- From: Drew Wilson <atwilson@google.com>
- Date: Wed, 26 Aug 2009 14:11:30 -0700
My recollection is that we prohibit worker access to cookies for exactly this reason (WorkerGlobalScope does not expose a "cookies" attribute). -atw On Wed, Aug 26, 2009 at 2:05 PM, Jens Alfke <snej at google.com> wrote: > 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/e844048c/attachment.htm>
Received on Wednesday, 26 August 2009 14:11:30 UTC