[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] CORS and resource provider awareness
On Sun, Nov 4, 2012 at 5:16 PM, David Sheets <email@example.com> wrote:
> Hi Ken,
> Some thoughts inline...
> On Tue, Oct 30, 2012 at 12:54 PM, Kenneth Russell <firstname.lastname@example.org> 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?
Fair questions. I believe the dataflow analysis computing the
"shader_clean" bit is so cheap that it could be done all the time
without significantly impacting the startup or run-time performance of
any real-world application. Shader translation and validation is
already a mandatory step when loading WebGL shaders.
>> - 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.
That's a good point. Yes, I think it could. I hadn't thought of that
>> - 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
Thanks, this is a useful tabulation of the states.
> 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?
Interesting idea, and a possibility. It seems to me that the main
motivation for adding a GLSL extension would be to be able to skip the
analysis altogether. I think the cost of the dataflow analysis should
be measured first before adding more extensions and complexity. If we
were to go down the route of defining a GLSL extension then I think it
should be one disabled by default, enabled manually, and which
indicates intent to produce a shader obeying the control flow
restrictions. The shader compilation log would still provide detail on
why any shaders failing that analysis did so.
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: