Interested in testing experimental cookie blocking features?


In my web-extension forget me not, I’ve just added an experimental feature to block thirdparty cookies before they are being set:

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.

(Baptiste Thémine) #2

A blacklist is easy to implement. You could define a blacklist just with an array that you store in
When you add a domain to the blacklist :
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


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:

  • Remove blacklisted cookies after tab close and browser restart?
  • Or completely block blacklisted cookies from ever being set?
  • What list has more weight? If a domain matches white, gray and black rules, then what should it be considered as?

For your information, my rules allow wildcards, i.e. you can write * or hello.*.com or amazon.*, so it’s quite easy to have multiple rules match a domain

(Baptiste Thémine) #4

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.

(Baptiste Thémine) #6

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 * and a rule type/color.

(Baptiste Thémine) #8

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.

(Baptiste Thémine) #10

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.

  • Does a user create a generic white rule and then wants to override with a specific gray rule?
  • Or does the user create a generic gray rule and wants to override with a specific white rule?

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?

(Baptiste Thémine) #12

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 * for gray and for white.

(Baptiste Thémine) #14

So here it is better that overrides * rule.
Just a question, how do you manage the storage of your url list? In my addon, I use for now but, as it will be compatible with Firefox Android 59, I would like to use 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 :

  • Firefox Desktop stores the list in sync. Firefox Android is not connected to sync but some urls are added to the list in local. Once Android is connected, does sync should override local (and I lose data) or merge?
  • Firefox Desktop is not connected to sync and I remove some urls from the list in local. Once Desktop is connected, does local should override sync or merge (and I lose last deletes)?
  • Worst case, if the two situations above happen at the same time i.e. I use my Android and my Desktop at the same time offline, which list is the most up to date? and how to update the two lists?
  • If I introduce sync in next versions, how to merge the two local lists?


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.

(Baptiste Thémine) #16

This is an interesting solution. :thinking: Sync API seems finally quite difficult to implement. A tutorial and a demo on MDN would be very helpful.

(Martin Giger) #17

All storage APIs have the same API interface, so interacting with them is equivalent, no matter if it is local, sync or managed storage.

(Baptiste Thémine) #18

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.