5 ms·

User gitarr on reddit[1]: 1) Privacy Badger maintains a separate, plain-text list of every domain you've ever visited: https://github.com/EFForg/privacybadger/

by tdkl 10y ago

User gitarr on reddit[1]: 1) Privacy Badger maintains a separate, plain-text list of every domain you've ever visited: https://github.com/EFForg/privacybadger/issues/1064 https://github.com/EFForg/privacybadger/issues/1064 2) Every time you start Firefox, Privacy Badger will connect to a IP on port 443. https://github.com/EFForg/privacybadger/issues/1065 https://github.com/EFForg/privacybadger/issues/1065 [1] https://www.reddit.com/r/linux/comments/5i7st0/the_new_and_improved_privacy_badger_20_is_here/db6curs/ https://www.reddit.com/r/linux/comments/5i7st0/the_new_and_i...

StavrosK 10y ago
How do we expect Privacy Badger to learn from domains we've visited if we won't let it store a list of domains we've visited?
- peteretep 10y ago
  Hashing
  - StavrosK 10y ago
    Give me a hashed list of all the domains you've visited and I'll tell you how effective that is.
    - koliber 10y ago
      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.
      - StavrosK 10y ago
        Yes, you could, and page loads would take 500ms per resource just to decide whether it should be blocked or not.
      - shakna 10y ago
        EFF have been working on something a little bit more practical, and have re-engaged activity on it. [0] [0] https://github.com/EFForg/privacybadger/issues/266 https://github.com/EFForg/privacybadger/issues/266
    - peteretep 10y ago
      Sure, no problem. Here are the last five: C4 AF AA 39 1A How effective is it? EDIT: here's the hashing code, in case it's helpful: substr(crypt($domain, "xx"),2,2)
      - StavrosK 10y ago
        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. Are you serious?
- AstralStorm 10y ago
  It should store them in the encrypted browser database.
tombrossman 10y ago
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?
feelslikefelt 10y ago
Welp, time to uninstall.
- ThatGeoGuy 10y ago
  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 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.
shakna 10y ago
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.

by tdkl 10y ago

StavrosK 10y ago

How do we expect Privacy Badger to learn from domains we've visited if we won't let it store a list of domains we've visited?

peteretep 10y ago
Hashing
- StavrosK 10y ago
  Give me a hashed list of all the domains you've visited and I'll tell you how effective that is.
  - koliber 10y ago
    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.
    - StavrosK 10y ago
      Yes, you could, and page loads would take 500ms per resource just to decide whether it should be blocked or not.
    - shakna 10y ago
      EFF have been working on something a little bit more practical, and have re-engaged activity on it. [0] [0] https://github.com/EFForg/privacybadger/issues/266 https://github.com/EFForg/privacybadger/issues/266
  - peteretep 10y ago
    Sure, no problem. Here are the last five: C4 AF AA 39 1A How effective is it? EDIT: here's the hashing code, in case it's helpful: substr(crypt($domain, "xx"),2,2)
    - StavrosK 10y ago
      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. Are you serious?
AstralStorm 10y ago
It should store them in the encrypted browser database.

tombrossman 10y ago

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?

feelslikefelt 10y ago

Welp, time to uninstall.

ThatGeoGuy 10y ago
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 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.

shakna 10y ago

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.