Cross domain tracking even with 3rd party cookies disabled.
State Informative (Closed)
Disclosed publicly 2018-08-07T22:46:40.235Z
Reported To
Weakness none
Bounty
Collapse


Timeline
submitted a report to Brave Software .
2018-03-30T19:15:36.506Z

Cross domain tracking
Default settings from Brave browser has 3rd party cookies disabled. Which I am assuming also disables 3rd part storage like IndexedDB etc. Because of this protection it is not possible for a 3rd party to track users across multiple domains.

But, Even though third-party cookies is disabled by default using Shared workers, a third-party is able to track the user across domains and websites.

REPRODUCTION STEPS
If you visit the these three pages in three tabs, you will notice that as a third-party it can learn the movement of a user across domains, even though the user has disabled 3rd party cookies.

https://cdn.cliqz.com/browser-f/fun-demo/some-random-page.html
https://cdn2.ghostery.com/browser-f/fun-demo/some-random-page.html

The third party script is being loaded from https://konarkmodi.github.io/

Impact

Because of this protection it is not possible for a 3rd party to track users across multiple domains. The demo is not very clever, but a 3rd party with a large footprint on the web can use this to track substantial web browsing behaviour of the user.

Regards,
Frans

  • 0 attachments:
kmodi Activities::Comment
2018-03-30T19:32:51.640Z
Also, this exploit can also be used to track user cross domain in private tabs. (Not across private tab and normal tab).


chocolatechipmuffin Activities::Comment
2018-04-02T04:20:13.052Z
Hi @kmodi, Thanks for your submission. We are currently reviewing your report and will get back to you once we have additional information to share. Regards, @chocolatechipmuffin


toml Activities::BugInformative
2018-04-02T19:27:52.880Z
Thanks for the report. We're aware of various vectors which can allow for cross-site third-party tracking, and we track some of them at https://github.com/brave/browser-laptop/labels/feature%2Fcontent-blocking. In particular, we're aware of the challenge faced by workers: https://github.com/brave/browser-laptop/issues/2418. In general, fingerprinting or third-party tracking vectors aren't in scope for bounties in our program. It's not that these issues aren't a problem for privacy on the Web, it's just that there's a fine line between disabling tracking vectors and keeping websites working. Because of the large potential for disappointment with otherwise-valid reports (like this one) we think that balancing those details is better suited for our product team than in bug reports.


kmodi Activities::Comment
2018-04-02T21:15:56.030Z
Hi @toml : Thank for responding. I respect what ever is the bounty policy. But I do not agree with the reasoning behind "disabling tracking vectors and keeping websites working". For the following reasons: 1. This issue was not about "Service workers" but instead about "Shared workers" : https://developer.mozilla.org/en-US/docs/Web/API/SharedWorker 2. Can you site some example where disabling "Shared workers" includes site breakage. In my experience, it should not break much, specially as compared to breakage one might observe with 3rd parties disabled. Shared workers can still function but double-keyed with origin. 3. I reported the same issue with Chromium, which was fixed (My naive understanding is that Brave picks some portion from Chromium) so I guess this port is missing. Issue: https://bugs.chromium.org/p/chromium/issues/detail?id=786187#c6 4. I tested the same on other popular browsers: a. Firefox b. Chrome / Chromium c. Opera All with third party cookies disabled, the worker functionality works, but tracking is not possible. So I think, Brave putting privacy first, should be able to do it as well. In any case, request you to make this report public, and since it does not need to be a private issue, we can open a ticket on https://github.com/brave/browser-laptop/issues/


toml Activities::AgreedOnGoingPublic
2018-04-02T21:46:22.941Z
I'm happy to make this public, and happy to work on this issue in public on our GitHub. Working in public is always preferable, where possible. I certainly agree that this is an issue we should work to fix. And indeed, double-keying cookies accessed by workers may well be the right fix. We do use a lot of code from Chromium, and are in the process of a big rewrite to use even more of Chromium rather than Muon, our security-focused Electron fork. If this is already fully resolved in Chromium then we probably just get that fix automatically. You can check our newer more-Chromium-based work at https://github.com/brave/brave-browser. It's still pretty rough around the edges and certainly not ready for primetime. If this is already fixed there then problem solved, right?


toml Activities::ManuallyDisclosed
2018-08-07T22:46:40.111Z