[whatwg] Storage mutex and cookies can lead to browser deadlock

[Jens Alfke]

I know that one of the design issues with worker threads and local  
storage has been how to resolve concurrency issues, and that for this  
reason, in the current spec worker threads can't access local storage.

However, there's a scenario under the current spec that doesn't  
involve local storage, whereby a worker thread can deadlock the  
browser. This is because access to cookies, by workers or the browser  
itself, is also subject to that global mutex.

Consider these steps:
1. A worker thread accesses "document.cookie". This causes it to  
acquire the mutex (sec. 3.1.3).
2. The thread now performs some long-lasting operation without  
exiting. In the simplest case it just goes into an infinite loop.
3. Meanwhile, the user loads a new web page in the browser.
4. The resulting HTTP response contains a Cookie: header. The spec  
requires that the browser's loader temporarily acquire the mutex while  
updating the cookie (sec. 2.6, item 4).
5. The page-load blocks indefinitely because the worker thread still  
has the mutex and never lets go of it.

The result is that the browser becomes incapable of loading any web  
pages that use cookies. Assuming the worker thread never exits, the  
only way to recover from this is to quit the browser. A worker thread  
like this could very easily be created by a malicious website,  
resulting in a DoS attack on the browser. And of course, a merely  
poorly-written script could create the same effect without intending to.

I honestly can't think of any safe way of tweaking the semantics of  
the existing 'document.cookie' API to make it transactional. :(

Has anyone implemented this portion of the spec yet?

—Jens

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090826/cf1381c8/attachment-0001.htm>