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

MDFP domains are marked as tracking in the snitch map #2351

Closed
bcyphers opened this issue Apr 19, 2019 · 4 comments · Fixed by #2377
Closed

MDFP domains are marked as tracking in the snitch map #2351

bcyphers opened this issue Apr 19, 2019 · 4 comments · Fixed by #2377
Assignees
Labels
bug MDFP Multi-domain first parties: lists of domains that should be treated as related to each other migrations Badger user data modifications

Comments

@bcyphers
Copy link
Contributor

I was investigating #2334, and realized one of my assumptions is wrong. When a third-party domain sets high-entropy cookies, Privacy Badger doesn't check to see whether the domain is on the MDFP list before updating the snitch map. As a result, even though Wikimedia domains are on the list, the seed dataset still has a full snitch_map entry for wikimedia.org. See https://github.com/EFForg/privacybadger/blob/master/src/data/seed.json#L10633.

This is because heuristicBlockingAccounting doesn't contain any MDFP checks. I think this is a bug because every other place _recordPrevalence is called does -- Privacy Badger won't record MDFP domains as trackers when they do fingerprinting or set localstorage cookies.

The fix should be pretty easy, but it will also require a migration (as talked about here.)

@bcyphers bcyphers added bug MDFP Multi-domain first parties: lists of domains that should be treated as related to each other labels Apr 19, 2019
@ghostwords
Copy link
Member

I have a fix in progress as part of #2198 (I think ... that part may not be pushed to GH yet). It didn't seem worth fixing by itself.

@ghostwords
Copy link
Member

Do we need a migration? As in, what does having MDFP'd domains in snitch map break?

@bcyphers
Copy link
Contributor Author

bcyphers commented Apr 21, 2019

The main reason I want to fix it is for issues like #2334 (comment). Right now MDFP domains have "false strikes" against them; if wikimedia.org is ever used in a third-party context on a domain outside its MDFP list, I think it will be blocked, even if it's never been seen tracking outside of the Wikimedia ecosystem. It also makes it harder to debug issues around MDFP domains when their snitch maps are full of other supposedly first-party domains.

@ghostwords
Copy link
Member

ghostwords commented May 22, 2019

The migration would go something like, for every site domain in snitch map (which passed the less-strict third-partyness check in heuristicblocking.js), see if the site domain is in fact third-party to the tracker domain (the correct third-partyness check in webrequest.js). If it's not, oops, it's a mistake, we should remove it. If this brings snitch map for the tracking domain below TRACKING_THRESHOLD, oops, we should undo the blocking. (What goes into undoing blocking?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug MDFP Multi-domain first parties: lists of domains that should be treated as related to each other migrations Badger user data modifications
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants