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

I think the canonical racy case is "the page wants to keep a counter for the
number of times event X occurs" in a cookie or local storage.
It doesn't seem to be possible to achieve this without the mutex - the
proposal below would break down if two pages tried to increment the cookie
value simultaneously (if both pages changed "cookieValue=3" to
"cookieValue=4" at the same time, the result of your merge step would likely
be "cookieValue=4", not "cookieValue=5" as one might intend).

-atw

On Thu, Sep 3, 2009 at 1:08 PM, Benjamin Smedberg <bsmedberg at mozilla.com>wrote:

> On 9/1/09 7:31 PM, Jeremy Orlow wrote:
>
> > Does the silence mean that no one has any intention of implementing
> > this?  If so, maybe we should resign ourselves to a break in the single
> > threaded illusion for cookies.  This doesn't seem too outlandish
> > considering that web servers working with cookies will never have such a
> > guarantee and given that we have no evidence of widespread breakage with
> > IE 8 and Chrome.
>
> We (Firefox) just started looking at this seriously: the implications of
> the
> global lock are pretty unpleasant.
>
> The major race condition appears to be code on the web that gets
> document.cookie, parses and modifies the string it to add or remove a
> particular cookie, and sets document.cookie again. This pattern could race
> against HTTP requests which also set cookies.
>
> Chris Jones proposed that we behave in a script-consistent manner without
> actually doing a global mutex:
>
> * When a script gets document.cookie, "check out" a consistent view of the
> cookie data. While the script runs to completion, its view of
> document.cookie does not change.
> * When the script sets document.cookie and runs to completion, calculate
> the
> delta with the original data and "commit" the changes.
> * HTTP Set-Cookie headers stomp on prior data at any time, but don't
> interfere with the consistent script view above.
>
> It would be nice to provide an web API to perform the operation of setting
> a
> cookie atomically, just as the Set-Cookie HTTP header does. That is:
> document.setCookie('foo=bar; domain=subd.example.com').
>
> It's not clear whether/how this same algorithm could be applied to
> localStorage, since the amount of data required to create a consistent
> state
> is potentially much larger. Is there an inherently racy API in
> .localStorage
> which we need to protect with complicate mutex/transactional schemes?
>
> --BDS
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090903/3b2c5894/attachment.htm>

Received on Thursday, 3 September 2009 13:24:55 UTC