Am 24.10.2011 um 21:51 schrieb Adam Barth: >> >> I'd like to know what the actual threat of such timing attacks are. I've >> seen claims of a maximum theoretical leak rate (in bits/s) but then counter >> claims that since, in this case, it would be hard to distinguish the >> difference in slowdown between CSS shaders and general page rendering, that >> the real rate is much lower. And, at least in the case of Safari, you can't >> always be sure that getting a rAF callback means you're about to draw. >> >> Does anyone have hard data on this? > > At a minimum, please do not land an implementation for this feature > without a way for ports that are concerned about this security feature > to disable it independently of both CSS_FILTERS and WEBGL. Contrary > to your previous assertion, the security implications are quite > different than those with WebGL. We already discussed the HW acceleration of SVG Filters on https://bugs.webkit.org/show_bug.cgi?id=70099 and the implementation of CSS Filters earlier on this mailing list. We agreed that we will continue to use the implemented software rendering as fallback for Filters. CSS Shaders won't be included. Shaders should just be supported if HW acceleration is enabled. And I think as a minimum consensus on bug 70099 most people on the thread agreed to go on with GraphicsContext3D for now. In my opinion it means we would have the same security concerns like on WebGL. That's also one reason why I think that the WEBGL flag would match these needs quite well, even if CSS Shaders rely just indirectly to WebGL. If the flag is not enabled, CSS Shaders are deactivated (and ignored if web developers use them in their filter chain) and Filters take the software rendering fallback.
Dirk
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
