Blocking DOM storage with ABE?

[aloishammer]

It appears to me that aloishammer wants twitter to be able use offline/DOM storage, but no other site should even be allowed to ask. Good luck with that.

That would be ideal; I assumed ABE would be the best bet to achieve that. Being able to disable DOM storage while still having #NewTwitter work seems even better, of course.

After looking over the recent (last year or so) apparent lack (loss?) of interest in regular security testing of at least some of the largely unused HTML5 capabilities in the Firefox codebase-- I'm not implying other browsers are different --I'm more than a little worried. The bug al_9x kindly pointed to seems to bear out at least some of my worry about HTML5 in Fox not having real field testing.

I expect to be relying on NoScript to save my (our) bacon. Again.

[al_9x]

No, I'm not mixing it up. Toggling dom.storage.enabled to false disables offline storage completely. The demo link I provided fails if dom.storage.enabled is toggled to false. I'm not referring to the cache. When Firefox refers to "data for offline use" in Options > Advanced > Network, it's referring to DOM storage. Setting dom.storage.enabled to false disables storing "data for offline use" completely.

Create a new profile, set dom.storage.enabled to false and load your link. It will still ask you, and if you allow, will store the data. (checked on fx 3.6.10 on xp sp3)

"offline storage" and "dom storage" are different technologies controlled by different settings.

"offline storage" is controlled by browser.cache.offline.enable and browser.offline-apps.notify, setting notify to false will turn off notification and also prevent storage.
"dom storage" - dom.storage.enabled

[Alan Baxter]

Thanks for bearing with me, al_9x. I thought they were the same thing, but your explanation and a little more research on my part indicates that they're not.

@aloishammer:
Disregard what I said about controlling DOM storage for individual sites from Options > Advanced > Network. Those options may not control DOM storage after all. It looks like DOM storage permissions follow the cookie prefs instead. Bug 341524 – Make webapps session storage follow the cookie prefs

No, I'm not mixing it up. Toggling dom.storage.enabled to false disables offline storage completely. The demo link I provided fails if dom.storage.enabled is toggled to false. I'm not referring to the cache. When Firefox refers to "data for offline use" in Options > Advanced > Network, it's referring to DOM storage. Setting dom.storage.enabled to false disables storing "data for offline use" completely.

Create a new profile, set dom.storage.enabled to false and load your link. It will still ask you, and if you allow, will store the data. (checked on fx 3.6.10 on xp sp3)

You're right. The offline data is stored even though dom.storage.enabled is false. But the example site doesn't display or allow you to edit the data unless dom.storage.enabled is true. That added to my confusion: it seemed to support my conflating DOM with offline. Why do you think that site needs dom.storage.enabled to be true to work properly?

[al_9x]

Why do you think that site needs dom.storage.enabled to be true to work properly?

It's using both, offline storage to make the app available offline and dom storage for its data (tasks created while offline).

[Alan Baxter]

Why do you think that site needs dom.storage.enabled to be true to work properly?

It's using both, offline storage to make the app available offline and dom storage for its data (tasks created while offline).

Hm, I see. Thanks.

[MeltingPoint]

@Giorgio this may be worth including (in a more universal form)

Code: Select all

user_pref("noscript.surrogate.localStorage.sources", "@^https?:");
user_pref("noscript.surrogate.localStorage.replacement", "try { window.localStorage; } catch(e) { __defineGetter__('localStorage', function() {return null;}); __defineGetter__('sessionStorage', function() {return null;});}");

Thanks very much, fixed YouTube not showing thumbnails of videos. I just can't imagine the average user spending the time I did to figure this out - thank god for people like you and Giorgio

[al_9x]

3.6.13 will fix this: https://bugzilla.mozilla.org/show_bug.cgi?id=599479