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

[whatwg] Web Storage: apparent contradiction in spec

From: Jeremy Orlow <jorlow@chromium.org>
Date: Mon, 31 Aug 2009 11:12:42 -0700
Message-ID: <5dd9e5c50908311112r385bed54l8bdb732d908012df@mail.gmail.com>
On Mon, Aug 31, 2009 at 11:01 AM, Jens Alfke <snej at google.com> wrote:

>
> On Aug 31, 2009, at 3:11 AM, Ian Hickson wrote:
>
>  We can't treat cookies and persistent storage differently, because
>> otherwise we'll expose users to cookie resurrection attacks. Maintaining
>> the user's expectations of privacy is critical.
>>
>
> The fact that local storage can be used as a type of super-cookie doesn't
> mean the two are the same thing. Yes, obviously if I give a website
> permission to put 50MB of stuff on my disk, it can use 1k of that as a type
> of cookie if it wants. That's just one of many reasons why user agents
> should require user approval for letting a domain access local storage.
>
> That does not mean that the "Delete Cookies" menu command should also
> delete local storage. Users often delete cookies to resolve login issues
> (I've had to do this with Google websites several times). Conflating the two
> can lead to disasters like "I told you to delete my COOKIES! Not my EMAIL
> DRAFTS that I was trying to log in to send!"


Agreed.


>  So I've removed the text that says that local storage could be
>> user-critical.
>>
>
> That's going to come as a shock to developers who were planning to use it
> for user-created data (whether drafts of content to be pushed to the cloud,
> or strictly-local documents.) Without this, the safe usage of local storage
> diminishes to a download cache.
>

Yes, this is pretty disconcerting since there's been OVERWHELMING support
for LocalStorage being treated as user-critical on this thread.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090831/2cd61352/attachment.htm>
Received on Monday, 31 August 2009 11:12:42 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:16 UTC