[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] CORS and resource provider awareness



Hi Ken,

Some thoughts inline...

On Tue, Oct 30, 2012 at 12:54 PM, Kenneth Russell <kbr@google.com> wrote:
>
> Nobody's code would be broken.
>
> The idea, a variant of which Gregg Tavares has posted before to this
> mailing list, would be:
>
>   - A WebGLRenderingContext would start life with a "shader_clean" bit set.
>
>   - The "shader_clean" bit continues to be set so long as all shaders
> loaded into the WebGLRenderingContext obey the timing restrictions set
> in the ANGLE patch.

This analysis will be unnecessary in very many use cases. Should it be
run for every shader?

If I have a same-origin web game that loads 256 shader permutations,
why should they all be checked for timing attacks?

>   - While the "shader_clean" bit is set:
>
>     - It is legal to upload cross-domain media into WebGL textures.
> Doing so taints the canvas and prevents toDataURL(), readPixels(),
> etc., as the pre-CORS WebGL spec did.
>
>   - If the "shader_clean" bit transitions from true to false, and any
> cross-domain media was uploaded as a texture, then the context would
> be lost.

Could the shader fail to compile instead? Context loss is pretty harsh.

>   - If the "shader_clean" bit was false, the existing CORS
> restrictions would be enforced.
>
> This would not break any existing programs. It would, however, allow
> cross-domain media to be used in conjunction with a set of useful
> WebGL shaders.

Here's what I propose:
Shaders which are intended to not branch on texture data should
declare something like

#extension WEBGL_BRANCH_RC : disable

where 'WEBGL_BRANCH_RC' (Restricted Content?) is a strawman name for
an implicit extension that is enabled by default in ESSL right now.

Shaders which do not disable this extension ('intension'?) do not have
the branch analysis performed and always unset the "shader_clean" bit.
Shaders which disable this extension (as above) will error on compile
if they branch on potentially unprivileged data.

With this approach, use of the subset of the language that is safe is
explicitly declared in shaders and shader authors and users can tell
at-a-glance whether the shader obeys the timing restrictions. To
instruct their tools to find violations, authors can say:

#extension WEBGL_BRANCH_RC : warn

Here are the state transitions for the shader_clean and tainted bits.
The state is represented by (shader_clean, tainted) with the start
state as (true, false):

(true, false) --CORS upload--> (true, false)
(true, false) --(BRANCH_RC : disable) upload--> (true, false)
(true, false) --non-CORS upload--> (true, true)
(true, false) --(BRANCH_RC : enable) upload--> (false,false)

(true, true) --(BRANCH_RC : enable) upload--> #fail_compile

(false, false) --non-CORS upload--> #fail_upload

Where other transitions are identity for these state bits.

CSS shaders would then be required to disable the extension. This
might break shaders which currently do:

#extension all : disable

but AFAIK no one does this on the web (why would you?! but "all :
warn" would get more useful) and these shaders should arguably be
broken if they branch on texture data because they no longer use the
minimal feature set for the platform.

What do you think?

David

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------