🆕 Software Suggestion | ForgetMeNot Browser Cleaning Extension #1898

Open
opened 2020-05-09 12:02:33 +00:00 by jeroenev · 14 comments
jeroenev commented 2020-05-09 12:02:33 +00:00 (Migrated from github.com)

Basic Information

ForgetMeNot Browser extension:
"Make the browser forget website data (like cookies, local storage, etc.), except for the data you want to keep by adding domains to a whitelist, graylist, blacklist, or redlist."
URL:
https://addons.mozilla.org/en-US/firefox/addon/forget_me_not/

Description

This browser extension clears all browser data similarly to Cookie Autodelete, and seems to include Cookies+Localstorage like CookieAutoDelete.

Aside from this it also includes a lot of other methods, like ServiceWorkers, Plugin Data and IndexDB data, and Cache data
(these are cleaned on browser startup only, not on leaving site, and these do not support the whitelisting rules, so everything gets cleared regardless of site)

Why I am making the suggestion

Because I saw the warning on the Cookie Autodelete plugin, I've been using this as an alternative for CAD for a while now, but seeing a warning on PT saying CAD is not able to delete serviceworker data, I thought it might be good to mention this.

My connection with the software

Just a user who discovered the software searching for something more comprehensive than CookieAutoDelete. mainly using https://samy.pl/evercookie/ as a baseline for how good it does it's cleaning.
After opening the site, creating an EverCookie, leaving the site, closing the browser, and opening the site again, all data sources used to try to recover the data it seems to fail.

So it seems to me like it's doing its job really well.

These are the settings I use.
FMN Settings

  • I will keep the issue up-to-date if something I have said changes or I remember a connection with the software.
## Basic Information ForgetMeNot Browser extension: "Make the browser forget website data (like cookies, local storage, etc.), except for the data you want to keep by adding domains to a whitelist, graylist, blacklist, or redlist." **URL:** https://addons.mozilla.org/en-US/firefox/addon/forget_me_not/ ## Description This browser extension clears all browser data similarly to Cookie Autodelete, and seems to include Cookies+Localstorage like CookieAutoDelete. Aside from this it also includes a lot of other methods, like ServiceWorkers, Plugin Data and IndexDB data, and Cache data (these are cleaned on browser startup only, not on leaving site, and these do not support the whitelisting rules, so everything gets cleared regardless of site) ## Why I am making the suggestion Because I saw the warning on the Cookie Autodelete plugin, I've been using this as an alternative for CAD for a while now, but seeing a warning on PT saying CAD is not able to delete serviceworker data, I thought it might be good to mention this. ## My connection with the software Just a user who discovered the software searching for something more comprehensive than CookieAutoDelete. mainly using https://samy.pl/evercookie/ as a baseline for how good it does it's cleaning. After opening the site, creating an EverCookie, leaving the site, closing the browser, and opening the site again, all data sources used to try to recover the data it seems to fail. So it seems to me like it's doing its job really well. These are the settings I use. ![FMN Settings](https://user-images.githubusercontent.com/10954827/81473244-6b3af200-91fd-11ea-922d-79a1be52df87.png) - [X] I will keep the issue up-to-date if something I have said changes or I remember a connection with the software.
dngray commented 2020-05-09 17:05:44 +00:00 (Migrated from github.com)

The issue is these things can only be deleted on shutdown. Temporary Containers deletes everything related to the container shortly after it is closed. Therefore Temporary Containers is a superior way of doing this as it doesn't rely on the user to regularly close their browser. Thoughts @Thorin-Oakenpants?

The issue is these things can only be deleted on shutdown. Temporary Containers deletes everything related to the container shortly after it is closed. Therefore Temporary Containers is a superior way of doing this as it doesn't rely on the user to regularly close their browser. Thoughts @Thorin-Oakenpants?
jeroenev commented 2020-05-09 17:34:06 +00:00 (Migrated from github.com)

@dngray I definitely agree that Temporary Containers is a more comprehensive solution.

But this might be used as a more comprehensive alternative to Cookie AutoDelete, especially on mobile, where containers simply don't exist.

