Software Removal | Privacy Badger #1301

Closed
opened 2019-09-12 00:12:04 +00:00 by dawidpotocki · 21 comments
dawidpotocki commented 2019-09-12 00:12:04 +00:00 (Migrated from github.com)

Privacy Badger does not do anything beyond what uBlock Origin/uMatrix/NoScript does.
If we don't want to remove it, it should at least be listed last.

Privacy Badger does not do anything beyond what uBlock Origin/uMatrix/NoScript does. If we don't want to remove it, it should at least be listed last.
ghbjklhv1 commented 2019-09-12 01:36:33 +00:00 (Migrated from github.com)

I have a bit of an issue with this as not all advertisements are bad (just most).
Even DuckDuckGo has advertisements and you can get privacy respecting ads (AdEx is interesting).


As for NoScript and uMatrix, they are too hard to use.
It is too difficult to manually allow basically every website.

I have a bit of an issue with this as not all advertisements are bad (_just most_). Even DuckDuckGo has advertisements and you can get privacy respecting ads ([AdEx](https://www.adex.network/) is interesting). __________________________________ As for NoScript and uMatrix, they are too hard to use. It is too difficult to manually allow basically every website.
nitrohorse commented 2019-09-12 01:59:30 +00:00 (Migrated from github.com)

I think Privacy Badger does fill a specific use case for some users, specifically when using uBO with blocklists rather than allowlists.

Privacy Badger uses heuristics to locate trackers and then blocks them. Basically, this means that Privacy Badger picks up where Ublock Origin leaves off. Should a tracker not located on the Ublock Origin blacklist find its way to your browser, Privacy Badger's heuristics will catch it and block it. - https://www.techrepublic.com/article/how-to-use-ublock-origin-and-privacy-badger-to-prevent-browser-tracking-in-firefox/

Further context: https://www.eff.org/privacybadger/faq#How-does-Privacy-Badger-work

Since we don't document a recommendation for which method to use (blocklist vs. allowlist) then it seems safer to leave Privacy Badger listed. But moving it to the bottom or at least lower than uBO/uMatrix makes sense to me since those are more critical in my opinion.

I think Privacy Badger does fill a specific use case for some users, specifically when using uBO with blocklists rather than allowlists. > Privacy Badger uses heuristics to locate trackers and then blocks them. Basically, this means that Privacy Badger picks up where Ublock Origin leaves off. Should a tracker not located on the Ublock Origin blacklist find its way to your browser, Privacy Badger's heuristics will catch it and block it. - https://www.techrepublic.com/article/how-to-use-ublock-origin-and-privacy-badger-to-prevent-browser-tracking-in-firefox/ Further context: https://www.eff.org/privacybadger/faq#How-does-Privacy-Badger-work Since we don't document a recommendation for which method to use (blocklist vs. allowlist) then it seems safer to leave Privacy Badger listed. But moving it to the bottom or at least lower than uBO/uMatrix makes sense to me since those are more critical in my opinion.
blacklight447 commented 2019-09-13 12:20:39 +00:00 (Migrated from github.com)

I vote for removal.

I vote for removal.
Mikaela commented 2019-09-13 16:34:11 +00:00 (Migrated from github.com)

I vote for keeping.

Privacy Badger is the only extension we list that non-experts can use that doesn't block based on a external blocklist and instead learns what trackers are by itself.

µBlock Origin depends on external blocklists, µMatrix and noScript would be closer to PB by blocking everything, but they require too much configuration for basic users.

I vote for keeping. Privacy Badger is the only extension we list that non-experts can use that doesn't block based on a external blocklist and instead learns what trackers are by itself. µBlock Origin depends on external blocklists, µMatrix and noScript would be closer to PB by blocking everything, but they require too much configuration for basic users.
Mikaela commented 2019-09-13 16:45:47 +00:00 (Migrated from github.com)

I opened #1306 which does the suggestion of moving it on top of "for everyone" addons (I am not comfortable putting it below noScript and µMatrix as those two are under a separate heading "for power users").

See also: https://www.eff.org/privacybadger/faq#Is-Privacy-Badger-compatible-with-other-extensions,-including-other-adblockers

I opened #1306 which does the suggestion of moving it on top of "for everyone" addons (I am not comfortable putting it below noScript and µMatrix as those two are under a separate heading "for power users"). See also: https://www.eff.org/privacybadger/faq#Is-Privacy-Badger-compatible-with-other-extensions,-including-other-adblockers
Mikaela commented 2019-09-14 17:51:37 +00:00 (Migrated from github.com)

What would you all say on puttng the list to alphabetical order?

See also: https://github.com/privacytoolsIO/privacytools.io/pull/1306/files#r324430513

What would you all say on puttng the list to alphabetical order? See also: https://github.com/privacytoolsIO/privacytools.io/pull/1306/files#r324430513
nitrohorse commented 2019-09-14 18:42:55 +00:00 (Migrated from github.com)

What would you all say on puttng the list to alphabetical order?

See also: privacytoolsIO/privacytools.io/pull/1306/files#r324430513

It would be consistent with other sections so that's probably a good idea.

> What would you all say on puttng the list to alphabetical order? > > See also: [privacytoolsIO/privacytools.io/pull/1306/files#r324430513](https://github.com/privacytoolsIO/privacytools.io/pull/1306/files#r324430513) It would be consistent with other sections so that's probably a good idea.
ghost commented 2019-09-16 16:38:58 +00:00 (Migrated from github.com)
  • uBlock Origin relies on lists of known trackers and bad websites (comparable with the typical anti-malware approach) (+ some more features)
  • Privacy Badger comes with a heuristics-based approach, and doesn't necessarily need to know trackers/websites

Source: https://arxiv.org/pdf/1905.01051 (Browser Fingerprinting: A survey, May 2019)

- **uBlock Origin** relies on lists of known trackers and bad websites (comparable with the typical anti-malware approach) (+ some more features) - **Privacy Badger** comes with a heuristics-based approach, and doesn't necessarily need to know trackers/websites Source: https://arxiv.org/pdf/1905.01051 (Browser Fingerprinting: A survey, May 2019)
blacklight447 commented 2019-09-17 09:15:50 +00:00 (Migrated from github.com)

I think this discussion finally comes down to: is the extra blocking that privacy badger does over Ublock Origin worth having another plugin to install.

I think this discussion finally comes down to: is the extra blocking that privacy badger does over Ublock Origin worth having another plugin to install.
Mikaela commented 2019-09-17 18:21:09 +00:00 (Migrated from github.com)

I think this discussion finally comes down to: is the extra blocking that privacy badger does over Ublock Origin worth having another plugin to install.

But the list is not "you have to install these" and I think being OK with advertising, but not tracking is a legitimate usecase which is where Privacy Badger would work in.

> I think this discussion finally comes down to: is the extra blocking that privacy badger does over Ublock Origin worth having another plugin to install. But the list is not "you have to install these" and I think being OK with advertising, but not tracking is a legitimate usecase which is where Privacy Badger would work in.
dawidpotocki commented 2019-09-17 22:58:15 +00:00 (Migrated from github.com)

Comment by Démon de Laplace from our Matrix server

PrivacyBadger's main role is to block third-party (tracking) cookies and
send DNT requests (I belive), However:

  1. PrivacyBadger takes time to "learn" (due to three strikes policy) and
    therefore increases entropy and the fingerprint, something agains the
    philosophy of Ghacks user.js, one of the user.js profiles we recommend.

  2. DNT seems to do nothing as of now.

  3. uBO already blocks most of these third party cookies, and hence even
    Ghacks user.js specifically says PrivacyBadger is near useless, on
    https://github.com/ghacksuserjs/ghacks-user.js/wiki/4.1-Extensions

  4. uBO isn't necessary an adblocker, and can be configured to not block
    ads, so it isn't really a good argument
    https://github.com/privacytoolsIO/privacytools.io/issues/1301#issuecomment-530628552

It is true that PrivacyBadger might block certain cookies that uBO
doesn't have in it's filterlist, but it likely doesn't outweight the
increase in fingerprinting and resource usage.

__Comment by Démon de Laplace from our Matrix server__ PrivacyBadger's main role is to block third-party (tracking) cookies and send DNT requests (I belive), However: 1. PrivacyBadger takes time to "learn" (due to three strikes policy) and therefore increases entropy and the fingerprint, something agains the philosophy of Ghacks user.js, one of the user.js profiles we recommend. 2. DNT seems to do nothing as of now. 3. uBO already blocks most of these third party cookies, and hence even Ghacks user.js specifically says PrivacyBadger is near useless, on https://github.com/ghacksuserjs/ghacks-user.js/wiki/4.1-Extensions 4. uBO isn't necessary an adblocker, and can be configured to not block ads, so it isn't really a good argument https://github.com/privacytoolsIO/privacytools.io/issues/1301#issuecomment-530628552 It is true that PrivacyBadger might block certain cookies that uBO doesn't have in it's filterlist, but it likely doesn't outweight the increase in fingerprinting and resource usage.
DF2NwasJiMYLNFyAOQarZtfPPj0qXh4G commented 2019-09-18 00:04:51 +00:00 (Migrated from github.com)

I'm the guy who came up with https://github.com/privacytoolsIO/privacytools.io/issues/1301#issuecomment-532433649.

As I see it, there are three main approaches to configuring Firefox in a "secure/private" manner:

  1. Following the Tor Browser / ghacks user.js policy of decreasing entropy between users, and lowering attack surfaces as much as possible, as to "blend in the crowd."
  2. Randomizing all outgoing data, as to prevent trackers from building an accurate profile of the user.
  3. Trying to provide minor security and privacy advantages without compromising usability and convenience.

As mentioned beforehand, Privacy Badger increases entropy, and therefore wouldn't be compatible with the philosophy of the first one.

The second philosophy has been shown to be questionable in practice, and isn't something that I believe a person should give as a tip to potentially ignorant people.

Even in the third case, the usage of Privacy Badger really isn't justified (granted something such as uBO is already being used) as I recall Privacy Badger noticeably slowing down the loading speed of websites, without it providing much utility*.

I also wanted to mention that I don't think simply doing what is proposed on #1306 is the best idea. Instead, I think it would be a better investment of time to add a warning to not use it along with uBO (why use something that brings no noticeable merit, with lots of noticeable downsides?) or outright remove it, and write a guide on how to configure uBO to not block ads**.

* From my impression of using it for multiple weeks, about a year ago. Although I might be remembering incorrectly.

** uBO brings plenty of security and privacy benefits, even without blocking ads. Such as blocking tracking cookies, connections from domains known for malware, remote fonts, scripts and frames, or even preventing IP leaks from WebRTC.

I'm the guy who came up with https://github.com/privacytoolsIO/privacytools.io/issues/1301#issuecomment-532433649. As I see it, there are three main approaches to configuring Firefox in a "secure/private" manner: 1. Following the Tor Browser / ghacks user.js policy of decreasing entropy between users, and lowering attack surfaces as much as possible, as to "blend in the crowd." 2. Randomizing all outgoing data, as to prevent trackers from building an accurate profile of the user. 3. Trying to provide minor security and privacy advantages without compromising usability and convenience. As mentioned beforehand, Privacy Badger increases entropy, and therefore wouldn't be compatible with the philosophy of the first one. The second philosophy has been shown to be questionable in practice, and isn't something that I believe a person should give as a tip to potentially ignorant people. Even in the third case, the usage of Privacy Badger really isn't justified (granted something such as uBO is already being used) as I recall Privacy Badger noticeably slowing down the loading speed of websites, without it providing much utility*. I also wanted to mention that I don't think simply doing what is proposed on #1306 is the best idea. Instead, I think it would be a better investment of time to add a warning to not use it along with uBO (why use something that brings no noticeable merit, with lots of noticeable downsides?) or outright remove it, and write a guide on how to configure uBO to not block ads**. \* From my impression of using it for multiple weeks, about a year ago. Although I might be remembering incorrectly. \** uBO brings plenty of security and privacy benefits, even without blocking ads. Such as blocking tracking cookies, connections from domains known for malware, remote fonts, scripts and frames, or even preventing IP leaks from WebRTC.
Thorin-Oakenpants commented 2019-09-18 03:43:08 +00:00 (Migrated from github.com)
  1. uBO already blocks most of these third party cookies, and hence even Ghacks user.js specifically says PrivacyBadger is near useless, on https://github.com/ghacksuserjs/ghacks-user.js/wiki/4.1-Extensions

Are you sure?
wiki

It used to say that. It has always been true that Privacy Badger (or any other extension) can pick up some spill not covered by uBO: but I didn't want the list of extensions to become a massive list of duplication. The wiki has always said "We are also not saying you have to use all these extensions", but if I ever had to recommend only one extension for novices: uBO would be it. i.e. there's an assumption here that users are using uBO: especially given our user base. The return from PB becomes a dribble to nothing, depending on your uBO settings. Personally, I would get zero benefit from it: since I run uBO and uMatrix in pretty hard configs.

However, I recently changed the wiki, because I can't argue with the logic that it does cover items others miss: the point of difference (from list based solutions) being the heuristics.

As mentioned beforehand, Privacy Badger increases entropy, and therefore wouldn't be compatible with the philosophy of the first one.

Don't confuse Privacy Badger with Privacy Possum. This has nothing to do directly with fingerprinting

> 3. uBO already blocks most of these third party cookies, and hence even Ghacks user.js specifically says PrivacyBadger is near useless, on https://github.com/ghacksuserjs/ghacks-user.js/wiki/4.1-Extensions Are you sure? ![wiki](https://user-images.githubusercontent.com/16656956/65105101-5d610400-d9c3-11e9-9035-d9d523a91716.png) It used to say that. It has **always** been true that Privacy Badger (or any other extension) can pick up some spill not covered by uBO: but I didn't want the list of extensions to become a massive list of duplication. The wiki has always said "We are also not saying you have to use all these extensions", but if I ever had to recommend only one extension for novices: uBO would be it. i.e. there's an assumption here that users are using uBO: especially given our user base. The return from PB becomes a dribble to nothing, depending on your uBO settings. Personally, I would get zero benefit from it: since I run uBO and uMatrix in pretty hard configs. However, I recently changed the wiki, because I can't argue with the logic that it does cover items others miss: the point of difference (from list based solutions) being the heuristics. > As mentioned beforehand, Privacy Badger increases entropy, and therefore wouldn't be compatible with the philosophy of the first one. Don't confuse Privacy Badger with Privacy Possum. This has nothing to do directly with fingerprinting
DF2NwasJiMYLNFyAOQarZtfPPj0qXh4G commented 2019-09-18 05:13:57 +00:00 (Migrated from github.com)

Thanks for the detailed reply. I love your work and I'm sure you've way better insight than me. But here's some things I wanted to make sure.

Are you sure?
It used to say that.

Yes, I am sure. The comment that @dawidpotocki posted for me was actually written on the 12th, six days ago. And it seems like the edit that changed that part was four days ago. [1]

The return from PB becomes a dribble to nothing, depending on your uBO settings.

Uses heuristics to learn and to build local blocking lists. Your mileage will depend on what other blocking extensions you use and their configurations, but it certainly can't hurt.

My understanding was that, if it does "dribble to nothing," then it becomes a compromise between whether the "dribble to nothing" actually helps more than the deficits (fingerprinting, resource usage, breakage after updates, etc). And I feel like it really doesn't. Hence why I think a warning is apt for people who are interested in installing both, if not outright removal.

Don't confuse Privacy Badger with Privacy Possum. This has nothing to do directly with fingerprinting

It was also my understanding that, because Privacy Badger takes time to learn, [2] the pattern of how third parties cookies will be allowed a few times until it is blocked would become obvious. Hence making it more fingerprint-able. However, saying that it would increase entropy might have been misleading on my part... Or outright wrong for that matter... Terminology is still something I have to work on.

[1] 44f04f0e2c

[2] https://www.eff.org/privacybadger/faq#How-does-Privacy-Badger-work

If it observes a single third-party host tracking you on three separate sites, Privacy Badger will automatically disallow content from that third-party tracker.

Thanks for the detailed reply. I love your work and I'm sure you've way better insight than me. But here's some things I wanted to make sure. >Are you sure? It used to say that. Yes, I am sure. The comment that @dawidpotocki posted for me was actually written on the 12th, six days ago. And it seems like the edit that changed that part was four days ago. [1] >The return from PB becomes a dribble to nothing, depending on your uBO settings. >Uses [heuristics](https://www.eff.org/privacybadger/faq#How-does-Privacy-Badger-work) to learn and to build local blocking lists. Your mileage will depend on what other blocking extensions you use and their configurations, [but it certainly can't hurt](https://www.eff.org/privacybadger/faq#Is-Privacy-Badger-compatible-with-other-extensions,-including-other-adblockers). My understanding was that, if it does "dribble to nothing," then it becomes a compromise between whether the "dribble to nothing" actually helps more than the deficits (fingerprinting, resource usage, breakage after updates, etc). And I feel like it really doesn't. Hence why I think a warning is apt for people who are interested in installing both, if not outright removal. >Don't confuse Privacy Badger with Privacy Possum. This has nothing to do directly with fingerprinting It was also my understanding that, because Privacy Badger takes time to learn, [2] the pattern of how third parties cookies will be allowed a few times until it is blocked would become obvious. Hence making it more fingerprint-able. However, saying that it would increase entropy might have been misleading on my part... Or outright wrong for that matter... Terminology is still something I have to work on. [1] https://github.com/ghacksuserjs/ghacks-user.js/wiki/4.1-Extensions/44f04f0e2c32d88b3ce8b3f1e78ba6d42b2a9742 [2] https://www.eff.org/privacybadger/faq#How-does-Privacy-Badger-work >If it observes a single third-party host tracking you on three separate sites, Privacy Badger will automatically disallow content from that third-party tracker.
Thorin-Oakenpants commented 2019-09-18 05:38:13 +00:00 (Migrated from github.com)

Yes, I am sure

That's fine. I had no link to the original comment, and could only go on your comment

then it becomes a compromise between whether the "dribble to nothing" actually helps more than the deficits (fingerprinting, resource usage, breakage after updates, etc)

There's no compromise. I know you didn't mention it, but I'll include it here: there's no technical compromise: as long as one extension or Firefox itself blocks the resource, the resource is blocked. Resource usage, you gotta be kidding me. Breakage: unlikely to ever happen given the move to web extensions and numbers of users and the Dev/Nightly channels.

You keep saying fingerprinting: this is not fingerprinting, certainly not in the strictest sense. I don't want to get into a long discussion, but what you're describing is behavioral. FPing likes stability, and it likes it stable across all websites. Anything that blocks tracking outweighs what you're describing (the exception being the Tor Browser where tracking can do what it likes, because FPI and new identities etc)

the pattern of how third parties cookies will be allowed a few times until it is blocked would become obvious

No one is going to bother trying to monitor that. Suddenly they do allow that one 3rd party, then suddenly they don't. They could have visited the site for years but only just added PB. They could have sanitized their local web content/persistent storage, they could have suddenly blocked the 3rd party by other means (updated uBO list). They could use a VPN and change servers a lot. Tying this single, once-in-a-badgers-lifetime change to the same user/browser relies on a lot of IF and BUTs.

> Yes, I am sure That's fine. I had no link to the original comment, and could only go on **your** comment > then it becomes a compromise between whether the "dribble to nothing" actually helps more than the deficits (fingerprinting, resource usage, breakage after updates, etc) There's no compromise. I know you didn't mention it, but I'll include it here: there's no technical compromise: as long as one extension or Firefox itself blocks the resource, the resource is blocked. Resource usage, you gotta be kidding me. Breakage: unlikely to ever happen given the move to web extensions and numbers of users and the Dev/Nightly channels. You keep saying fingerprinting: this is not fingerprinting, certainly not in the strictest sense. I don't want to get into a long discussion, but what you're describing is behavioral. FPing likes stability, and it likes it stable across all websites. Anything that blocks tracking outweighs what you're describing (the exception being the Tor Browser where tracking can do what it likes, because FPI and new identities etc) > the pattern of how third parties cookies will be allowed a few times until it is blocked would become obvious No one is going to bother trying to monitor that. Suddenly they do allow that one 3rd party, then suddenly they don't. They could have visited the site for years but only just added PB. They could have sanitized their local web content/persistent storage, they could have suddenly blocked the 3rd party by other means (updated uBO list). They could use a VPN and change servers a lot. Tying this *single, once-in-a-badgers-lifetime* change to the same user/browser relies on a lot of IF and BUTs.
DF2NwasJiMYLNFyAOQarZtfPPj0qXh4G commented 2019-09-18 06:11:29 +00:00 (Migrated from github.com)

Seems fair. I would totally be fine keeping it, then. Oh, and I just realized that it might perhaps be better to do as @nitrohorse said on https://github.com/privacytoolsIO/privacytools.io/pull/1306#discussion_r324430513; to put it under Decentraleyes rather than making it completely last.

Seems fair. I would totally be fine keeping it, then. Oh, and I just realized that it might perhaps be better to do as @nitrohorse said on https://github.com/privacytoolsIO/privacytools.io/pull/1306#discussion_r324430513; to put it under Decentraleyes rather than making it completely last.
Thorin-Oakenpants commented 2019-09-18 06:30:53 +00:00 (Migrated from github.com)

Just realized that I maybe didn't explain that very well: so I'll put it another way / example

It literally cannot do worse than allowing the 3rd party (connection, tracking script, cookies whatever)

  • you allow the 3rd party, you visit 10 sites that use this 3rd party. It can now connect those 10 visits.
  • you block the 3rd party, you visit 10 sites that use this 3rd party, the first party tells the 3rd party, the 3rd party can detect you were blocking it, across those 10 sites

If the first case (allow): you could possibly be worse off (assigned a unique id). In the second case (blocking), it then requires more effort from the 3rd party (and assistance from 1st party), to even know you visited the 10 sites.

It's a tracking mechanism, not a FPing one. If it was universal (or near universal), then it would be. Otherwise it's only relevant to traffic sets that include that 3rd party: and all the big ones are most likely already listed in tracking blocklists

Just realized that I maybe didn't explain that very well: so I'll put it another way / example It literally cannot do worse than allowing the 3rd party (connection, tracking script, cookies whatever) - you allow the 3rd party, you visit 10 sites that use this 3rd party. It can now connect those 10 visits. - you block the 3rd party, you visit 10 sites that use this 3rd party, the first party tells the 3rd party, the 3rd party can detect you were blocking it, across those 10 sites If the first case (allow): you could possibly be worse off (assigned a unique id). In the second case (blocking), it then requires more effort from the 3rd party (and assistance from 1st party), to even know you visited the 10 sites. It's a tracking mechanism, not a FPing one. If it was **universal** (or near universal), *then* it would be. Otherwise it's only relevant to traffic sets that include that 3rd party: and all the big ones are most likely already listed in tracking blocklists
nitrohorse commented 2019-09-18 17:52:18 +00:00 (Migrated from github.com)

Reopening since I’m unsure what the resolution is for this. Remove PB, keep and move to bottom of list, or organize list based on “significance” for users (which users, normal/power?).

Reopening since I’m unsure what the resolution is for this. Remove PB, keep and move to bottom of list, or organize list based on “significance” for users (which users, normal/power?).
Mikaela commented 2019-09-19 12:19:33 +00:00 (Migrated from github.com)

Remove PB

👎 as there is a spot it can fill with default configuration without user who has nothing against advertisements having to bother with µBlock Origin.

keep and move to bottom of list

I am fine with it.

or organize list based on “significance” for users (which users, normal/power?).

👎 I think everyone is going to have their own significance lists or throw new addons to the list. I think alphabetical order would make more sense, especially if more descriptions were added. Reading the page I am not sure what could be added.

> Remove PB :-1: as there is a spot it can fill with default configuration without user who has nothing against advertisements having to bother with µBlock Origin. > keep and move to bottom of list I am fine with it. > or organize list based on “significance” for users (which users, normal/power?). :-1: I think everyone is going to have their own significance lists or throw new addons to the list. I think alphabetical order would make more sense, especially if more descriptions were added. Reading the page I am not sure what could be added.
DF2NwasJiMYLNFyAOQarZtfPPj0qXh4G commented 2019-09-19 20:22:35 +00:00 (Migrated from github.com)

In the case that things would be sorted by significance (I don't mind either way), I imagine it to look something like this:

Very Useful:
So useful, it obsoletes many extensions.

  • uBlock Origin

Useful:
Useful with no real drawbacks.

  • HTTPS Everywhere
  • Decentraleyes

Questionable:
Has some merit.

  • PrivacyBadger (mostly covered by uBO)
  • Cookie AutoDelete (gives users false sense of privacy, and is more a convenience tool than one that enhances privacy/security? And should probably be replaced with Temporary Containers) [1]

Others:
These two, from what I can tell, should not even be listed as something that improves the user's privacy. Perhaps a different section, akin to "For Power Users Only"?

  • Snowflake
  • Terms of Service; Didn’t Read

Maybe I should make a different Issue specifically for it, but I find Cookie AutoDelete and the things I listed in the "Others" to not be in line with the other extensions.

[1] 44f04f0e2c

️ APIs do not exist to allow clearing IndexedDB, Service Workers cache, appCache, or cache by host. Clearing cookies & localStorage on their own, and leaving orphaned persistent data is a false sense of privacy

In the case that things would be sorted by significance (I don't mind either way), I imagine it to look something like this: **Very Useful:** So useful, it obsoletes many extensions. * uBlock Origin **Useful:** Useful with no real drawbacks. * HTTPS Everywhere * Decentraleyes **Questionable:** Has some merit. * PrivacyBadger (mostly covered by uBO) * Cookie AutoDelete (gives users false sense of privacy, and is more a convenience tool than one that enhances privacy/security? And should probably be replaced with Temporary Containers) [1] **Others:** These two, from what I can tell, should not even be listed as something that improves the user's privacy. Perhaps a different section, akin to "For Power Users Only"? * Snowflake * Terms of Service; Didn’t Read Maybe I should make a different Issue specifically for it, but I find Cookie AutoDelete and the things I listed in the "Others" to not be in line with the other extensions. [1] https://github.com/ghacksuserjs/ghacks-user.js/wiki/4.1-Extensions/44f04f0e2c32d88b3ce8b3f1e78ba6d42b2a9742 >❗️ APIs do not exist to allow clearing IndexedDB, Service Workers cache, appCache, or cache by host. Clearing cookies & localStorage on their own, and leaving orphaned persistent data is a false sense of privacy
Mikaela commented 2019-09-19 21:09:37 +00:00 (Migrated from github.com)

Closing in favour of #1327 which I think is the only way forwards with this issue.

Closing in favour of #1327 which I think is the only way forwards with this issue.
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#1301
No description provided.