[Ext] Cookie Controller, now with DOM storage

Announce and Discuss the Latest Theme and Extension Releases.
Locked
Grat2
Posts: 9
Joined: February 12th, 2015, 2:57 pm

Re: [Ext] Cookie Controller, now with DOM storage

Post by Grat2 »

it doesn't even ask any more (the ask-first pref is now default off)

Which one is it ? I only see 3 prefs related to IndexedDB in Firefox 35.

I noticed recently that setting dom.indexedDB.warningQuota to 0 doesn't mean you'll get a prompt when a website tries to store any amount of data no matter how low. And since we can't set dom.indexedDB.enabled to false without breaking stuff, we are open to anyone adding whatever they want regardless of cookie preferences and history cleaning.
So if you know of a pref to reinstate the prompt, I'm all ears!

The problem is that it uses an entirely separate permissions system to cookies and DOM storage.

At least for the allow/forbid part, can't Cookie Controller just tie cookies and DOM storage permissions together with IndexedDB through the Cookie Permissions button ?

I can see how using the Tidy Cookies button to deal with IndexedDB on top of cookies and DOM storage is more tricky, but UI wise, how about one more click with a new color and eventually a warning ? (Similar to when you warn about deleting *all* cookies globally)

What I mean is that IndexedDB is essentially very close to DOM (local) storage, and DOM storage is quite close to cookies, so it makes sense to have one add-on deal with all three at once instead of separating IndexedDB from the rest.


I agree that deletion is something to think carefully before implementing it, but permission seems like a no brainer doesn't it ?


Either way thanks for considering and good luck with all that e10s trouble :)
lithopsian
Posts: 3664
Joined: September 15th, 2010, 9:03 am

Re: [Ext] Cookie Controller, now with DOM storage

Post by lithopsian »

Try offline-apps.allow_by_default. I haven't looked into all the permissions settings in detail, but this should at least give you a prompt before anything happens.

Yes, indexedDB is almost intended as a replacement for DOM storage which has some distinct problems. Mozilla probably thinks one of the problems is that people can block DOM storage and easily delete it :( Certainly they are far more interested in having unknown code running all over your machine than thinking about the security and privacy implications. Having spent years trying to rid us of the scourge of malicious or just plain flaky addons (which are at least largely within the control of the user!), they seem determined to make things worse instead of better. This is all been driven by mobile, where for some reason people seem happy to let just about any piece of code have access to just about any part of their device, and have almost come to expect it. Sheer madness.

The functionality is a no-brainer, but implementing it is far more complicated than I think anyone realises. Even me! I could maybe try to use the existing UI to set indexedDB permissions, but they don't really match up to cookie permissions and there are inevitably going to be problems. I might try it as a first step and add another button it if just can't work that way. Also I don't yet really understand how the permissions are (or will be) applied differently to web apps and addons.
Grat2
Posts: 9
Joined: February 12th, 2015, 2:57 pm

Re: [Ext] Cookie Controller, now with DOM storage

Post by Grat2 »

Try offline-apps.allow_by_default. I haven't looked into all the permissions settings in detail, but this should at least give you a prompt before anything happens.

Even for normal websites using IndexedDB ? Nice, thanks, I'll give it a try :)

Mozilla probably thinks one of the problems is that people can block DOM storage and easily delete it

I think it's also because IndexedDB is way less confusing to use and scale up, i.e. to store large and numerous resources for games or complex apps. It's kind of problematic if those resources can be deleted easily, but Firefox's history cleaner feature has comprehensive lists of data types that can be deleted individually, so IMO IndexedDB should be in there, probably under the "Offline data" type, which I think doesn't get deleted by default until the user ticks the checkbox.


This is all been driven by mobile, where for some reason people seem happy to let just about any piece of code have access to just about any part of their device, and have almost come to expect it.

Yeah, that one is funny. I think it's slowly getting better on mobile, but slowwwwly and there's a long way to go. However, the situation clearly is degrading on desktop: All devices progressively get in sync in how they work and since mobile is terrible, I guess desktop mechanically takes a hit. Still, Firefox is way better than any alternative safe from Tor Browser, itself based on Firefox ESR.


The functionality is a no-brainer, but implementing it is far more complicated than I think anyone realises.

That's what I feared :)
Well good luck, I'll post relevant Bugzilla links if I find some that could help you get a better view on what needs to be done concretely.


Really, thanks again for your very useful and convenient add-on :)
Grat2
Posts: 9
Joined: February 12th, 2015, 2:57 pm

Re: [Ext] Cookie Controller, now with DOM storage

Post by Grat2 »

