Disable DOM storage by default_store exceptions per site
Is there a method or addon that allows blocking DOM storage by default ("dom.storage.enabled"), but allows storing exceptions for trusted sites to use DOM storage? If not, does anyone know of anything under development for such capability?
Some sites don't work if DOM storage is totally disabled. It's well publicized (even by sites & companies, themselves) that DOM storage is far more useful to them, or 3rd party trackers, for cross site tracking than are traditional cookies.
Firefox & every cookie manager addon offer ability to block all cookies by default, but allow cookies (store exceptions) on a per-site basis.
AFAIK, there's nothing similar, to block all DOM storage by default, and store exceptions for a few sites you trust, or sites that require DOM storage for the site to work.
There are some addons that manually clear DOM storage, along w/ other cache, cookies, etc. Some may even clear DOM storage after closing the page, or at timed intervals (Self Destructing Cookies??).
I've not used SDC, but read it's documentation. If I understand, it only has ability to clear DOM storage - after the fact, not to block it by default & allow it only on whitelisted sites.
Thanks.
Gewysig op
All Replies (7)
DOM storage should use the same exceptions as cookies, so if you would block cookies then that should work.
Firefox 34 and later have a storage inspector that allows to see a website stores in local storage. It is part of the developer tools and can be enabled via the Toolbox Options (gear) icon in the Web Console (Firefox/Tools > Web Developer).
Thanks. A quick test confirms what you said about DOM storage using same preferences as what is used for cookies.* At least, testing a couple of sites.
Do you know how far back (Fx versions) that cookie settings controlled DOM storage? I'm not sure if that was always the case.
1) Your answer was quite useful. A question right off - if you have ONLY 1st party cookies allowed for a site, does that restrict data in DOM to ONLY 1st party, also? It could take a while to manually check this behavior on lots of sites.
If the answer is 'no' (i.e., DOM storage must either be allowed for all 1st & 3rd parties on a site, or not at all) then that's back to the equivalent of allowing 3rd party cookies. I hope that's not the case.
2) If DOM storage is always allowed on sites with cookies allowed, that still doesn't mean users always want to allow DOM storage for a given site, just because they allow 1st party session cookies for the site.
The data & what can be done w/ it aren't the same for cookies vs. DOM storage. That leads back to the original question: disabling DOM storage by default & storing exceptions. Separately from cookies, possibly because A) allowing cookies for purpose of logging in (for instance), doesn't mean you want to allow DOM storage.
B) what sites can do w/ DOM storage is different from what they can do w/ 1st party session cookies.
For others wanting to look at the "Storage Viewer" in Firefox Developer tools, go to: Tools (main menu) -- Web Developer -- click Developer Toolbar. From the dev toolbar UI, on its main toolbar - where Inspector, Console tabs, etc. are, click the Options (gear icon).
In Left column, under Default Firefox Develper Tools, check "Storage." (there are tool tips w/ brief description). Then, Storage tab will be on the developer toolbar (to view what the currently active web site (current tab) has stored, if anything.
You may need an add-on for this. I didn't see any that looked useful in a quick search.
(In the old days, you could use the Advanced tab of https://addons.mozilla.org/firefox/addon/controle-de-scripts/ to create sophisticated rules for managing access by scripts to individual methods and properties but after some changes in how Firefox manages "capability" settings a few versions ago, I suspect it doesn't work any more.)
Depending on who you want to block, some general purpose anti-tracking extensions may be an effective way to limit use of local storage: http://www.areweprivateyet.com/
Thanks jscher & cor-el. Thanks for the links.
I've only started looking, but no, I haven't seen any addons that separately control cookie behavior from DOM storage.
Cookie Controller (I've never used) https://addons.mozilla.org/En-us/firefox/addon/cookie-controller/ - shows separate settings to delete Session cookies vs. "Cookies AND DOM storage." Something like that might be worth a look. I'm not sure how it works. But deleting them isn't the same as blocking.
If they can be deleted separately, eventually they might be controlled separately?
I can't be the 1st to comment, that what sites can do with cookies vs. DOM storage is not at all the same. But they're handled basically the same in a browser.
That may be ? because the various browsers or some web standard make it very hard for addons to handle them differently. At least for now.
It took forever for most users to realize there was a big difference in 1st party & 3rd party cookies. Likely the same with DOM storage. Many users have never heard of it.
Little known fact: "cor-el" is a direct descendent of "Jor-el" (Superman's father). Which is why cor-el has super computer skills.
There are strong resemblances between local storage and cookies. For example, both consist of data in the same form:
name = value
And I believe both follow the same rules for access (e.g., domain-based security).
I also think Firefox is designed to apply session/persistent rules you set for a site's cookies to its local storage.
An important difference is that Firefox returns a site's cookies automatically with each request, while local storage is accessible only using JavaScript (or a plugin?) so people like me who use NoScript are blocking sites from using local storage by default.
Cookies are send with each request and have a limited size (4096), so are more likely a security/privacy issue (other servers see the cookies if the connection is not secure) and local storage can only be locally accessed via JavaScript and isn't send to the server. Cookies add to the amount of data send with a request and need to be processed by the server.
This website also uses local storage to store the state of collapsed items in the sidebar on pages like this.