I also think simply whitelisting sites in CAD/FMN is simpler for users than managing FF containers.

@dngray I definitely agree that Temporary Containers is a more comprehensive solution. But this might be used as a more comprehensive alternative to Cookie AutoDelete, especially on mobile, where containers simply don't exist. I also think simply whitelisting sites in CAD/FMN is simpler for users than managing FF containers.
ThracianKnight1907 commented 2020-05-09 17:38:26 +00:00 (Migrated from github.com)

It seems that it's not in active devolpment. Also, there are issues related to containers, like
this which are still open. Also the UI doesn't seem that user friendly, at least when I tested it a while ago it took me a while to understand it.

It seems that it's not in active devolpment. Also, there are issues related to containers, like [this](https://github.com/Lusito/forget-me-not/issues/186) which are still open. Also the UI doesn't seem that user friendly, at least when I tested it a while ago it took me a while to understand it.
jeroenev commented 2020-05-09 17:51:30 +00:00 (Migrated from github.com)

Last commit was less than a month ago.
And have you seen the settings for Temporary containers?
This add-on is not that confusing imho, even if CAD might still be slightly more user-friendly.
EDIT: last commit in the version-3b branch was 6 days ago.

Last commit was less than a month ago. And have you seen the settings for Temporary containers? This add-on is not that confusing imho, even if CAD might still be slightly more user-friendly. EDIT: last commit in the version-3b branch was 6 days ago.
ph00lt0 commented 2020-05-10 09:17:31 +00:00 (Migrated from github.com)

@dngray as far as I know ForgetMeNot does actually clean cookies when you close the tab if you opt for Immediatly as setting.

@dngray as far as I know ForgetMeNot does actually clean cookies when you close the tab if you opt for Immediatly as setting.
Thorin-Oakenpants commented 2020-05-10 10:02:50 +00:00 (Migrated from github.com)

