In my web-extension forget me not, I’ve just added an experimental feature to block thirdparty cookies before they are being set:
https://addons.mozilla.org/en-US/firefox/addon/forget_me_not/
Not sure how much this will affect performance tho.
I’m thinking about expanding this to block blacklisted cookie domains as well, but since a black list doesn’t exist yet, a definition of how a black list should work needs to be discussed.
Feedback is very much appreciated.
Thanks in advance.
A blacklist is easy to implement. You could define a blacklist just with an array that you store in browser.storage.
When you add a domain to the blacklist :
list.push(myurl);
When you want to know if the domain is blacklisted :
list.find(url => (url==myurl)); or use a custom comparison function
When you remove a domain from the blacklist :
list = list.filter(url => (url!=myurl));
I use that for my addon https://addons.mozilla.org/firefox/addon/scriptfilteraddon/.
Thanks, but I know how to implement a blacklist… I just don’t know yet how I want it to behave.
Questions that I ask myself are:
For your information, my rules allow wildcards, i.e. you can write *.google.com or hello.*.com or amazon.*, so it’s quite easy to have multiple rules match a domain
Some websites might require cookies to work so it should be better to delete cookie after tab close, or beter, add different levels of restriction where first level will enable cookies, second level delete cookies after tab close, and third disable cookies.
The white list is the most restrictive. This is the better choice if your addon is intended for a company for example. Otherwise, for an inexperimented user, the black list is more convenient.
I think you have the wrong idea about my add-on. I already have white and gray lists implemented.
Another list (red) is currently in beta to override the other rules.
white: keep cookies as usual. gray: keep until browser restart. red: ignore white and gray rules.
default behavior for domains not in the list or red listed items is to remove cookies when all instances of that domain have been left.
Example: user adds a whitelist rule for * to allow all domains, then he can add red rules to make exceptions for certain domains, which will invoke the default behavior from above.
I know some cookies are required for some websites to work. That’s what whitelists are for.
I’m currently evaluating if a new rule type blacklist would make sense to deny cookies from domains where you know you don’t want them.
Ah ok I see, so what you call white/gray/red list are a kind of restriction level that I mentioned previously. In fact, there is only one list and each item contains a restriction level. Is it correct? Or do you really implement 3 seperated lists in your code?
No, you are correct. There is only one list.
An entry in the list consists of an expression (for example *.amazon.com) and a rule type/color.
Nice. I think adding a new restriction “black” which completely blocks cookies is effectively a good idea.
Thanks. Since red is now a type too, it’s much clearer how black should behave. I’d say black > red > white > gray should be the order of importance.
Should not gray be more important than white?
I’m actually not too sure yet on that one. I started with white > gray, as other extensions did it this way.
Maybe this is not something that can be easily said and needs to be configurable.
I have no use-case which demonstrates the need for either one to be more important. Do you?
The problem is that if white > gray, you can’t add a rule “*” in white in order to have cookies enabled by default and then add gray rules.
I wanted to say that is the same if you want to add a * rule for gray and then add white rules, but that can be done by just disabling the cleanup-on-domain-leave option.
This is a very generic case tho… what if the rules a bit more specific. like *.google.com for gray and mail.google.com for white.
So here it is better that mail.google.com overrides *.google.com rule.
Just a question, how do you manage the storage of your url list? In my addon, I use for now browser.storage.local but, as it will be compatible with Firefox Android 59, I would like to use browser.storage.sync for next versions. However, I found some cases to take into consideration for syncing and I don’t know how to solve them in my code.
Here are the different cases :
I’m currently using local storage in both of my extensions.
When converting my first extension to webext, I tried using sync, but it kept crashing, so I stopped using it.
If, at some point I chose to use sync, I would have to keep storing some things in local (for example the list of domains to clean on startup).
Obviously, there is an issue with storing the list when multiple devices add or remove entries.
I guess I would keep the current list in local storage and then create a map of lists in sync storage.
This map of lists in sync would need some unique ID for the device as the key.
Each device would then store the action (like create, update, delete) together with a timestamp in this device specific list, so when a sync update has been received, these changes can be easily merged as needed, maybe with user permission.
Not sure if there is such a device specific unique ID tho… I haven’t had the time to research it.
This is an interesting solution. 
Sync API seems finally quite difficult to implement. A tutorial and a demo on MDN would be very helpful.
All storage APIs have the same API interface, so interacting with them is equivalent, no matter if it is local, sync or managed storage.
I agree with you but, as they are used for different purposes, for example local is for storing data on one device whereas sync is for syncing data between two or more devices, the problems you have to solve are different and so the code implementation is more complex.