- From: Peter Kasting <pkasting@google.com>
- Date: Thu, 3 Sep 2009 16:16:28 -0700
On Thu, Sep 3, 2009 at 4:08 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote: > 10 hours ago, Hixie said: > > 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). > > There are a few other remarks in line with this from that email and a > subsequent one. > Statements in an email are not equivalent to statements in the spec. Ian is rightly concerned about user privacy, and the spec reflects that concern by advising that user agents should try to make this clear to users. But what it does not say is that UAs must clear them at the same time, and the fact that the spec language was changed SPECIFICALLY to try and make this more clear is pretty solid evidence. As I have said before, in the end it's irrelevant what you and Ian want to argue about by email: what ultimately matters is what UA vendors decide to do, which the spec will then reflect. And I find it extraordinarily unlikely that any UA vendor would not implement granular control over local storage. If this doesn't imply that LocalStorage in practice will thus become > an ephemeral storage mechanism that is easy for users to accidentally > blow away, and thus will be too unreliable for anything beyond a > supercookie, then I'd like clear statements to that effect. As it is, > theoretical assurances that it's all going to be okay aren't adequate > - if any browser *actually* made cookie-clearing *automatically* also > clear LocalStorage, we authors can't rely on it. > Clear statements aren't going to make you any safer than unclear ones will make you unsafe. A UA vendor can easily decide to violate a clear statement (and this has been done countless times with numerous specs in the past). That said, I have heard nothing from *any* UA vendor that suggests anyone will do what you fear. PK -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090903/9235f9bb/attachment.htm>
Received on Thursday, 3 September 2009 16:16:28 UTC