Hi, thank you for your review;

you talk about a feature that I had to remove to fix a bug ( https://bugzilla.mozilla.org/show_bug.cgi?id=1465063 ) in Firefox that will be corrected on version 62 (Sept 2018). I could have kept it but cookies with the First-Party Isolation flag could not have been managed by my application. The addon is already ready for version 62 of Firefox on which the feature will reappear ;)

Hi, you are the second person to report this behavior.

I talk about it on the issue https://github.com/ysard/cookie-quick-manager/issues/23.
Maybe this behavior is due to the version of Firefox you are using (developer version ?) and therefore to a modification of the API not yet present on the current public version (60.0.1).

Hi, thank you for your comment !

About the preservation of cookies: The browser uses a different internal API when you delete cookies from settings or on restart. So, no signal is emitted and my addon can not restore for the moment a cookie in this case.
I will work on it, but one solution might be to store protected cookies (not just their names) in a separate database. But the purpose of the addon is not to rewrite the full Firefox's cookie management...

Finally you can use the umatrix addon to delete session cookies at regular intervals, or refuse to write them according to very specific firewall rules. This is, in my opinion, a must have with ublock origin.

edit 03-07-2018 - English
Basically, the fact that cookies enter the system is less of a problem than the fact that they can get out (and be read by websites).
The creator of uMatrix explains it very well on his wiki:
https://github.com/gorhill/uMatrix/wiki/Cookies

Before I used CookieMonster, since Firefox 56+, I use uMatrix which does the same thing and in addition replaces RequestPolicy and part of NoScript (PS: I have no actions at uMatrix: p).
To reproduce the default behavior of CookieMonster you just need to add a rule in the addon:

* * cookie block
=> Cookies from and to all websites will be blocked by default.

It's up to you to fix your exceptions as CookieMonster allowed it.
If you have authorized a cookie and then have it blacklisted right after, the cookie will remain on the system
(if you have not checked the auto-delete option), but it will not be read by the site.
The database of cookies and Firefox will not be faster if you delete / clean your cookies regularly.

These elements make me say that the management of whitelist / blacklist is rather redundant / useless with respect to an addon that does everything and does it well.
Regarding the edition of cookies (which is the main purpose of this one), there is however a lot of work to manage containers / contexts and FirstPartyIsolation introduced with the latest updates. That's why I'm not particularly eager to look at these firewall rules myself :)

Some additional information:
CookieMonster allowed to modify the exceptions directly in the database of Firefox. These exceptions are stored among others in permissions.sqlite. Today there is no more API to reproduce this behavior; it's a choice...

I have already developed a tool to convert these rules (as well as RequestPolicy and NoScript rules) into uMatrix rules.
More information here: https://pro-domo.ddns.net/umatrix-converter and on the Github: https://github.com/ysard/umatrix-converter
To be fast: User can just upload the files concerned to retrieve a text file of rules to import into uMatrix.

To conclude, my opinion is that Mozilla has tried to force the decided changes related to APIs. This is questionable because we all know that what made the strength of this browser in the eyes of the public is the richness of its ecosystem. This is especially questionable since the APIs are not mature. But we can understand them because the computer world suffers from a big inertia especially on security issues, and the situation could last for years without a radical decision to tidy up the addons, and in unsecured APIs.

We have to keep in mind that apart from addons problems, new engines deployed in recent updates are very promising because they replace code developed a long time ago; and last but not least, Firefox is by far the best web browser we have today about security and privacy of users.
This is important for this kind of software that we use constantly for our online activities...


edit 03-07-2018 - Français
Basiquement, le fait que les cookies entrent sur le système est moins un problème que le fait qu'ils puissent en sortir (et être lus par les sites web).
Le créateur de uMatrix l'explique très bien sur son wiki:
https://github.com/gorhill/uMatrix/wiki/Cookies

Avant j'utilisais CookieMonster, depuis Firefox 56+, j'utilise uMatrix qui fait la même chose et en plus remplace RequestPolicy et une partie de NoScript (PS: je n'ai pas d'actions chez uMatrix :p).
Pour reproduire le comportement par défaut de CookieMonster vous devez juste ajouter une règle dans l'addon:

* * cookie block

=> les cookies depuis et vers tous les sites seront bloqués par défaut.
À vous de fixer vos exceptions au fur et à mesure comme CookieMonster le permettait.
Si vous avez autorisé un cookie puis que vous l'avez blacklisté juste après, certes le cookie restera sur le système (si vous n'avez pas coché l'option d'auto-suppression), mais il ne pourra pas être lu par le site.
La base de données des cookies et Firefox ne seront pas plus rapide si vous supprimez/nettoyez vos cookies régulièrement.

Ces éléments me font dire que la gestion de whitelist/blacklist est plutôt redondante/inutile face à un addon qui fait tout et qui le fait bien.
Concernant l'édition des cookies (qui est le but principal de celui-ci), il y a en revanche beaucoup de travail pour gérer les containers/contexts et le FirstPartyIsolation introduits avec les dernières mises à jour. C'est pourquoi je ne suis pas particulièrement pressé de me pencher moi-même sur les ces règles pare-feu :)

Quelques informations supplémentaires:
CookieMonster permettait à l'époque de modifier les exceptions directement dans la base de données de Firefox. Ces exceptions sont stockées parmis d'autres dans permissions.sqlite. Aujourd'hui il n'y a plus d'API permettant de reproduire ce comportement; c'est un choix...

J'ai déjà développé un outil pour convertir ces règles (ainsi que les règles de RequestPolicy et NoScript) en règles uMatrix.
Plus d'informations ici: https://pro-domo.ddns.net/umatrix-converter et sur le Github: https://github.com/ysard/umatrix-converter
Pour être rapide: il suffit d'uploader les fichiers concernés pour récupérer un fichier texte de règles à importer dans uMatrix.

Pour conclure, mon avis est que Mozilla a tenté de passer en force les changements décidés liés aux API. C'est discutable car on sait tous que ce qui faisait la force de ce navigateur aux yeux du grand public est la richesse de son écosystème. Cela d'autant plus que les API ne sont pas matures. Mais on peut les comprendre car le monde informatique souffre habituellement d'une très grande inertie surtout en matière de sécurité, et la situation pourrait perdurer des années sans décision radicale de mettre de l'ordre dans les addons, et dans les APIs non sécurisées.

Gardons en tête qu'en dehors du problèmes des addons, les nouveaux moteurs déployés dans les mises à jour récentes sont très prometteurs car remplacent du code développé il y a bien longtemps. Pour finir, en matière de sécurité et respect de la vie privée des utilisateurs, Firefox est de très très loin le meilleur navigateur Web que nous ayons aujourd'hui.
C'est important pour ce genre de logiciel que nous utilisons en permanence pour nos activités en ligne...