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

Feature Request: “Intelligent Tracking Protection”-alike #119

Closed
ron-wolf opened this issue Jul 23, 2020 · 3 comments
Closed

Feature Request: “Intelligent Tracking Protection”-alike #119

ron-wolf opened this issue Jul 23, 2020 · 3 comments
Assignees
Labels
wontfix This will not be worked on

Comments

@ron-wolf
Copy link

TL;DR

  • Safari & Privacy Badger have pre-emptive tracker detection, which is pretty cool
  • I found Safari’s implementation, and it’s open-source
  • I also found an explainer from Apple on how it works
  • Maybe this could augment Brave’s existing tracker blocking lists?

My idea

I am an ex-Safari user who switched to Brave once Apple neutered extension support (which is purported to be coming back using WebExtensions). I’ve been reading up in detail about how Apple implements Intelligent Tracking Protection in WebKit, the open-source counterpart to Safari (akin to Chromium for Google Chrome). ITP uses statistical methods to classify third-party domains as trackers, and gradually reduce their access to the user‘s browser the longer the user has gone without visiting their domain directly.

For those interested, I found a 2017 Apple blog post about the technology that does a pretty good job of explaining the feature, and why it works so well. The following snippet is of particular interest:

Out of the various statistics collected, three vectors turned out to have strong signal for classification based on current tracking practices: subresource under number of unique domains, sub frame under number of unique domains, and number of unique domains redirected to.

If the user has not interacted with example.com in the last 30 days, example.com website data and cookies are immediately purged and continue to be purged if new data is added.

However, if the user interacts with example.com as the top domain, often referred to as a first-party domain, Intelligent Tracking Prevention considers it a signal that the user is interested in the website and temporarily adjusts its behavior as depicted in this timeline:

Intelligent Tracking Prevention Timeline

If the user interacted with example.com the last 24 hours, its cookies will be available when example.com is a third-party. This allows for “Sign in with my X account on Y” login scenarios.

On the technical side, I found a page of documentation, and the feature’s location within the mirrored source tree. (Here is the Trac viewer for the original repository.)

To the best of my knowledge, that portion of WebKit’s source is licensed under a BSD-like license, while this repository is licensed under the MPL, as per Rust rules I presume. I’m not as familiar with cross-licensing as I’d like, but perhaps it would be possible to learn from Apple’s technology and incorporate something like Intelligent Tracking Protection in Brave? In the meantime, I am doubling up on Brave’s tracking protection using Privacy Badger.

@pes10k pes10k added the wontfix This will not be worked on label Jul 27, 2020
@pes10k
Copy link
Collaborator

pes10k commented Jul 27, 2020

Hi @ron-wolf , thank you for opening the issue. I dont think Brave will pursue a ITP like approach, mainly because Brave's protections are currently strictly stronger than ITP in nearly all cases (and that we're building other approaches for the small remaining differences).

ITP broadly does three things (there are some other aspects too, but they're mostly about escape valves for the below)

  1. Control who can have third party storage, and for what life time. ITP is a heuristic for who gets limited 3p storage. Brave blocks 3p storage across the board (with a very few minor web compat exceptions, that are limited to 1p-3p pairs, and which we have an underdevelopment approach to shrink further)
  2. A tricky, very conservative heuristic for stripping tracking parameters from expected bounce trackers. Brave maintains a set of known tracking-related query parameters already that we strip off universally (i.e. we dont rely on the loosey heuristic). https://brave.com/whats-brave-done-for-my-privacy-lately-episode5/ has more detail if you're interested
  3. Restricting the Life-time of JS accessible storage in the first party context. Brave currently already caps the lifetime of all JS set cookies in the first party context (and blocks all storage in the third-party context), and we're looking to see if we can be further aggressive here (so localStorage, indexDB, etc).

If its of interest, brave/brave-browser#8514 covers the approach we're pursuing to remove the few remaining 3p storage exceptions.

But, the main takeaway is that adopting ITP would reduce Brave's privacy protections, and result in re-enabling some forms of tracking, which we're of course not interested in doing :).

Hope that helps!

@pes10k pes10k closed this as completed Jul 27, 2020
@ron-wolf
Copy link
Author

@pes10k Thanks for the patient and thorough explanation! Most sites have worked just fine with Brave, so I wrongly assumed Brave’s implementation was more conservative than, say, Safari’s. I don’t know too much about the implementation, but let me know if there’s anything I could help with regarding brave/brave-browser#8514!

@pes10k
Copy link
Collaborator

pes10k commented Jul 30, 2020

@ron-wolf thanks much for the kind words and the offer! It'll probably be 2-3 months before we have a useful version of brave/brave-browser#8514 in nightly (its a very large, complex change from how Chromium handles things), but if you're interested then, we'd love to have more users testing it out and sharing their experiences with us!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants