Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't block domains by etld+1 for non-cookie tracking. #1527

Closed
cowlicks opened this issue Jul 25, 2017 · 2 comments · Fixed by #2891
Closed

Don't block domains by etld+1 for non-cookie tracking. #1527

cowlicks opened this issue Jul 25, 2017 · 2 comments · Fixed by #2891
Assignees
Labels
enhancement fingerprinting Relating to (canvas) fingerprinting detection heuristic Badger's core learning-what-to-block functionality important yellowlist Domains on this list are allowed but with restrictions: no referrer headers or cookies/localStorage

Comments

@cowlicks
Copy link
Contributor

When we see a 3rd party tracking on a website, we block the etld+1 associated with the 3rd party.

This makes sense when we see cookie tracking, because cookies are scoped by domain.

However it does not make sense for localstorage or fingerprinting tracking. Localstorage tracking is scoped to a domain. Fingerprinting tracking is probably most easily associated with URLs (or something like them).

An example of how this might be a problem:

  • we see fingreprinting tracking from a third party https://cdn.jsdelivr.net/fingerprintjs2/1.5.,1/fingerprint2.min.js
  • we block jsdelivr.net
  • this breaks stuff so we add jsdelivr.net to the cookieblock list (it is actually on there)
  • fingerprinting tracking can now continue, just as before

So we didn't actually fix anything.

It is hard to tell how big of an issue this is, since we don't get information about why a thing was blocked (related to #1289 #963), but we should keep this in mind as we develop a new action_map.

@cowlicks
Copy link
Contributor Author

related to #1505

@bcyphers
Copy link
Contributor

Some more context from badger sett:
in a 10k site scan, Privacy Badger detected 348 instances of canvas fingerprinting. 70 of those came from domains on the yellowlist. So Privacy Badger doesn't detect too much fingerprinting to begin with, but a pretty significant (~20%) portion of that fingerprinting comes from cookieblocked domains.

All 70 of those trackers used the 'toDataURL' function to do the fingerprinting (https://github.com/EFForg/privacybadger/blob/master/src/js/contentscripts/fingerprinting.js#L307). Since we are already wrapping this function in all third-party IFrames, we could have it return some harmless value instead of a meaningful data URL when the IFrame is cookieblocked. I think this would be a relatively small change -- will put together a pull request proof of concept at some point.

This isn't a great long-term solution, but it might be a good stopgap that doesn't involve fundamental changes to the way Privacy Badger's blocking engine works.

@bcyphers bcyphers self-assigned this Sep 16, 2020
ghostwords added a commit to EFForg/badger-sett that referenced this issue Apr 27, 2022
@ghostwords ghostwords added the yellowlist Domains on this list are allowed but with restrictions: no referrer headers or cookies/localStorage label Apr 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement fingerprinting Relating to (canvas) fingerprinting detection heuristic Badger's core learning-what-to-block functionality important yellowlist Domains on this list are allowed but with restrictions: no referrer headers or cookies/localStorage
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants