DOM.storage.enabled necessary for several panels

uli · 2018-03-20 11:28:40

Playing a little with the 4.7 admin UI, I noticed that since 4.7 there are some changes in behaviour for certain, cookie-based, elements: The state of all UI elements controlled by “Expand all/Collapse all” links aren’t remembered any longer like in 4.6. Being bitten once, I suspected it had to do with local storage, and right so: When dom.storage.enabled is set to true, everything around remembered setting in these panels is functional again.

Is there a compelling reason to switch to using local storage and not use cookies any longer?

Turning local storage off is a measure for sheltering privacy, so that it’s not too easy for certain invasive websites to identify users and collect, agglomerate and sell our data, and we can’t turn that off only for certain websites, we’ve to turn privacy on/off globally, and I’d really like to to keep this feature turned off. (And I can tell you, you’re not suffering generally when local storage is turned off! :)

Bloke · 2018-03-20 11:48:40

Hmmm, I would expect localStorage to be able to be toggled per site. You can opt in to all other things per site – cookies, dekstop notifications, login credentials, location info, etc – so why is this feature special? Weird browser manufacturers. It ought to be on/off/let-me-choose.

That said, the reason we use localStorage over cookies now for panel-related stuff is that it’s easier to control per device, not per login. So if you edit your site on a mobile device you don’t have to reconfigure the UI to hide stuff that you only want to see on desktop, and vice versa. Really handy for showing only certain table columns per device.

Could we fall back on cookies if localStorage is off? Probably. Should we? Dunno.

Last edited by Bloke (2018-03-20 11:50:15)

etc · 2018-03-20 12:03:30

AFAIR (might be outdated), forbidding cookies for a site disables Storage. And cookies are worse than storage, so @uli you are surely using a whitelist. ;-)

Bloke · 2018-03-20 12:13:01

etc wrote #310153:

forbidding cookies for a site disables Storage.

So the implication is that if you’ve allowed cookies for a site, then localStorage is also allowed?

Cookies need to be on for the domain in order for Txp to function (otherwise you’d have to log in again for every action) so if that’s the case, why is Uli not seeing localStorage being stored as well?

What browser is this, btw?

EDIT: I found a resource that implies localStorage is unique per protocol, host & port so there must be a mechanism to control it at that level. It makes sense for browser manufacturers to bundle it with the cookie settings as it’s all related to “allow this site to store stuff about me in some way”.

Last edited by Bloke (2018-03-20 12:18:17)

etc · 2018-03-20 12:17:48

Bloke wrote #310154:

So the implication is that if you’ve allowed cookies for a site, then localStorage is also allowed?

If it is allowed globally. The main point is: cookie not allowed => storage not allowed, but not other way. So it suffices to allow storage globally and use a whitelist for cookies (which is a good practice anyway).

Cookies need to be on for the domain in order for Txp to function (otherwise you’d have to log in again for every action) so if that’s the case, why is Uli not seeing localStorage being stored as well?

Because he has disabled it globally.

Another reason to use localStorage is that for some actions (e.g. columns or tab hide/show) you need to send a request with cookies (to store the preference in db), but not with storage (stored locally). So it’s faster on a slow connection.

Bloke · 2018-03-20 12:20:01

Right. Makes sense. Solution: enable it globally, control it per domain via browser cookie settings.

phiw13 · 2018-03-20 12:36:07

Bloke wrote #310154:

So the implication is that if you’ve allowed cookies for a site, then localStorage is also allowed?

Cookies need to be on for the domain in order for Txp to function (otherwise you’d have to log in again for every action) so if that’s the case, why is Uli not seeing localStorage being stored as well?

What browser is this, btw?

It is Firefox, a hidden pref in about:config (DOM.storage.enabled). And yes that is a global setting. As Oleg notes, you can block it per site (allow/disallow cookies…) but that is something hard to use for the average person. The preferences settings in Firefox 59 are a little clearer about that.

(Maybe the Firefox people should go spying a little bit what Safari’s Intelligent Tracking Prevention does. It seems to work fairly well in terms of blocking (minimising) third party tracking. Ok, it helps to have a Content Blocker as well.)

Bloke · 2018-03-20 12:52:50

I seem to recall last time I went to about:config (a long time ago) there was a message about “There be dragons”. Perhaps this is one such dragon Uli shouldn’t have woken ;-)

etc · 2018-03-20 13:07:45

phiw13 wrote #310158:

It is Firefox, a hidden pref in about:config (DOM.storage.enabled). And yes that is a global setting. As Oleg notes, you can block it per site (allow/disallow cookies…) but that is something hard to use for the average person.

An average person should fear cookies/JS at least as much as Storage. And there are few extensions that can help.

uli · 2018-03-20 18:56:15

etc wrote #310162:

And there are few extensions that can help.

I’ll see how mine and this here …

Bloke wrote #310156:

Solution: enable it globally, control it per domain via browser cookie settings.

… can play together. Thanks!

phiw13 · 2018-03-21 05:23:53

uli wrote #310167:

I’ll see how mine and this here …

… can play together. Thanks!

Let us know how it turns out…

(my first step when setting up Firefox: disallow third-party cookies)

etc · 2018-03-21 10:34:28

Cookiebro works quite well and includes a cookie editor, for extra powa.

Textpattern CMS

Textpattern CMS support forum

#1 2018-03-20 11:28:40