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

Re: [Public WebGL] Extension proposal: WEBGL_security_sensitive_resources

Hi Max

While I like the idea of being able to use a rendered html element as a texture; I'm not completely sure I understand the extension's intent or the lock-down and security issues that be involved.

As I understand it, it deals with direct resources (image, video) and suggests composite resources (html)

There a five classes of direct resource:
  1. Own domain resources - no issue
  2. Cross-domain images or video  - can already be used with the appropriate http headers; and this works well, otherwise there would be a big problem trying to use a cdn for anything.
  3. Local resources - can also be used if the user uploads or dragdrops, or via getUserMedia for cameras.
  4. Domain accessible resources without cors headers; which are accessible by your domain, either public or with auth, so don't present a restricted resource security risk, - can be proxied either same-domain or with cors headers attached.
  5. Restricted resources - can only be accessed with appropriate authentication; note if these resource have the appropriate cors headers, and the domain they are used on is valid by the headers they are type 2; if your domain has access to them (server-side) they are type 4.
So for direct resources it would only be type 5 (when its not 2 or 4) that this extension would be the only workaround?

For composite resources; html based, there are three main categories:
  1. Accessible via _javascript_
  2. Texture resources - as above, but with the inclusion of object, iframe etc
  3. Personal - like whether a link has been visited
  • Category 1: Is no greater security risk in the WebGL context; as the WebGL is run from _javascript_ and it would be easier for example to just innerHTML the whole document from the _javascript_.

  • Category 2: Could work within the cross-domain framework and the origin-clean flag; but you probably shouldn't be taking images of a users' LOB flash, silverlight, or an iframe with their PayPal or bank statement. 

  • Category 3: should never be exposed outside the appropriate security context (e.g. a browser extension/plugin explicitly for managing your history etc)
I'd very much welcome an html render to texture or use html element as texture source; but think it could be done with looser security restrictions; and caveats for example:

:visited always rendered as :link , if they do not evaluate to the same style there may be a performance impact as any pre-rendered html for display cannot be re-used. Optimising for whether :visited links are in view may allow timing attacks.

Equally I'm not sure I understand the use-cases for allowing relaxed security on type 5 resources (where they are not 2 or 4)?

Kind regards

Ben Adams

On 26 September 2013 01:21, Max Vujovic <mvujovic@adobe.com> wrote:

Hi Oliver,

I'm suggesting the behavior defined in the proposal link:

The "Errors" section provides most of the explicit definitions of behavior. Please let me know if any sections need clarification.

- Max

On Sep 25, 2013, at 5:02 PM, Oliver Hunt <oliver@apple.com> wrote:

> Can you please describe exactly what this extension would entail?  We need explicit definitions of behaviour to be able to reasonably assess a proposal like this.
> —Oliver
> On Sep 25, 2013, at 4:50 PM, Max Vujovic <mvujovic@adobe.com> wrote:
>> Hi all,
>> I'd like to propose an extension that allows WebGL to process security sensitive content. In summary, the extension allows authors to upload cross-origin resources as textures and run a restricted shading language on their content. The shading language is restricted in order to prevent timing attacks. Authors can use both regular and security sensitive content in the same WebGL context.
>> The concept of security sensitive resources can be used to bring HTML content into WebGL in a future extension.
>> Here is a link to proposal:
>> http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_security_sensitive_resources/
>> This proposal is related to the discussion last November:
>> https://www.khronos.org/webgl/public-mailing-list/archives/1211/msg00058.html
>> I think enabling custom, accelerated effects on arbitrary content opens a whole world of creative possibilities on the web platform.
>> Feedback welcome!
>> Thanks,
>> Max
>> -----------------------------------------------------------
>> 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
>> -----------------------------------------------------------

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