The issue here is not about sanitizing between sessions (and you should use FF's internal settings for that), it's about repeat visits to sites in-session. So that is the first thing I would say: i.e:

  • Option 1: sanitize on close - should suit most users
  • Option 2: for in-session tracking.. depending on your threat model
    • people use all sorts of configs
    • e.g. some people will want to not clear "cookies", which includes localStorage (but they can still clear IDB) so they can auto-login. That leaves a hole
    • e.g. some users keep their browser open for days on end
    • so if your config, or threat model call for it then use TC (superior) or some other extension
  • Option 3: FFS: use Tor Browser or secondary browsers/profiles/one-off PBMode windows

FYI: FF77+

  • 1551301 : Allow WebExtensions to clear IndexedDB by hostname
  • 1632990 : Allow WebExtensions to clear ServiceWorkers by hostname

They need testing and implementation into web extensions - but be aware that there are still outstanding issues with persistent web storage (but more edge case than anything else) which temporary containers can fix - i.e Origin Attributes cover a lot more - e.g. cache

As for ForgetMeNot, I think it uses a workaround to hack the IDB entries (IDB is used for IDB and service workers), or maybe that was Site Bleacher - IDK - I'm not interested in sanitizing extensions until they at least start to get some parity

The issue here is not about sanitizing between sessions (and you should use FF's internal settings for that), it's about repeat visits to sites **in-session**. So that is the first thing I would say: i.e: - Option 1: sanitize on close - should suit most users - Option 2: for in-session tracking.. depending on your threat model - people use all sorts of configs - e.g. some people will want to not clear "cookies", which includes localStorage (but they can still clear IDB) so they can auto-login. That leaves a hole - e.g. some users keep their browser open for days on end - so if your config, or threat model call for it then use TC (superior) or some other extension - Option 3: FFS: use Tor Browser or secondary browsers/profiles/one-off PBMode windows FYI: FF77+ - [1551301](https://bugzilla.mozilla.org/show_bug.cgi?id=1551301) : Allow WebExtensions to clear IndexedDB by hostname - [1632990](https://bugzilla.mozilla.org/show_bug.cgi?id=1632990) : Allow WebExtensions to clear ServiceWorkers by hostname They need testing and implementation into web extensions - but be aware that there are still outstanding issues with persistent web storage (but more edge case than anything else) which temporary containers can fix - i.e Origin Attributes cover a lot more - e.g. cache As for ForgetMeNot, I *think* it uses a workaround to `hack` the IDB entries (IDB is used for IDB and service workers), or maybe that was Site Bleacher - IDK - I'm not interested in sanitizing extensions until they at least start to get some parity - maybe someone should just ask @Lusito - https://github.com/Lusito/forget-me-not/issues/209
Lusito commented 2020-05-10 11:21:47 +00:00 (Migrated from github.com)

FMN is in active development, but I'm currently rewriting a lot of the code for a version 3 (which includes container support). That's why there haven't been any major changes aside from translations lately.

Just a few notes (beware, FMN is only on Firefox, so I can't say anything about chrome):

The term "on tab close" is not accurate for FMN. It cleans on domain leave. That includes tab close, but also just entering a new domain in the same tab.

FMN can do a lot more than CAD. It's probably that additional stuff that makes it a little less user-friendly, but it gives the user more options. For example, last time I checked CAD only had white and gray lists. FMN can prevent cookies from ever being set.

Browser support for cleaning is currently a bit limited. For example, while I will support container rules in V3, this will be limited to certain scenarios:

  • Cookies can be cleaned per domain and per container => No issue
  • Local Storage can be cleaned per domain, but not per container and not at all on android => ouch.
  • Indexed DB And Service Workers can not be cleaned per domain yet (soon though), but they can't be cleaned per container either => argh
  • Cache can neither be cleaned per domain nor per container (though I see hope to at least get the per-domain soon).

All of the above limitations are there because the browser API does not support it (yet). So container-specific rules will be limited in any web-extension. Some extensions even claim to clean things that they actually can't (like SiteBleacher).

So yes, the temporary container solution might fit some use-cases better, since you can remove containers (though I've seen reports, that they leave things behind => only a disk usage problem).

Depending on your use-case there's always going to be better solutions:

  • Use first party isolation
  • Use firefox cleaning on startup to remove everything
  • Just use private windows for everything

They all have drawbacks of course. First party isolation breaks some functionality. Other solutions forget your data completely, so you'll have to login over and over again.

FMN has a specific audience. Those people want fine-grained control over what exactly gets deleted (and when) and what remains.

FMN does not work arround anything using hacks currently. I don't like these kind of hacks, since they are ugly to maintain and they are unreliable.

@Thorin-Oakenpants it's not about the cleaning extensions getting parity, it's mostly about the browser API getting parity. If the browser API had the full power that we need, then it wouldn't take long until the cleaning extensions could catch up.

FMN is in active development, but I'm currently rewriting a lot of the code for a version 3 (which includes container support). That's why there haven't been any major changes aside from translations lately. Just a few notes (beware, FMN is only on Firefox, so I can't say anything about chrome): The term "on tab close" is not accurate for FMN. It cleans on domain leave. That includes tab close, but also just entering a new domain in the same tab. FMN can do a lot more than CAD. It's probably that additional stuff that makes it a little less user-friendly, but it gives the user more options. For example, last time I checked CAD only had white and gray lists. FMN can prevent cookies from ever being set. Browser support for cleaning is currently a bit limited. For example, while I will support container rules in V3, this will be limited to certain scenarios: - Cookies can be cleaned per domain and per container => No issue - Local Storage can be cleaned per domain, but not per container and not at all on android => ouch. - Indexed DB And Service Workers can not be cleaned per domain yet (soon though), but they can't be cleaned per container either => argh - Cache can neither be cleaned per domain nor per container (though I see hope to at least get the per-domain soon). All of the above limitations are there because the browser API does not support it (yet). So container-specific rules will be limited in any web-extension. Some extensions even claim to clean things that they actually can't (like SiteBleacher). So yes, the temporary container solution might fit some use-cases better, since you can remove containers (though I've seen reports, that they leave things behind => only a disk usage problem). Depending on your use-case there's always going to be better solutions: - Use first party isolation - Use firefox cleaning on startup to remove everything - Just use private windows for everything They all have drawbacks of course. First party isolation breaks some functionality. Other solutions forget your data completely, so you'll have to login over and over again. FMN has a specific audience. Those people want fine-grained control over what exactly gets deleted (and when) and what remains. FMN does not work arround anything using hacks currently. I don't like these kind of hacks, since they are ugly to maintain and they are unreliable. @Thorin-Oakenpants it's not about the cleaning extensions getting parity, it's mostly about the browser API getting parity. If the browser API had the full power that we need, then it wouldn't take long until the cleaning extensions could catch up.
Lusito commented 2020-05-10 11:39:42 +00:00 (Migrated from github.com)

BTW, why are containers nonexistent on android?
As far as I can tell, the API is complete. The only thing that's missing is a UI for it. You wouldn't need that for temporary containers, facebook container, etc, right?

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/contextualIdentities

BTW, why are containers nonexistent on android? As far as I can tell, the API is complete. The only thing that's missing is a UI for it. You wouldn't need that for temporary containers, facebook container, etc, right? https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/contextualIdentities
Thorin-Oakenpants commented 2020-05-10 11:59:15 +00:00 (Migrated from github.com)

it's not about the cleaning extensions getting parity, it's mostly about the browser API getting parity.

Sorry if I was confusing. The point being that extensions don't have the power to do the job fully (yet)


[ localStorage / IDB / SW cache / cache ] can't be cleaned per container either

IANA-WebExt-Expert, and I'm not sure about cache, but the rest are sanitized AFAIK (bugs aside). In a hardened setup, each visit would be a new OA anyway.

source

Temporary Containers only uses one API to remove data, and that is contextualIdentities.remove - which removes all userContextId tagged storage (including IDB). And even if it'd fail to do so, new contextualIdentities couldn't access the same data, since the cookieStoreIds (that's how the attribute is called in the API - it however refers to the userContextId used to OA-tag) are unique as long as the container feature is active.

Depending on your use-case there's always going to be better solutions

Indeed. With TC in hardened mode, there's no need for FPI (except in PBMode where container OA's cannot exist) - and the biggest drawback to FPI is cross-domain login flows (e.g using google to log into youtube). That's where dFPI comes in (which is a cookie setting in FF77+ and is a slightly relaxed FPI, and not as comprehensive (yet but will probably ramp up: e.g FPI covers things like HSTS, DNS cache etc). The bad news is dFPI and FPI are incompatible.


Anyway, I think this discussion is meant to be about CAD and FMN - and that's up to you PTIO peeps - personally I don't recommend any (persistent web storage) sanitizing extensions because there is a superior solution (not just the sanitizing but also the other items being isolated).

FPI and/or TC is not for everyone, so it makes sense to promote CAD or FMN (as well as sanitizing on close). That's up to you guys at PTIO to decide what to do: both need to implement the new cleaning IDB/SW by host, and FMN will soon have container support. My gut feeling is FMN seems like a better choice when ready

@Lusito thanks for responding 👍

> it's not about the cleaning extensions getting parity, it's mostly about the browser API getting parity. Sorry if I was confusing. The point being that extensions don't have the power to do the job fully (yet) --- > [ localStorage / IDB / SW cache / cache ] can't be cleaned per container either IANA-WebExt-Expert, and I'm not sure about cache, but the rest are sanitized AFAIK (bugs aside). In a hardened setup, each visit would be a new OA anyway. [source](https://github.com/ghacksuserjs/ghacks-user.js/issues/395#issue-310329383) > Temporary Containers only uses one API to remove data, and that is [`contextualIdentities.remove`](https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/contextualIdentities/remove) - which removes all [`userContextId` tagged storage (including IDB)](https://wiki.mozilla.org/Security/Contextual_Identity_Project/Containers#What_is_.28and_isn.27t.29_separated_between_Containers). And even if it'd fail to do so, new contextualIdentities couldn't access the same data, since the `cookieStoreId`s (that's how the attribute is called in the API - it however refers to the `userContextId` used to OA-tag) are unique as long as the container feature is active. > Depending on your use-case there's always going to be better solutions Indeed. With TC in hardened mode, there's no need for FPI (except in PBMode where container OA's cannot exist) - and the biggest drawback to FPI is cross-domain login flows (e.g using google to log into youtube). That's where dFPI comes in (which is a cookie setting in FF77+ and is a slightly relaxed FPI, and not as comprehensive (yet but will probably ramp up: e.g FPI covers things like HSTS, DNS cache etc). The bad news is dFPI and FPI are incompatible. --- Anyway, I think this discussion is meant to be about CAD and FMN - and that's up to you PTIO peeps - personally I don't recommend any (persistent web storage) sanitizing extensions because there is a superior solution (not just the sanitizing but also the other items being isolated). FPI and/or TC is not for everyone, so it makes sense to promote CAD or FMN (as well as sanitizing on close). That's up to you guys at PTIO to decide what to do: both need to implement the new cleaning IDB/SW by host, and FMN will soon have container support. My gut feeling is FMN seems like a better choice when ready @Lusito thanks for responding 👍
Lusito commented 2020-05-10 12:31:43 +00:00 (Migrated from github.com)

IANA-WebExt-Expert, and I'm not sure about cache, but the rest are sanitized AFAIK (bugs aside). In a hardened setup, each visit would be a new OA anyway.

I meant in the case where you don't delete the entire container but want to delete specific data in a container. At least on Firefox (stable), this is not supported yet (as said, they are working on it). Chrome maybe.

Yes, when you remove a container, it can't be accessed by websites anymore, so that is the only way to safely clean all the data as of now, but it does come with a loss of comfort.

FMN (or similar) still might complement temporary containers, as temporary containers only get cleaned upon removal. FMN can completely deny cookies from ever being set. Preventing tracking within the lifetime of a container.

I like having options (which is why I created FMN in the first place.. the author of CAD is not open for changes if they don't fit his vision).

Let me know if you have more questions.

>IANA-WebExt-Expert, and I'm not sure about cache, but the rest are sanitized AFAIK (bugs aside). In a hardened setup, each visit would be a new OA anyway. I meant in the case where you don't delete the entire container but want to delete specific data in a container. At least on Firefox (stable), this is not supported yet (as said, they are working on it). Chrome maybe. Yes, when you remove a container, it can't be accessed by websites anymore, so that is the only way to safely clean all the data as of now, but it does come with a loss of comfort. FMN (or similar) still might complement temporary containers, as temporary containers only get cleaned upon removal. FMN can completely deny cookies from ever being set. Preventing tracking within the lifetime of a container. I like having options (which is why I created FMN in the first place.. the author of CAD is not open for changes if they don't fit his vision). Let me know if you have more questions.
dngray commented 2020-05-10 17:18:41 +00:00 (Migrated from github.com)

Option 1: sanitize on close - should suit most users

That's what I had been doing on Android myself, with CAD. I regularly make sure I close my browser when finished.

e.g. some users keep their browser open for days on end

That is one of my main concerns. It's likely this is more of an issue for desktop users, ie ones who hibernate. I suppose with Android users many, would not actually close Fennec, they'd just open some other apps and switch between them.

Well as it is at the moment, we only suggest CAD for Android platforms where you can't run Temporary Containers on Fennec. What I like about Temporary Containers in automatic mode, is it's pretty fool proof, and requires minimal configuration, so its easy to set up.

both need to implement the new cleaning IDB/SW by host, and FMN will soon have container support. My gut feeling is FMN seems like a better choice when ready

That was my feeling as well. I think we might replace CAD with FMN 3 comes out, as it does appear to be more complete and able to clear things other than cookies (afaik that's all CAD can clear).

BTW, why are containers nonexistent on android?
As far as I can tell, the API is complete. The only thing that's missing is a UI for it. You wouldn't need that for temporary containers, facebook container, etc, right?

I think the issue is that Temporary Containers requires the ability to create tabs with container backed storage.

FMN can completely deny cookies from ever being set. Preventing tracking within the lifetime of a container.

I currently use umatrix for doing that, in particular news websites that only let you view 3 articles for free. 🏴‍☠️..

> Option 1: sanitize on close - should suit most users That's what I had been doing on Android myself, with CAD. I regularly make sure I close my browser when finished. > e.g. some users keep their browser open for days on end That is one of my main concerns. It's likely this is more of an issue for desktop users, ie ones who hibernate. I suppose with Android users many, would not actually close Fennec, they'd just open some other apps and switch between them. Well as it is at the moment, we only suggest CAD for Android platforms where you can't run Temporary Containers on Fennec. What I like about Temporary Containers in automatic mode, is it's pretty fool proof, and requires minimal configuration, so its easy to set up. > both need to implement the new cleaning IDB/SW by host, and FMN will soon have container support. My gut feeling is FMN seems like a better choice when ready That was my feeling as well. I think we might replace CAD with FMN 3 comes out, as it does appear to be more complete and able to clear things other than cookies (afaik that's all CAD can clear). > BTW, why are containers nonexistent on android? > As far as I can tell, the API is complete. The only thing that's missing is a UI for it. You wouldn't need that for temporary containers, facebook container, etc, right? I think the issue is that Temporary Containers requires the ability to [create tabs with container](https://bugzilla.mozilla.org/show_bug.cgi?id=1398097) backed storage. > FMN can completely deny cookies from ever being set. Preventing tracking within the lifetime of a container. I currently use umatrix for doing that, in particular news websites that only let you view 3 articles for free. :pirate_flag:..
Thorin-Oakenpants commented 2020-05-10 18:45:06 +00:00 (Migrated from github.com)

I currently use umatrix for doing that ... [re "denying cookies from ever being set"]

First: it doesn't stop cookies being "set", only "leaving" your computer
Second: it only applies to HTTP cookie headers (edit: i.e JS bypasses it)

[1] https://github.com/gorhill/uMatrix/wiki/Cookies

And blocking the cookie via extension, still means other persistent storage is available. For these sorts of sites you are probably better off just blocking cookies via site permissions (this also neuters sessionStorage, localStorage, IDB, service workers) - depends if you sanitize site settings on close. i.e the cookie permission is the master switch for Quota Manager

> I currently use umatrix for doing that ... [re "denying cookies from ever being set"] First: it doesn't stop cookies being "set", only "leaving" your computer Second: it only applies to HTTP cookie headers (edit: i.e JS bypasses it) [1] https://github.com/gorhill/uMatrix/wiki/Cookies And blocking the cookie via extension, still means other persistent storage is available. For these sorts of sites you are probably better off just blocking cookies via site permissions (this also neuters sessionStorage, localStorage, IDB, service workers) - depends if you sanitize site settings on close. i.e the cookie permission is the master switch for Quota Manager
dngray commented 2020-05-11 04:20:00 +00:00 (Migrated from github.com)

For these sorts of sites you are probably better off just blocking cookies via site permissions

Yeah I narrowed down it was one specific 1st party cookie causing the issue, when I used uMatrix to block it's creation then I could visit any number of articles.

> For these sorts of sites you are probably better off just blocking cookies via site permissions Yeah I narrowed down it was one specific 1st party cookie causing the issue, when I used uMatrix to block it's creation then I could visit any number of articles.
Lusito commented 2020-05-23 13:51:22 +00:00 (Migrated from github.com)

FYI there is currently some progress going on in the browsingData API:
https://bugzilla.mozilla.org/show_bug.cgi?id=1340511

If https://bugzilla.mozilla.org/show_bug.cgi?id=1353726 gets done next, there might be hope for nice cleaning features.

FYI there is currently some progress going on in the browsingData API: https://bugzilla.mozilla.org/show_bug.cgi?id=1340511 If https://bugzilla.mozilla.org/show_bug.cgi?id=1353726 gets done next, there might be hope for nice cleaning features.
This repo is archived. You cannot comment on issues.
No Milestone
No Assignees
1 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: privacyguides/privacytools.io#1898
No description provided.