On Mon, Oct 24, 2011 at 9:38 PM, Dean Jackson <d...@apple.com> wrote: > On 24/10/2011, at 9:08 PM, Adam Barth wrote: >> How have you solved the security problems with CSS Shaders? >> Specifically, timing attacks can be used to extract image information >> passed to shaders and many things WebKit renders are sensitive and >> should not be exposed to the web site (e.g., the color of visited >> links). > > This is a good question and I know that I don't have the answers (and can't > even claim to understand all the implications). > > I think the most important restriction is that shaders should not apply > cross-origin. e.g. iframes and probably anything with <img> children from > another domain (unless it is marked as ok via CORS).
There's an issue even with same-origin content. The issues are quite similar to the security issues with canvas.drawElement. Please see the extensive discussion on https://bugs.webkit.org/show_bug.cgi?id=69044. > The possibility of leaking information such as visited links, or maybe > reconstructing text which could be fed to OCR, is more difficult. Is this > really specific to CSS Shaders? SVG filters would theoretically be able to do > the same thing. In fact, given enough knowledge of WebKit rendering one could > imagine tweaking the style of an element in a way that causes a measurable > rendering slowdown. If that were true, it would be a serious privacy attack. We've taken care that a web site cannot learn about which links the user has visited, even with tricky timing attacks. For example, visited and non-visited links cannot have styles that differ in the alpha channel because differences in the alpha channel show up as differences in rendering time. > 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. Personally, I don't believe it's possible to implement this feature securely, at least not using the approach prototyped by Adobe. However, I would love to be proven wrong because this is certainly a powerful primitive with many use cases. Adam _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