It appears that offline apps use AppCache instead of IndexedDB. AppCache (aka offline cache, I believe it's the same right ?) can be cleared and unless that Firefox|Advanced|Network option is buggy, the user is notified when it is used. That option affects browser.offline-apps.notify, so offline-apps.allow_by_default probably applies to the AppCache instead of IndexedDB.

It can get confusing but at least, I think we have it all:
Cookies
Dom storage (session and local)
AppCache
IndexedDB
lithopsian
Posts: 3664
Joined: September 15th, 2010, 9:03 am

Re: [Ext] Cookie Controller, now with DOM storage

Post by lithopsian »

So I ran some tests and dug into some code instead of just guessing, and this is all horribly broken. There are no quotas prompts at all in the beta version I have, although this is apparently fixed now. The warningQuota preference is no longer used, at all. The relevant prefs are now dom.quotaManager.temporaryStorage.fixedLimit and dom.quotaManager.temporaryStorage.chunkSize, but it isn't clear to me whether these actually control indexedDB at the moment. There are outstanding bugs related to that.

There is UI for controlling indexedDB access on the about:permissions page (helpfully labelled as "Maintain offline storage"), also available through the permissions tab of the PageInfo dialog, but it is difficult to know whether this is working correctly, or at all, with so much else not working. I can't even tell any more what it is supposed to be doing, let along what it is actually doing. Some of the quotes from Mozilla representatives in bugs relating to this are truly frightening, they simply don't care if users have information or control over this, or whether there are security or privacy loopholes.

Don't hold your breath for a comprehensive solution to this in Cookie Controller :( I might just add a global disable toggle for now, and let it break what it breaks until Firefox 37. This is currently controlled from about:permissions and it at least does seem to globally disabled indexedDB.

A few relevant bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1093646 fixed in some FF35/6 versions
https://bugzilla.mozilla.org/show_bug.cgi?id=968272 landed FF31
https://bugzilla.mozilla.org/show_bug.cgi?id=1083927 fixed for FF37
https://bugzilla.mozilla.org/show_bug.cgi?id=1119462 fixed for FF37
All open indexedDB bugs
Grat2
Posts: 9
Joined: February 12th, 2015, 2:57 pm

Re: [Ext] Cookie Controller, now with DOM storage

Post by Grat2 »

Sorry for the late reply.

about:permissions does do the trick to disable IndexedDB globally. (Maybe it disables other offline storage as well, I haven't checked.)
Unfortunately IndexedDB cannot be enabled on hand-picked sites yet it seems. I tested it on this page using Firefox 36 with global permissions denied by default but allowed on mozilla.net: It didn't work.

IndexedDB has been almost completely rewritten in Firefox since 2013 and user friendly functionalities are still a work in progress. Fortunately it's almost never used on the web so there is no tracking occurring yet, and once Firefox 37 is there it will not cause problems to just disable IndexedDB globally until Mozilla finally implements better user control, which I think is their intent.

My guess is that they postponed this precisely because IndexedDB tracking is not a threat today, but I don't like that reasoning, especially coming from a privacy-centred browser. I'll poke you again once Mozilla is ready. Thanks for your time :)
User avatar
cycletourist
Posts: 15
Joined: October 19th, 2003, 4:10 pm
Location: Colorado
Contact:

Re: [Ext] Cookie Controller, now with DOM storage

Post by cycletourist »

The domain localhost works fine in Cookie Controller. However, if I use another name for a local domain (development machines at home on my LAN), the cookie controller menus show a blank where it's name would be and I cannot control the cookie settings for that domain

E.g., I have a computer on my LAN named dave that is running Apache web server. I address the server on that machine as http://davehost/ (no tld). When I open pages at davehost, the cookie controller menus show a blank where "davehost" should be and I am unable to control cookie permissions for that domain (davehost).
lithopsian
Posts: 3664
Joined: September 15th, 2010, 9:03 am

Re: [Ext] Cookie Controller, now with DOM storage

Post by lithopsian »

I see the problem with "localhost" type domains. I think I can fix this by treating all single-part URIs in the same way. That is, not doing any fancy manipulation to them.
lithopsian
Posts: 3664
Joined: September 15th, 2010, 9:03 am

Re: [Ext] Cookie Controller, now with DOM storage

Post by lithopsian »

Version 3.9 should work better with local hosts that aren't "localhost". Let me know if there are still difficulties.
lithopsian
Posts: 3664
Joined: September 15th, 2010, 9:03 am

Re: [Ext] Cookie Controller, now with DOM storage

Post by lithopsian »

Is there anyone out there with a trackpad? How does Cookie Controller work for you? In particular, how do the ctrl-click, middle-click, right-click behaviours work. At best it seems the tooltips and instructions might be confusing for trackpads where ctrl-clicking simply emulates a right-click. At worst, this might be completely broken, but I don't have the hardware to test it.
allin
Posts: 2
Joined: June 10th, 2015, 12:23 pm

Re: [Ext] Cookie Controller, now with DOM storage

Post by allin »

Hello,
I can't help you with trackpads but i have another request.

I love this extension and I use it on every Firefox I use. I often reinstall my OS because I use testing versions of GNU/Linux and I always lose the Cookie Controller's settings. Could you please add a "backup" feature? And Import/Export feature that allows users to backup and restore their cookie preferences.

Thank you very much for your great work and this useful extension.
Grat2
Posts: 9
Joined: February 12th, 2015, 2:57 pm

Re: [Ext] Cookie Controller, now with DOM storage

Post by Grat2 »

Hi,

I have a Synaptics PS/2 Port TouchPad. CTRL+LeftClick has no effect on the Cookie Permissions button, and seems to have the effect of a regular left click on the Tidy Cookies button. It's basically the same behaviour as my USB mouse in both cases.

Right clicking has the same effect as with a mouse as well, and I have no middle click.

About v3.10, could you elaborate on what you did ? It seems that you removed the "Individual file permissions" option from the Cookie Permissions button, an option that was disabled by default, and enabled its effect in 3.10.
So what does it do exactly and why has it become necessary for Firefox 21 and up ?


Thanks!
lithopsian
Posts: 3664
Joined: September 15th, 2010, 9:03 am

Re: [Ext] Cookie Controller, now with DOM storage

Post by lithopsian »

File permissions have always been a bit of a hack in Firefox. Web pages in local files don't have domains so they don't fit into the permissions scheme used for http addresses. At first, Firefox added a magic string "<file>" to add permissions exceptions that would apply to all local files. Not ideal but sufficient for most of the few people that needed this feature. Then they added the ability to have different exceptions for individual files, and I added this as an option in Cookie Controller. Now they have taken away the ability to set "<file>" permissions, although for now existing "<file>" exceptions do continue to work. I've taken that feature out of Cookie Controller since it isn't supported any more. Fairly soon, "<file>" will stop working although I don't think the people who are working on the particular bug I'm following have realised it yet.

So what does that mean for you? If you have web pages stored in files instead of at web addresses, you might have set permissions for them. Unless you were deeply into this, you probably just got the magic "<file>" and all local files get the permission. If you add or remove a file permission in Cookie Controller 3.10 it will only apply to the exact file that you have open. It means file permissions now behave a little more like web page permissions. In a Firefox release coming to you soon, existing permissions you have set for files using the magic string will stop working and you'll have to set permissions individually for every html file. For now, although Cookie Controller won't do it for you, you can still add an exception for all files manually by entering <file> in the Exceptions... dialog, although Cookie Controller may remove it if you play around with file permissions.
lithopsian
Posts: 3664
Joined: September 15th, 2010, 9:03 am

Re: [Ext] Cookie Controller, now with DOM storage

Post by lithopsian »

I'm not sure that the Synaptics PS/2 Port TouchPad behaves like a Trackpad, but anyway you've brought up some interesting points. Ctrl-clicking on the Trackpad often (always?) behaves like a right click because Apple designers decided it would be "cool" not to have buttons and there's only so many ways most people can tap on it. There is a weird double-finger tap that can be a different sort of click, then maybe you can have ctrl-click do something else, but most people don't go there.

I didn't realise that ctrl-click on the Tidy button did anything. It doesn't do anything special, but it does work just like a left-click. Or right click.

Ctrl-left-clicking on the Perm button *should* do something special. If you don't currently have an exception set for that web site, it should set the default exception *temporarily*. Temporarily usually means until you close or restart Firefox, although there are hidden preferences to set timed exceptions. It also works on the permissions on the menu. If you have an exception set already, ctrl-clicking does nothing because you can't temporarily remove an exception. Maybe it should do something, be a normal left-click like on the Tidy button?
lithopsian
Posts: 3664
Joined: September 15th, 2010, 9:03 am

Re: [Ext] Cookie Controller, now with DOM storage

Post by lithopsian »

I'll put import/export on the to-do list. It seems simple but would actually be pretty messy. Grabbing all the relevant permissions and exceptions to export without grabbing stuff that isn't related to cookies isn't as obvious as it could be. Importing them again runs the risk of destroying permissions that are important. Not completely replacing existing permissions could be extremely confusing, because having exceptions at different levels of the same domain causes immense headaches (not for Firefox, but for people trying to understand why cookies can or can't get set).
Locked