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.
> 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.