discussion: section persistent [web] storage items

[Thorin-Oakenpants]

snip

[Atavic]

NOTE: C-AD is Cookie AutoDelete (a webextension).

[crssi]

Those persistent cookie are typically stored in IndexedDB, which can be effectively cleaned by Cookies Exterminator addon.
Note: Cookies Exterminator will work until FF 57+, after that we can hope mozilla will resolve the APIs, which Cookie AutoDelete or CookiErazor can use to deal with those.
In the past (before FF 55 or 54... can't remember now) SDC dealt perfectly with those, but is obsolete now.

[crssi]

Sure... I have mention the working solution at this point for anyone interested (IMHO it is worth to mention) and elaborated further in the "Note" section of my response.

Now I will hide my head in the sand. ;)

[earthlng]

• 1398303 Local Storage not cleared by Clear Recent History

the example site weather.com uses IDB and the 5. step in his steps to reproduce is "Go to weather.com again and wait a little bit." - "wait a little bit" most likely because it restores the locations from the IDB and stores it in LocalStorage again. Local Storage is most definitely cleared by clearing recent history (cookies is enough actually) - you can check the webappsstore.sqlite file if you don't believe me.

[earthlng]

should we create a persistent [web/content] storage section ❓ No-one has commented on that in 6 days since I proposed it

yeah sorry about that. Sure, I am not against that but with all these issues at the moment maybe it would be better to wait for a while. Otherwise there would need to be a lot of text and it could easily end up being way too confusing.

[2glops]

A persistent "storage and memory" section is a good idea.
Many issues there, but the actual main goal of that section should be identify and group all items related to browser storage.

[ghost]

Concerning LocalStorage I read here the developer of the Firefox Cookie Controller add-on state:

Lastly, there is a limit on the amount of storage that can be used by each web page. By default this is 5MB but you can change it, potentially to zero. However, web pages don't always handle overflowing this quota very well so you might cause problems by changing it.

The setting for this is dom.storage.default_quota

1- I'd like to know your opinion regarding the fact web pages don't always handle overflowing this quota very well.
2- Would it be pertinent to add to section

/* 2705: disable DOM (Document Object Model) Storage
 * [WARNING] This will break a LOT of sites' functionality.
 * You are better off using an extension for more granular control ***/
   // user_pref("dom.storage.enabled", false);

the following setting:

// amount of storage that can be used by each web page
// user_pref("dom.storage.default_quota", 0);// Default=5120 (5MB)

Of course it's possible to use a dedicated add-on (or even as I used to, a dedicated Custom Button) but this requires a per-site user intervention since Firefox doesn't handle this on per-site. On another hand setting dom.storage.enabled to false is indeed problematic. I'm trying right now with the above dom storage quota set to 0, testing here and there sites I know that use LocalStorage, and no problem. YouTube for instance stored nothing when otherwise it does.

[ghost]

Yeah, the IndexedDB odyssey, the fact of visiting a site such as bostonglobe.com with cookies set to site and session only and notice in the Page Info / Permissions / Maintain Offline Storage filled with 48kB of data, removing it and blocking the site, reopening the site to notice the 48kB are back: yeps I experienced that as we all. Ghacks has a dedicated article on this.

I managed a work-around by associating two add-ons : Permit Cookie 2 (legacy add-on) and Cookie Autodelete. I've uninstalled Self-Destructing Cookies add-on not because it is a legacy add-on but because Cookie Autodelete being a Webextension it will run its cookie management database seperately, and that can be an advantage:

I've set network.cookie.cookieBehavior to 2 (=disallow all)
From there on Cookie Autodelete has nothing to perform ... except if a site either requires a cookie to simply open (few, but some do!) either because I need to login.
If cookie required, I make a session exception for that site with Permit Cookie 2

• without setting that site's cookie permission in Cookie Autodelete if I wish not the cookie to be kept once the site closed,
• by adding a cookie permission (session or keep) in Cookie Autodelete otherwise.

All this rather than only Cookie Autodelete only because whatever site, if cookies are not blocked (blocked for that site anyway) are at this time enabled to lay their data in my profile / storage folder, and I refuse that.

The LocalStorage is less problematic in that the storage will be persistent only if the site is allowed to use a persistent cookie. In my scheme I face a site laying IndexedDB data in my storage folder only if I've set a cookie exception (session or persistent) and that the site is an IndexedDB aficionado.

