W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2009

[whatwg] RFC: Alternatives to storage mutex for cookies and localStorage

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 8 Sep 2009 19:00:44 -0700
Message-ID: <63df84f0909081900r2b38ef23i8553e0c6c103a228@mail.gmail.com>
On Tue, Sep 8, 2009 at 6:00 PM, Maciej Stachowiak<mjs at apple.com> wrote:
>
> On Sep 8, 2009, at 4:27 PM, Chris Jones wrote:
>
>>
>> I think I haven't been explaining my proposal clearly enough. ?Let me try
>> to err on the other side of brevity. ?Sorry if this is too pedantic.
>>
>> Currently, UAs either (i) support localStorage or (ii) don't. ?Web apps
>> using localStorage must therefore determine whether the UA they're running
>> in supports localStorage, and adjust their behavior accordingly. ?If they
>> don't, they won't run in type (ii) UAs.
>>
>> So how do web apps implement this check? ?If I were implementing it, I
>> would test |window.localStorage === undefined|. ?I have no clue how web devs
>> actually implement it; I solicited feedback from them in earlier posts.
>
> I think this has a few problems:
>
> 1) There are probably Web apps that actually detect based on user agent
> sniffing, rather than based on feature testing. No matter how much we tell
> people to feature-test, there are still many Web sites (and even popular
> JavaScript libraries) out there that look at the User-Agent string.
>
> 2) There are probably mobile-targeted Web apps aimed at devices like iPhone,
> Palm Pre and Android which just assume LocalStorage is there (since it is
> available on all their target devices).
>
> 3) For Web apps that used the older feature in good faith, it would be
> suddenly taken away from their existing deployed apps. I expect this will
> make developers unhappy even if it doesn't technically break their site but
> rather just makes some functionality regress in browsers that support
> LocalStorage, down to the level of non-supporting browsers. I would rather
> let them keep using a suboptimal form of the feature than take it away
> supposedly for their own good.

My concern with this solution is that pages are still very likely to
not think of any of this and instead use the simplest API available,
which undoubtedly will be the transaction-free unsafe API.

Thus for most pages this isn't better than not doing anything.

/ Jonas
Received on Tuesday, 8 September 2009 19:00:44 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:52 UTC