If ads did not track me, did not suddenly blast loud sounds at me, did not flash portions of the screen at me, did not open new windows or tabs, did not try hijack my machine or install malware and generally behaved like good net citizens, I would be quite comfortable with seeing ads in most areas.
The beauty of Privacy Badger is that it does not block ads, instead it blocks anything that could track, based not on a centralized list, but based on websites' behaviour.
From the download page:
"Although we like Disconnect, Adblock Plus, Ghostery and similar products [...] none of them are exactly what we were looking for. In our testing, all of them required some custom configuration to block non-consensual trackers."
"algorithmic and policy methods for detecting and preventing non-consensual tracking"
So I think the biggest difference is the algorithm it uses to "learn" what to block as you browse.
Edit: Also, it doesn't block all ads. From the same source: "Because Privacy Badger is primarily a privacy tool, not an ad blocker. Our aim is not to block ads, but to prevent non-consensual invasions of people's privacy"
There is no point in using Disconnect if you have uBlock Origin. uBlock Origin has a set of filters in it's preferences that includes all of the filters from Disconnect. And you also do not need Privacy Badger if you have uBlock Origin.
www.privacytools.io recommends all the browsers and add-ons you could need to stay safe and annoyance-free.
I use uBlock Origin together with Privacy badger. It can block cookies for a domain while allowing you to load files, which I find useful, for example, for reading disqus comments in a website.
I also recommend uMatrix. Ridding all the cookies while allowing some resources with such granularity is very powerful. Also maybe scary for new users, but give it a week and its usefulness will be obvious.
That's the site I used to find out which addons I should be using. They used to recommend using Disconnect and uBlock Origin but I guess they've updated their info since I last read it.
- You request once _per CDN_. Common libraries are hosted on multiple CDNs and you may simply load them from multiple locations. For example jQuery is hosted by MaxCDN, Google, Microsoft, Cloudflare, jsdelivr.
- Some CDNs may be temporarily down. It happened for me already multiple times, including Google CDN and Cloudflare CDN.
Could you not use an adaptive password hashing algo with an absurd iteration count. Let's say each hash takes 500ms. Salt each domain with a different salt.
Building a rainbow table would still be possible, but hindered. To discover one domain behind one hash, you would need to roughly run through half of the used domains with the slow password hash.
That being said, the subset of popular domains is much smaller then the full set of domains, so the problem can be pared down to be much more effective than the worst-case.
Oh, you're right, I can't reverse that. Your Privacy Badger has just blocked half the internet, though, because a million domains match each of those hashes.
2) Seems like this resolves to the EFF, and considering that Privacy Badger has a few constants that are updateable files at EFF URLs, (DNT_POLICIES_URL & COOKIE_BLOCK_LIST_URL), it isn't unreasonable to hold off on calling foul on this one.
Where is this list? On my (Ubuntu) machine I suspect it's ~/.mozilla/firefox/<profile-string-here>.default/browser-extension-data/jid1-<another-string-here>@jetpack/storage.js. However it definitely does not include a list of every domain I've ever visited.
I have Firefox set to clear everything except for bookmarks and saved passwords each time I close it (which is frequently) and there are definitely sites in that storage.js file from previous sessions, but it is not complete. I wonder if another mechanism purges domains after a time?
This is (IMO) an un-substantive reply to what amounts to fear-mongering. See their previous discussion about issue #1 that tdkl mentioned above (https://github.com/EFForg/privacybadger/issues/266), and you'll see the following comment at the bottom:
> This was discussed in the bi-weekly developers meeting on 9/27.
> Threat model: A local attacker would be able to view a subset of
> cleared history (only visited domains, not urls or times).
> This solution does not actually help against that since the
> attacker could still see if the users has visited site n by taking
> H(n) and searching for it in privacy badger's database.
> what does this stop: an attacker who can view pb data but doesn't
> know how to hash strings.
> other option: respect history clearing events, and remove domains
> from snitch map when they are removed from history.
> problem: this will break privacy badger if the user consistently
> clears their entire history.
So it appears that this is a local list (stored on your filesystem) that could be compromised and show your website history in the case of a local attacker accessing your machine. The "glib" remark to this is that you should be using full-disk-encryption with LUKS and a FOSS operating system as well, so this file shouldn't be exposed because any local attackers would have to defeat your encryption and get your machine to boot first. More realistically: suppose someone has access to this file. What else can a local attacker do on your machine to compromise your privacy? Do you really think they're going to go through a set of scrubbed website history (domains only, not URLs, no timestamps) to somehow ruin your life? If you don't clear your browser history entirely after every session you're exposing way more than this regardless. I fail to see how this is a significant issue in light of the fact that it requires local access to even become a problem.
As for issue #2, the fact that a browser extension (that you probably downloaded from the EFF) links to the EFF is not surprising. They update the do-not-track list, as well as the most recent cookie block list. The code is already coming upstream from the EFF (served from github, or the Chrome store, or the Firefox add-on marketplace, etc). Having to pull in up-to-date lists doesn't sound like the app isn't working as intended. I certainly can't maintain these lists and construct them myself, less so if I nuke all history of using the add-on every time I restart my browser.
Disclaimer: I do not work for EFF, all the information above was through a cursory search through the source on Github and probably doesn't reflect the full story, but the situation is certainly is more nuanced than "PrivacyBadger is secretly trying to undermine your privacy and security". It bothers me that people pull up minor things like this and shoot down projects that are legitimately working to try and make the web a place with less surveillance.