Not to mention that blocking all cookies with exceptions is a pleasure when visiting sites that install cookies for no valid reason, and even edit them live as bostonglobe.com does : listen, I still use an add-on called 'Noise' and it includes two Event topics (via addObserver), the cookie-rejected and cookie-changed events : I check these two events for testing, visit a site such as bostonglobe and hear the cookie(s) modified as I scroll! The site is actually updating live its cookieon every line I scroll!.

So, altogether, this combination of two add-ons, one (legacy) handling cookie exceptions on Firefox's level, the other, Webextension, handling cookies' exceptions within its own database, allows to fine tune cookies and therefore storage, globally since all seems to depend of the cookies behavior permission. That's how I do it until Mozilla gets things in order.

[ghost]

I've been experiencing with:

user_pref("dom.storage.enabled", true); // Default=true
user_pref("dom.storage.default_quota", 0); // Default=5120

Quite nice. Many sites block with dom.storage.enabled set to false but not with dom.storage.default_quota set to 0, especially those which don't actually write Web Storage data but require nevertheless storage as enabled. Youtube for instance does write Local and Session storage but runs fine with the quota set to 0. Userstyles.org as well except that it won't handle the screen display functionality (two top-right buttons) with quota set to 0. Even ProtonMail runs OK: it displays a message stating dom storage is required but runs nevertheless fine!

For whome may be interested to know what Local and Session storage is used by a site, there's the localStorage inspector bookmarklet which delivers that information flawlessly.

Indeed, as mentioned in the user.js concerning dom.storage.enabled,

You are better off using an extension for more granular control

but the point is, if controlling with an extension (or with a dedicated Custom Button as I do) the dom storage feature, switching dom.storage.default_quota from 5120 to 0 seems to be far more practical then switching dom.storage.enabled from true to false, given many sites won't block systematically.

[crssi]

Just FYI

With

user_pref("dom.storage.default_quota", 0);

videos on imdb.com does not work.
But they work when set with a little as 1.

[ghost]

I am considering dom.storage.default_quota as dom.storage.enabled is considered in our user.js, that is to either keep the default value either to tune on a per-site basis with an extension. I'm evoking the quota=0 as a replacement value to its default 5120 in the context of a per-site permission to switch back to 5120.

Example:

• I've set dom.storage.default_quota to 0
• I've installed a toolbar button crafted with the Custom Buttons add-on to toggle the above quota between 0 and 5120
• I know the few sites which require quota=5120 and I click the button accordingly to toggle to 5120. I toggle back to 0 once I've left the site.

Of course it would be as an aberration to set the quota to 0 for everywhere as it is to set the dom storage to disabled ... unless granular control is made available.

[ghost]

My point is to replace what was performed with the Self-Destructing Cookies legacy add-on but not handled by a Webextension : remove what has been set in the users localStorage once the site is closed, as performed with non whitelisted cookies. Cookies is easy, the Cookie Autodelete webextension does it, but doesn't handle the localStorage.

Nothing complicated in fact, unless to consider that the aim of clearing DOM storage set by a site is excessive given that DOM storage won't be readable by a 3rd-party site if 3rd-cookies are forbidden, that sessionStorage vanishes and that localStorage is persistent only if a site has been set in the user's cookie whitelist.

My aim is to have the DOM storage set by a site cleared once the site is closed. The aim is arguable but the way to achieve it (now that Webextensions cannot) seems to me interesting, and I happened to believe that squeezing privacy concerns was the very lot of our common concern here.

[crssi]

But they work when set with a little as 1

This is just observation notice, I am using default. ;)

[ghost]

if you used my strategy of default deny cookies (and even using one off PB windows as needed) then there is no need to clear anything.

I deny cookies as well (network.cookie.cookieBehavior = 2) but some sites won't even open if cookies are denied (for them since globally) ... that means such sites need at least a session cookie exception. OK. From there on an extension such as Cookie Autodelete will delete the cookie once the site is closed. OK. Problem is sites with cookie not forbidden (session or allow) have the ability to store IndexedDB data in the user's profile storage subfolder (I take the example of bostonglobe.com but truth is not many sites jymp on that possibility) and that forbidding offline storage for such sites will have been the issue until coming Firefox 56.

Concerning DOM storage looks like I've mistaked, indeed. No point in emphasizing on a no-problem.
I have gotten saturated with non-controlled storage and the way of dealing with it. Looking forwards to these issues announced as resolved in Firefox 56/57.