On Mon, Jan 4, 2016 at 3:09 PM, Kearwood "Kip" Gilbert <kgilb...@mozilla.com> wrote: > > IIRC, we don't believe WEBGL_security_sensitive_resources is viably > > implementable in a safe way (timing attacks!), so I suggest ignoring > > it. > Perhaps enforcing a CORS-like model would be simpler to secure, by > limiting what content you can get handles for?
A big problem is sticking HTML/CSS content into WebGL is that WebGL effectively enables reading pixel data through custom shaders and timing attacks. And HTML/CSS currently displays a lot of private information which we explicitly don't want the webpage to be able to read. For example: * Cross-site (non-CORS) images * Cross-site iframes * Visited-coloring of cross-site <a> links * OS-rendering of form controls (since they can be user-customized) * Possibly some information from cross-site (non-CORS) stylesheets, though I'm not sure if there's any information not already leaked through getComputedStyle(). I can only think of two ways to enable rendering a HTML element in WebGL without leaking the above information: * Enable a way to make sure that none of the above information exists in the HTML element. * Enable a way to use WebGL where the draw time can't be measured. I think the latter might be very hard since lately there has been a lot of demand from authors to get access to performance metrics on end-user devices, which makes a lot of sense. The former might be possible, but it'd be a lot of work finding all edge cases where we expose sensitive information, and the defining and implementing sensible behavior there. A number of cool features could likely be built with a system like that though. / Jonas _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
