- From: Chris Marrin <cmarrin@apple.com>
- Date: Mon, 12 Dec 2011 15:23:23 -0800
- To: Adam Barth <w3c@adambarth.com>
- Cc: "Gregg Tavares (wrk)" <gman@google.com>, Vincent Hardy <vhardy@adobe.com>, "public-fx@w3.org" <public-fx@w3.org>
On Dec 12, 2011, at 3:05 PM, Adam Barth wrote: > On Mon, Dec 12, 2011 at 2:56 PM, Chris Marrin <cmarrin@apple.com> wrote: >> On Dec 12, 2011, at 1:06 PM, Gregg Tavares (wrk) wrote: >> On Mon, Dec 12, 2011 at 11:48 AM, Chris Marrin <cmarrin@apple.com> wrote: >>> On Dec 12, 2011, at 10:23 AM, Adam Barth wrote: >>>> I'm happy to start talking about solutions once folks stop pretending >>>> this vulnerability doesn't exist. >>> >>> One solution would be to hide the amount of time it takes to render from >>> the content author. This is theoretically possible if you render in a >>> different thread than the one in which JavaScript is running (the web >>> thread). For instance, the web thread could construct a list of commands >>> used to render the page and then pass that list to another thread or process >>> for the actual rendering. While rendering is happening in that other thread, >>> the web thread can continue, generating a new display list for the next >>> frame. >>> >>> You'd still throttle the web thread to the display refresh rate to avoid >>> generating more display lists than could possibly be useful. But the actual >>> rendering could take an arbitrary amount of time without affecting the rate >>> at which display lists are generated. Since shader execution time is purely >>> a rendering artifact, the author would never know how long it has taken. >>> >>> The downside of this approach (other than additional complexity) is that, >>> if rendering is slower than the display refresh rate, more display lists >>> would be generated than rendered. These would simply be discarded, but the >>> browser would be doing more work than it does today when under heavy >>> rendering load. >> >> >> In this particular case I think the problem boils down to >> requestAnimationFrame. It's only going to give you frames as fast as it >> takes to render and one way or another you can use that to get your timing. >> (I don't think setInterval/setTimeout would be any different). At some point >> the JavaScript or HTML renderer will be throttled waiting for this other >> process to do work. You just need to figure out how much work to give it to >> find that throttling point and then use that to adjust how long rendering >> takes. >> >> >> rAF need not know anything about the rendering process. As far as the author >> knows the system is running at 60fps no matter how complex the page. In fact >> nothing that the author can see needs to know about it. As far as the author >> is concerned he is rendering to a display list at 60hz (or whatever the >> display rate is), and as long as creating that list doesn't give back any >> timing information (which it shouldn't), there should be no way to know how >> long a given rendering operation will actually take. >> >> Maybe you're concerned that the web thread would sometimes need to block on >> the rendering thread. By definition that would never be allowed. The final >> rendered image would be "output only". This of course would not be possible >> if you needed to read back the image, as you're able to do with canvas. But >> obviously any such read back would be disallowed when the canvas (or any >> other object whose image is processed by content code) contains pixels from >> the rendered page. > > It doesn't matter if one blocks on the other. They're competing for > the same resources, which means one thread (either the web thread or a > worker thread) will be able to observe how many resources the > rendering thread is using. That information contains the sensitive > information we are trying to hide. And so you have to isolate the threads so they're not using a shared resource. In my last message I mentioned two ways to do that. One is to isolate the rendering on a separate processor and the other is to use a GPU and prevent the web thread from seeing when the rendering operation is finished. ----- ~Chris cmarrin@apple.com
Received on Monday, 12 December 2011 23:23:54 UTC