Announce and Discuss the Latest Theme and Extension Releases.
I know there are loads of cookie extensions already but none of them quite did what I wanted, and the ones that were close didn't work the way I liked. So I wrote my own
Please welcome the Cookie Controller
At the moment it is two buttons that you can configure to where you like. The idea is that the buttons do exactly what you want just by clicking them once, no dialogs and no menus, but there are context menus that provide finer control if you need it.
One button turns cookies "on" and "off". You decide what on and off mean, but the default for off is to block all cookies and the default for on is to allow cookies just for the session. My idea was that this allows you to browse with cookies off, but turn them on temporarily if some website doesn't work properly. The button can be set to revert automatically to on or off at startup if you might forget.
The other button indicates and controls cookie permissions for the current page. There are four levels of permission based on whether there are exceptions for the current host: no exceptions means the default permissions apply; an allow exception means all cookies are accepted; a session exception means cookies are accepted just for this session; and a block exception means that no cookies are allowed for this page. The extension understands permission exceptions at the domain, subdomain, or superdomain levels, but it won't allow you to add or delete exceptions at superdomain level. Clicking the button just turns permissions on or off for the current host by adding or removing exceptions, the tooltip or context menu will tell you exactly what the button is going to do.
I think this is all very simple and useful. Next I'm looking at whether to add functions for deleting existing cookies. The whole point of the extension is not to ever store cookies that you might need to delete, but I know people are going to ask for this. I'm not sure whether to add a completely separate button or an entry on the context menus. I'm thinking that it might be nice to list the existing cookies for the current domain so that they could be deleted individually, although cookie names are not very transparent and it may be confusing which are host cookies and which are domain cookies. Someone has already asked for the ability to delete all session cookies, although I can think of a very simple way to do that without an extension
Last edited by lithopsian on December 15th, 2011, 1:25 pm, edited 1 time in total.
New version, new button. Version 0.3 includes a Tidy button which has functions for browsing and deleting cookies. You can browse through a tree of cookies for the current domain and delete individual cookies. There are also commands to delete all cookies for the domain, just session cookies for the domain, all session cookies, or every cookie in Firefox (be careful!).
If you don't need the third button for one-click deleting then the same functions are on the other two buttons, although you can hide them if you don't need them or prefer to use them from the Tidy button.
The Mozilla review queue seems to be getting longer, so I don't know how long version 0.3 will be stuck on the all versions page before it is reviewed.
Thoughts for the next version:
- same functions from the tools menu;
- display more information about each cookie;
- more categories of cookies to delete?
thank you for your addon.
I am using it since the first version and had no problems with it.
That's great. I've had some styling issues from Windows users where the radio buttons don't line up right. I think they are now fixed, but there are so many variations and themes. I'd like to hear from others that see funny things on the menus.
Native Linux radio buttons seem to work OK, but I have no idea about Macs.
I added support for the hidden preference network.cookie.alwaysAllowSessionCookies in ver 0.4. Of course Firefox supported it already, but now Cookie Controller understands it and explains it to you in the tooltips. It can also be configured as the on or off state by checking both Ask and Session, which were mutually exclusive before. It was a little tricky to debug all the combinations with this preference, but it is very simple to use and the tooltips fully explain the more complex configurations that can be produced. Basically this preference only does anything if you get asked whether to accept each cookie, and then session cookies will automatically be allowed without asking.
I'm also looking at the new hidden preference network.cookie.thirdParty.sessionOnly. This would be extremely simple to add to Cookie Controller but could be very confusing to use and understand. You can get strange things happening, such as third party cookies being accepted silently while first party cookies produce an ask dialog. It almost allows you to have completely separate behaviours for first party and third party cookies, although there are a few combinations that can't be set. It would be simpler if you could have completely independent settings for first and third party cookies instead of two overlapping but different mechanisms but that probably won't happen. Mozilla is looking at a completely new way to configure cookie permissions, based on the idea that the permissions for a third party cookie should depend both on who the first party is and who the third party is. Good idea but the devil is in the detail.
Is this open source? If so: what is the license? Where is the code hosted?
If not: can you make it so? Preferably with a BSD or MIT license? Could you please host it on GitHub?
(I've got a bug I'd like to patch, but I don't know if/where the source is.)
If there is a bug I'd like to fix it in the released version, although obviously you're welcome to fix it immediately in your own copy. Or you can branch a completely new addon if you want to make radical changes, not that there is anything special in there that you won't find anywhere else.
Who is interested in DOM storage? It is considerably less of a privacy risk than cookies due to strict scoping rules and the dropping of plans for "public" TLD storage. Also, it is hardly used by any web pages yet, perhaps because they can't do "naughty" things with it Still, it would be trivial to have Cookie Controller turn it on and off, and possible to display at least some of the stored information (potentially several MB of information per host!). Deleting all DOM storage is very easy and it would be possible, although not easy, to selectively delete it.
Well, I am
Would you mind explaining what that exactly means? Or could you provide some links?
From what I've read DOM storage is as problematic as cookies if it comes to privacy. It adds to the footprint of your browser.
Implementing that would be highly appreciated although I wonder how you do that since it's stored in webappsstore.sqlite which is locked while FF is running, AFAIK. Version 1.0, which I've installed today, says that initial support for DOM Storage permissions is included. I only found the entry Supercookie in the Cookies Toggle Button - does this refer to DOM storage? (I guess it does.) How is it possible to generally block DOM storage but allow it for specific sites? Or is the permission for DOM storage tied to cookies permission for a site (no/session/permanent)?
As I've been using Cookie Controller only for about 30 minutes (I had been using Cookie Monster for years) I can't deliver a final judgement yet But it looks certainly very promising, and if you implement a complete DOM storage control this would be fantastic as no other FF addon offers that, IMHO, since BetterPrivacy dropped it some time ago. Thank you for this interesting addon
I'm guessing you're German I'm told that Supercookie is the appropriate translation for DOM Storage. Certainly it describes it quite well.
You are correct about the current released version, it just has the one menuitem about DOM Storage and some tooltips. However, much of what Cookie Controller does also affects DOM Storage. That particular menuitem completely turns off all DOM Storage, but even when it is enabled the same restrictions are applied as to cookies. So if you have cookies denied then DOM storage is also denied. Adding an exception for a site also allows DOM storage for that site. All this will be much more apparent in the next release out in a few days.
Also in the next release will be the ability to view most DOM storage items and to remove them, individually or altogether. There are currently a number of bugs in Firefox and this isn't going to be perfect but I think it will be valuable. For example, local storage set by an https site throws an error when it is accessed from chrome, and session storage is not deleted when Firefox says it is.
You may also be right that DOM storage presents a considerable privacy risk but for the moment not many sites are using it. The management interfaces in Firefox are very poor though, so you might consider that an even greater risk because it is not possible for most people to even know if a site is storing this type of information. Firebug will show some of them (but not from https sites) but that is hardly a solution. You can look at some of them (but not session storage) directly in sqlite but that is not practical for most people. For something that allows a website to store megabytes of information, it really needs to be a little more exposed to public gaze.
I think my comments about scoping and TLD storage are valid. DOM storage areas are restricted very specifically to the scheme, host, and port. They simply don't exist for any other connection, and are even difficult to get to for an extension. There is some wiggle-room for accessing an area from an iframe but even that is heavily restricted. Firefox initially supported a form of DOM storage called global storage, which was like a giant hash table of storage areas where a web site could access any storage area for any parent domain, up to and including the top-level domains like .com. Mozilla didn't support TLD storage areas because of security concerns and it was dropped from the spec. The entire global storage concept is now deprecated and will be dropped completely somewhere around Firefox 11. Cookie Controller won't be including any support for global storage.
I admit it
I wasn't aware of that but https://bugzilla.mozilla.org/show_bug.cgi?id=341524 confirms what you're saying. Thanks for pointing to that connection
I'm looking forward to your next release - sounds very good! Will it also allow controlling local storage on per-site basis?
Yes, I found a hint on https://developer.mozilla.org/En/DOM:St ... balStorage and Dan Veditz's comment on http://ejohn.org/blog/dom-storage/#postcomment
Thanks, good to know! Do you have a link regarding FF 11?
Local storage can be controlled on a per-site basis using cookie exceptions. It obeys cookie exceptions just like it obeys other cookie permissions. This is also reflected in the next release which is now being tested and getting translations done. Cookie Controller will allow you to delete all DOM storage for a site, or all cookies for a site, but it won't be able to set different exceptions for cookies and DOM storage for the same site because Firefox doesn't support that.
Okay, understood, although it's a pity.
The German translation is in so I've uploaded a beta for you to play with. I am seeing a few quirky things going on with the DOM storage but so far I'm putting it down to what Firefox itself is doing.
Thanks a lot! However, the "Supercookies" entry is greyed out (contrary to version 1.0). Thus, enabling/disabling DOM storage is no longer possible ...
Who is online
Users browsing this forum: Google [Bot] and 1 guest