Your message is somewhat off-topic for this mailing list, which is about the development of the WebKit engine. Would you be willing to re-send your message to the FX task force:
http://www.w3.org/Graphics/fx/ That's the appropriate venue to discuss use cases and the like for CSS Shaders. That way we can get feedback from a variety of implementors instead of just WebKit. Adam On Thu, Dec 8, 2011 at 1:51 PM, Charles Pritchard <ch...@jumis.com> wrote: > On 12/3/11 11:37 PM, Dean Jackson wrote: >> >> On 04/12/2011, at 6:06 PM, Adam Barth wrote: >> >>> On Mon, Oct 24, 2011 at 9:51 PM, Adam Barth<aba...@webkit.org> wrote: >>>> >>>> Personally, I don't believe it's possible to implement this feature >>>> securely, at least not using the approach prototyped by Adobe. >>> >>> I spent some more time looking into timing attacks on CSS Shaders. I >>> haven't created a proof-of-concept exploit, but I believe the current >>> design is vulnerable to timing attacks. I've written up blog post >>> explaining the issue: >>> >>> http://www.schemehostport.com/2011/12/timing-attacks-on-css-shaders.html >> >> Thanks for writing this up. >> >> I'm still interested to know what the potential rate of data leakage is. >> Like I mentioned before, there are plenty of existing techniques that >> could >> expose information to a timing attack. For example, SVG Filters can >> manipulate the color channels of cross-domain images, and using CSS >> overflow >> on an iframe could potentially detect rendering slowdowns as particular >> colors/elements/images come into view. CSS shaders increase the rate of >> leakage >> because they execute fast and can be tweaked to exaggerate the timing, but >> one could imagine that the GPU renderers now being used in many of >> WebKit's ports >> could be exploited in the same manner (e.g. discover a CSS "trick" that >> drops >> the renderer into software mode). >> > ... >> >> Is there something we can do to make rendering-based timing attacks >> less feasible? >> > ... >> >> Or maybe rAF is inherently insecure? > > > Is there an active interest in investigating these issues? I understand that > CSS Shaders is bringing them to the forefront. > > I am confident we can move Shaders forward in a limited and safe manner, by > starting first on CORS Media elements, essentially bringing them to parity > with WebGL Canvas. > > That is to say: <canvas></canvas> -- with WebGL is up on the web and tested > as a means to apply filters to <img> and <video>. > Surely we can provide a CSS short-cut. > > But back to my concern: Sometimes a new idea or use case brings up real > engineering issues that get pushed-back as people push-back on the use case > or broader implications. I experienced that phenomenon to a large degree > with the <canvas> tag in Canvas 2d. I'd like to do better with pixel > shaders. > > Is there an objection to CSS Shaders for media elements, origin safe video, > img and canvas? They work in WebGL, they should work fine in CSS. > > Is there reasonable support for investigating timing issues inside of the > browser? We have baseline issues from latency in network requests: If I > request an image from a site you've already visited, it's likely to load > quicker than a subsequent request for a random 404 page from that site. I > feel that this baseline issues can help us take some of the controversy away > from future studies on timing issues. They already exist, they're accepted > and acceptable for consumer-grade browsers. > > I'm getting the feeling that these very interesting and important cases > brought up by Dean Jackson, are not being evaluated. > Webkit vendors, and many w3c vendors, should have an interest in seeing them > analyzed. > > So I'm reaching out here and saying, does anyone think this is a worthwhile > avenue for serious study? Is it simply not important for this generation of > browsers? > > Though webkit has a bias against "scientific experiment" on the code base, > being that it's an "engineering" project, it seems to me like engineering > and science as well as security and quality, benefit from asking these > questions and doing focused research. > > > -Charles > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
