[whatwg] Web Storage: apparent contradiction in spec

On Thu, Sep 3, 2009 at 5:33 PM, Ian Hickson<ian at hixie.ch> wrote:
> On Thu, 3 Sep 2009, Tab Atkins Jr. wrote:
>> On Thu, Sep 3, 2009 at 7:56 AM, Ian Hickson<ian at hixie.ch> wrote:
>> > On Mon, 31 Aug 2009, Jens Alfke 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.
>> >
>> > The fact that local storage can be used for cookie resurrection means
>> > we have to make sure that clearing one clears the other. Anything else
>> > would be a huge privacy issue (just as Flash has been).
>>
>> And as Flash will continue to be, forever, in a manner that is generally
>> opaque from the user, especially as more people lean on it for things
>> like a halfway-dependable storage location.
>
> On Thu, 3 Sep 2009, Aryeh Gregor wrote:
>>
>> The *only* reason Flash is a privacy issue is because there's no easy
>> way for users to clear its storage. ?The issue here isn't the
>> technical details of how the storage works, but the UI. ?Adobe, for
>> whatever reason, has chosen not to bother with helping Flash users
>> preserve their privacy, and because of lock-in, browser vendors are
>> unable to do anything about it. ?All major browser vendors have a
>> track record of going to great lengths to ensure that their users'
>> privacy is protected from third-party websites. ?I think it's safe to
>> say they'll compete to create good UI in this case -- even if
>> technically, the functionality of HTML 5 localStorage is identical to
>> that of Flash local storage. ?The spec doesn't need to try specifying
>> UI here (especially since it seems like it will be ignored).
>
> Indeed.
>
> Flash's privacy problem can be removed by uninstalling Flash. They're not
> a license to add more privacy problems to the platform.

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...

> On Thu, 3 Sep 2009, Tab Atkins Jr. wrote:
>> On Thu, Sep 3, 2009 at 7:56 AM, Ian Hickson<ian at hixie.ch> wrote:
>> > On Mon, 31 Aug 2009, Jens Alfke wrote:
>> >>
>> >> 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.
>> >
>> > I don't see what else we can do.
>>
>> You could just *not* specify that LocalStorage is worthless for anything
>> but a cache. ?Is there *anything* that would allow a permanent
>> site-accessible storage solution in your mind, or is cookie resurrection
>> a deal-killer for all time?
>
> The latter.
>
>
>> If the latter, you're not doing anyone any favors, least of all users,
>> as they'll still have their privacy violated but by entities other than
>> their browser which may be more difficult to review and regulate.
>
> If Adobe wants to violate their users' privacy, that's their prerogative.
> But I'm not speccing something that so blatently allows users to be
> tracked without their consent -- and worse -- despite their attempts to
> stop it.

It doesn't 'allow users to be tracked without their consent' any more
than cookies by themselves do.  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.

Would an approach like the <input type=save> be okay, where the user
has to explicitly take an action to enable permanent Storage for a
site the first time?  That makes simple navigation exactly as safe as
it is today, where cookies can leak privacy but they can be wiped.
You have to actively opt in to reducing your privacy.  I *want* to be
able to reduce my privacy for sites that I trust.

~TJ

Received on Thursday, 3 September 2009 15:44:17 UTC