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

[whatwg] Web Storage: apparent contradiction in spec

From: Peter Kasting <pkasting@google.com>
Date: Thu, 3 Sep 2009 15:48:52 -0700
Message-ID: <d62cf1d10909031548p3862dd3fh6f3bb3d310da3879@mail.gmail.com>
On Thu, Sep 3, 2009 at 3:44 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:

> And more-than-a-cache-Storage can be explicitly turned off or have its
> quota dropped to zero.  If that's important, the browsers will make it
> easy.  And more importantly, they'll make it *consistent* (within the
> browser), rather than the user having to figure out how to do it
> within Flash, then possibly within the next technology that hacks
> around this lack in browser technology, and the next one...
>

As a UA author I see nothing in the spec that prevents this *now*.

If this is important, browsers will
> expose the ability to blow away all of a site's storages at once.
> There's nothing to resurrect then.  On the other hand, if someone
> wants a site to keep its permanent Storage, then cookie resurrection
> isn't a big deal.
>
> You're seem to be assuming that either permanent Storage is *really*
> permanent, or that browsers will never expose a way to delete that
> data to the user (which amounts to the same).  That's silly.  The
> whole *point* of specifying a permanent Storage in HTML is so browsers
> can produce something that *they* control the UI for, rather than
> leaving the user's privacy to unknown plugins and other hacky means.
>

Again, this is precisely what we as UA authors can do now, with the current
spec.  I'm not sure what you're arguing.  Our job is to make sure users
whose philosophy is like Ian's are as well-served as users whose philosophy
is like yours, and our hands are not tied.

PK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090903/2d0ca90d/attachment.htm>
Received on Thursday, 3 September 2009 15:48:52 UTC

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