On Fri, Dec 9, 2011 at 2:40 PM, Vincent Hardy <vha...@adobe.com> wrote: > On Dec 7, 2011, at 7:29 PM, Adam Barth wrote: >> On Wed, Dec 7, 2011 at 7:23 PM, Vincent Hardy <vha...@adobe.com> wrote: >>> @chris >>> >>>>> So I take back my statement that CSS Shaders are less dangerous than >>>>> WebGL. They are more!!! >>> >>> It seems to me that the differences are: >>> >>> a. It is easier to do the timing portion of a timing attack in WebGL because >>> it all happens in a script and the timing is precise. With CSS shaders, the >>> timing is pretty coarse. >>> >>> b. The content that a CSS shader has access to may be more sensitive than >>> the content a WebGL shader has access to because currently, WebGL cannot >>> render HTML (but isn't it possible to render an SVG with a foreignObject >>> containing HTML into a 2D canvas, and then use that as a texture? In that >>> case, wouldn't the risk be the same? Or is the canvas tainted in that case >>> and cannot be used as a texture?). >> >> Bear in mind that these security problems have been addressed in >> WebGL. WebGL no long suffers from these vulnerabilities. > > Yes, I understand WebGL now assumes CORS for allowing/disallowing access to > resources. But my point was to clarify what is possible in terms of timing > and what is possible (or may become possible) in terms of rendering. > > Timing on CSS shaders is coarse (because there is not precise way to time how > long rendering of the shader takes unlike in WebGL). The attacker would rely > on requestAnimationFrame, and the time that is measured with that method > includes other processing than just the shader. So the timing measure is > rough. It is definitely important that we protect against the threat, but my > point is that the time measure is not great. > >> >>> @charles >>> >>>>> Can this proposal be moved forward on CORS + >>>>> HTMLMediaElement, HTMLImageElement and HTMLCanvasElement? >>> >>> At the last FX meeting, I got an action to sync. up with the CORS group and >>> discuss how CORS would apply to CSS shaders. >> >> It's very unclear to me how CORS can help in this situation. Can you >> explain what you have in mind? > > When a shader that applies to an element comes from a different origin than > the rendered content, then rendering of the element would be blanked. The > shader origin would be the shader's own url, the url of the page it is > embedded in or the url of the script that created it dynamically (e.g., by > injecting one dynamically with data: url for example, something Dean just > mentioned to me in a conversation we had). If there is any mismatch between > the origin of the shader and the origin of the shaded content, then the > rendering would be blanked (unless CORS on the shaded content gives > permission to the shader's origin). This would be done recursively on the > content. It is unclear to me if any mismatch should blank out the whole > rendering or if only the nodes in the tree that do not match should be > blanked.
As discussed previously, this approach is insufficient because some sensitive data is unrelated to cross-origin resources. For example, the color of hyperlinks is sensitive data but is unrelated to cross-origin resources, as is information displayed by the file upload control. > The action item is to discuss this with the WebApps group. I agree that either the WebApps working group or the FX task force is the best place to discuss this topic. I've already started a thread on the FX task force mailing list, if you'd like to continue the discussion there. If you prefer the WebApps working group, please feel free to start a thread on public-webapps. Thanks, Adam _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
