- From: Jens Alfke <snej@google.com>
- Date: Wed, 26 Aug 2009 14:05:52 -0700
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>
Received on Wednesday, 26 August 2009 14:05:52 UTC