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 check for supercookies until document_idle #1522

Merged
merged 1 commit into from
Aug 12, 2017

Conversation

cowlicks
Copy link
Contributor

This should close #1483

My theory is that there is a race condition. The supercookie detection content script is injected at "document_start" which means it might check for the localstorage data before the other script can write it.

@ghostwords ghostwords self-requested a review July 24, 2017 19:06
Copy link
Member

@ghostwords ghostwords left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unlike fingerprinting detection, where our injection needs to happen before anything on the page does, "supercookie" detection merely iterates over localStorage entries, which we should be able to do at any point.

There are probably differences in what we find and/or how soon we find it when we iterate later rather than sooner. Maybe we'll pick up more localStorage than before with this change, because we'd notice localStorage written by a script within the same page load.

Injecting later might also have a beneficial effect on page load, although maybe not noticeable.

@cowlicks Could you run Privacy Badger through a set of URLs, the larger the better (with badgers.cowlicks.website?), and compare supercookie-attributed tracking domains we find before this patch to the supercookie-attributed tracking domains after this patch? You'd probably have to tweak Privacy Badger to store or log this extra information since we don't yet differentiate between the different kinds of tracking a domain may perform.

@ghostwords
Copy link
Member

Regarding the test that keeps failing on Firefox ESR, are you able to reproduce the failures when running the test locally with ESR?

@cowlicks
Copy link
Contributor Author

cowlicks commented Aug 12, 2017

This also fixes how test_should_detect_ls_of_third_party_frame would still fail.

With this patch:
https://travis-ci.org/cowlicks/privacybadgerchrome/jobs/263715388

Without it:
https://travis-ci.org/cowlicks/privacybadgerchrome/jobs/263715350

@cowlicks
Copy link
Contributor Author

@cowlicks
Copy link
Contributor Author

I'm happy to do some crawls with this patch later, to measure how much more effective this fix is.

But since it has already been demonstrated to be effective, useful, and not break anything, I'm merging it.

Yay! No more broken tests.

@cowlicks cowlicks merged commit aa381c1 into EFForg:master Aug 12, 2017
@ghostwords
Copy link
Member

How did we demonstrate this doesn't break anything? Having tests pass is not enough, we still need to do manual testing.

@cowlicks
Copy link
Contributor Author

@ghostwords do you have a specific concern about what this might break? I'm happy to add an additional test. I don't see how it could break anything other than the localstorage tracking detection, but I've manually tested that still works by changing the tests to run the previously broken tests repeatedly.

@andresbase andresbase added this to the W32-33 milestone Aug 14, 2017
@ghostwords
Copy link
Member

My point is that this simple change actually has a big effect on Privacy Badger's functioning, specifically via the localStorage tracking detection component, and that having tests pass doesn't tell us what kind of effects, positive or negative, this change will have on actual user experience.

On the other hand, performing a couple of crawls, automated or not, and examining the results (here focusing on localStorage tracking detection) before and after the change will give us a pretty good idea of how we did.

This is something you should be able to do manually (with a few code tweaks to log localStorage findings for review) in a matter of hours.

@cowlicks
Copy link
Contributor Author

I crawled 20 websites that are likely to use optimizely's localstorage supercookie tracking (found here). Before this pull request, we were missing every first instance of localStorage super cookie that I saw.

I crawled 20 urls.

  • before 0
  • after 9

We should be catching all of them, but that can happen in another PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

async_tracking_misattribution_bug test is sporadically but consistently failing on Firefox ESR
3 participants