search

EFForg / privacybadgerfirefox-legacy

LEGACY Privacy Badger for Firefox SEE README
https://www.eff.org/privacybadger
Other
407 stars 68 forks source link

Periodically check for DNT policy updates to block/unblock sites #56

Closed diracdeltas closed 10 years ago

diracdeltas commented 10 years ago

Analagous to https://github.com/EFForg/privacybadgerchrome/issues/94.

garrettr commented 10 years ago

This is mostly already implemented (but commented out) in lib/policyCheck.js. Some things that should be resolved:

  1. The WorkerQueue should be tweaked to provide the exact behavior we want. Right now we push n domains to check into the queue, and check them one by one at a given interval (1s currently). Some improvements that could be made:
    1. Run requests in parallel batches (e.g. be processing 4 requests at a time).
    2. Detect if requests are failing and do something smart (maybe retry them again, sooner than the next 24hr interval, and stop the rest of the queue until then).
  2. @diracdeltas had privacy concerns. We should clarify these. I don't see a problem with sending requests to a site that users have already visited, since we aren't leaking information about any of their other history or behavior to that site (with the exception of their local network information. Perhaps over time, a nefarious site could use this to track them geographically?)
diracdeltas commented 10 years ago

@garrettr The timing of requests should be randomized, as I believe has been done in Chrome. Also, we should strip all cookies from the XHR request. Other than that, I don't have any privacy concerns that are blockers for 0.2.

garrettr commented 10 years ago

@diracdeltas Definitely we should strip the cookies. Why does the timing of the request matter?

diracdeltas commented 10 years ago

See https://github.com/EFForg/privacybadgerfirefox/pull/48#issuecomment-41857381.

diracdeltas commented 10 years ago

In particular, having a precise time of day for each user makes it easy to associate local network information over time with the same user.

garrettr commented 10 years ago

@diracdeltas I don't think it could really extended to a practical fingerprinting technique, especially because of the many variables affecting timing consistency, the long interval, and that it wouldn't persist over browser restarts. But it is leaking some information for no good reason, and it is easy to mitigate.

So the algorithm should be:

  1. recheck blocked sites on startup
  2. pick a random timestamp in (now, now+24hrs)
  3. repeat

What do you think? And do you want me to implement this?

diracdeltas commented 10 years ago

@garrettr Agreed that it should be mitigated anyway. Your algorithm LGTM!

Would be great if you took this ticket.

cooperq commented 10 years ago

Fixed by 0628e0788874fcd551fa650d845af075c18e3ce6