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

Re: [Public WebGL] CORS and resource provider awareness

If it's possible to have a subset of ESSL that doesn't have timing issues then it might be possible we could allow uploading of HTML textures as in

   gl.texImage2D(...., someDOMSubTree)

The canvas would be marked as "origin-clean" = false which would disable readPixels and toDataURL

And/or the firefox extension that allows WebGL access to the compositor's layers that they use for their 3D DOM viewer might be possible to enable for webpages and not just privileged code.

I only want to point that out as this issue isn't just about CORS assets.

Of course if it's not possible to prevent the timing issues then we won't go there which is fine but I certainly seems nice to try.

On Tue, Nov 6, 2012 at 6:15 AM, Kenneth Russell <kbr@google.com> wrote:

On Mon, Nov 5, 2012 at 12:36 PM, Florian Bösch <pyalot@gmail.com> wrote:
> On Mon, Nov 5, 2012 at 9:21 PM, Kenneth Russell <kbr@google.com> wrote:
>> This entire path of investigation is certainly fragile. I appreciate
>> the comparison to a leaky sieve. I would expect this functionality to
>> be exposed as a WebGL extension, not in the core API, and we would
>> expect to need to turn it off many times as new attacks are
>> discovered. Nonetheless, I think that if we collectively invest time
>> and effort to try to break the planned restrictions, that we might
>> determine a good subset of GLSL that can be used with cross-domain
>> media. Of course, if anyone has completely different ideas that would
>> also enable access to the desired media in an even safer manner,
>> please propose them.
> I'm still a bit concerned about about a couple things.
> 1) I'd like this complexity introduced by trying to defend against timing
> attacks but allow cross domain not be part of the core, because it would
> make implementing the core quite difficult. non CORS tainting is relatively
> straightforward to implement. Data flow analaysis, perhaps not.

As I mentioned above, agree with you about adding this behavior as an
extension and not in the core. I anticipate either needing to turn
this extension off multiple times as issues are discovered, or not
enabling it by default, and recommending to not do arbitrary web
browsing with it enabled.

> 2) I don't like it when a context gets shot from under you, for any reason,
> but especially not for reasons that would be avoidable. My concern here is
> that:
>   a) Adding a non CORS safe shader to a CORS tainted context nukes the
> context.
>   b) Adding a CORS subjected resource to a context with non CORS safe
> shaders nukes the context
>   Both these things can happen as a result outside of the direct control of
> the application author. For instance as a result of some resource provider
> dropping CORS headers, or as a result of accepting a shader in some manner
> that violates CORS safety from the outside (glsl sandboxes, etc.)

David Sheets made a good suggestion elsewhere in this thread to keep
the context secure by either (a) deliberately failing texture uploads
or (b) failing shader compilations, rather than forcing lost contexts.

> 3) Keeping the sieve tight will not get easier as ESSL progresses. There are
> going to be things like compute shaders, blend shaders, atomic counters,
> more shader stages etc. This is all pressing down on ES in the not so near
> future. It's true that we don't have to address these right now, on the
> other hand we know about these things right now because they've become the
> reality on desktops.

Agreed, it will become more complicated, but we should start somewhere
to see whether this is feasible at all. Experimentation over a period
of months is probably going to be needed to see whether the
restrictions that are developed are actually secure.


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