Browsers need to overhaul their privacy settings to account for things like
localStorage and bring control back to the user. In the days of cookies it was relatively simple for a user to wipe any identifiers (excluding IP address) from their browser. Simply clear cookies.
Firefox has two basic abilities, you can clear cookies, or you can browse and delete cookies. That’s great but not terribly clear that there’s more than cookies.
as far as I know has no cookie browser like Firefox has, but (edit: Erunno notes in the comments you can via chrome://settings/cookies) explicitly lets you “Delete cookies and other site and plug-in data”. That’s pretty good.
Today, I think Safari’s UI is the closest to perfect. Each hostname shows exactly what it has. My only gripe is that Safari doesn’t let you see what’s there. That’s a “power-user” feature however and I think it does an adequate job regardless.
Websites use more than just cookies these days. I discussed this a little over a year ago. The reason evercookie is controversial is that browsers don’t quite give users the level of control (real or perceived) that they expect for objects other than cookies.
Here is another use case for why this is needed. Google Analytics is used on perhaps half the internet’s websites. It sets a cookie every time. That means 230 bytes added to every http request for a lot of websites. Google could switch to
localStorage and free up that 230 bytes. While they technically could do this, in practice, this could create a firestorm of attacks against them. The problem is it would be spun as Google trying to evade cookie deletion and and a privacy violation. The same storm that evercookie created. I suspect that’s why it hasn’t been done to date. The truth is the Google Analytics team has done a lot for improving performance including making it entirely async. But this move would be controversial.
It’s no longer about “cookies”, but “user data”.
16 replies on “Privacy Issues Behind localStorage”
I have put a “storage” panel into my Tahoe Data Manager add-on, but unfortunately we have bad to non-existent interfaces in the Mozilla platform for a manager/viewer of the various new web storages (app cache, DOM storage / localStore, indexedDB) and so I had to plaster this implementation with crude hacks. It would be so nice if someone could go in and write some interfaces for those that are as nice as those for cookies, passwords, and permissions.
“Chrome as far as I know has no cookie browser like Firefox has”
This is not true (and never has been). Chrome’s cookie browser is reachable via chrome://settings/cookies and lists all data (cookies, localStorage, WebSQL, etc.) for each domain. I find it superior to Firefox’ current offering does not have such a comprehensive interface to quickly check what kind of data a domain has stored.
Updated. Thanks for the info.
Just to avoid any misunderstanding that this might be a hidden feature: The cookie browser is also reachable via Preferences -> Under the Hood -> Content Settings -> All Cookies and Site Data…
“I find it superior to Firefox’ current offering does not have such a comprehensive interface to quickly check what kind of data a domain has stored.”
This is not true. Firefox’s data permissions is reachable via about:permissions
It’s not comparable. about:permissions is about setting per-domain permissions with limited browsing abilities of site data (Firefox still misses an UI for managing localStorage AFAIK). Chrome’s cookie browser is about offering a comprehensive view of per-domain site data with permission management delegated to other interfaces.
Additionally (and contrary to Chrome’s cookie browser) about:permissions is a hidden feature as it is not reachable via the primary (i.e. mouse driven) interface. Given the rough look of it the decision to limit its exposure is understandable.
Ideally I would like to see both approaches combined, i.e. per-domain permission settings with site data browsing which does not necessitate open sub-interfaces (as about:permissions currently does).
“Additionally (and contrary to Chrome’s cookie browser) about:permissions is a hidden feature as it is not reachable via the primary (i.e. mouse driven)”
That was filed as bug 697941
The TrackerBlock addon from privacy choice (https://addons.mozilla.org/en-US/firefox/addon/trackerblock/) provides an HTML5 cookie editor.
Take a look at the code to see what a pain it was to implement.
Thank you, Robert. With all the excitement the Mozilla community displays in developing new features such as localStorage, the impact on privacy seems to be a bit of an afterthought. But since the new features are not yet in common use, there is still time to design with ‘privacy by default’ and ‘security by default’.
” the impact on privacy seems to be a bit of an afterthought.”
Part of Mozilla’s sales pitch for Firefox is that it gives the users control over their data. Implementing localStorage without any means to manage it contradicts that goal directly. It’s also certainly ironic that the browser developed by one of the biggest data collectors on the Internet has better controls in this regard.
“But since the new features are not yet in common use”
It’s not as widespread as cookies or LSOs but judging by my Chrome profile localStorage is already making huge inroads, especially on the big popular sites (amazon, nytimes, etc.).
Another factor in Google’s not adopting locale storage is likely also that because it’s a synchronous interface, it requires a global lock for some accesses. Making most sites start to try to grab that is likely to make the entire browser lock up a bit more often, which is something they probably don’t want Chrome doing in particular.
Well, I guess cookies already have the same problem. But storage is new enough that conceivably, people could get shifted away from it, if it’s not used too much…
“Another factor in Google’s not adopting locale storage”
Unless you talk about some other local storage your statement is wrong. My Chrome test profile shows local storage entries for several domains in the cookie manager.
Jeff: I’d be curious if there’s any measurable difference. My understanding was that cookies have the same issue, but it’s small enough to not be worth caring about (unless you’re reading/writing lots of cookies constantly, and I can’t think of an application where that would be useful).
Turns out I was mistaken about the problem here — it’s that it’s racy (see also subsequent comments). Now of course you can hack around this in various ways if necessary. But having to know about this, and having to do that work, seems pretty awful.
I wonder about the circumstances of those Google uses. Maybe they are doing a racing hackaround, or maybe it’s experimental code that’s doing it. I distinctly remember hearing that they weren’t using it because of the multi-process racing bits.
In the meantime, Potch wrote a bookmarklet: http://potch.me/ls/