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

Long-term solution to tracking protection whitelist #1108

Open
tomlowenthal opened this Issue Sep 13, 2018 · 3 comments

Comments

6 participants
@tomlowenthal
Copy link
Member

tomlowenthal commented Sep 13, 2018

In app/trackingProtection.js:

// Temporary whitelist until we find a better solution
const whitelistHosts = ['connect.facebook.net', 'connect.facebook.com', 'staticxx.facebook.com', 'www.facebook.com']

Currently hosts that are on the Tracking Protection list but cause some important functionality (like fb login) to break are added to this whitelist so they don't get blocked. My preferred long-term solution is to block by default but detect when a site is likely to break and pop up a dialog asking the user if they'd like to allow the domains to potentially track them.

Concrete example:

  1. user loads coolsite.com
  2. Brave sees a request to connect.facebook.net to download sdk.js or all.js and infers that coolsite.com is going to use a Facebook feature
  3. Brave shows a dialog that says, "Allow connections to connect.facebook.net and www.facebook.com so that you can use Facebook features (such as login and like buttons) on this page?"

@bbondy bbondy added this to the 1.x Backlog milestone Sep 13, 2018

@tomlowenthal tomlowenthal added this to Untriaged Backlog in Security & Privacy Oct 31, 2018

@tomlowenthal tomlowenthal removed this from Untriaged Backlog in Security & Privacy Oct 31, 2018

@tomlowenthal tomlowenthal added this to P3, P4, & P5 Backlog in Shields Nov 6, 2018

@bsclifton

This comment has been minimized.

Copy link
Member

bsclifton commented Nov 7, 2018

This came up in a recent Slack conversation (https://bravesoftware.slack.com/archives/C7VLGSR55/p1541483663510700) - I wanted to capture some notes about a different use-case

  1. View this link: https://www.theverge.com/2018/11/5/18066082/baby-bear-mountain-climb-russia-drone-pilot-endangered
  2. Scroll down to where tweet is embedded with a video
  3. Try to play video; it doesn't work

I believe it's being blocked because certain hostnames are not part of the inclusion list when 3rd party calls are being made (ex: to twitter.com from theverge.com). Per the original issue, we could prompt the user ("Allow twitter.com to show this embedded item?). Another option would be to intercept and obfuscate the request (hide cookies, etc)

@rebron rebron removed this from the 1.x Backlog milestone Feb 7, 2019

@markwylde

This comment has been minimized.

Copy link

markwylde commented Feb 10, 2019

This came up on hackernews today, although it's been flagged:
https://news.ycombinator.com/item?id=19129309

Maybe I'm missing something, but this is a pretty big issue for a browser that claims to be privacy focused. Can we not escalate this a little. We're whitelisting one of the most controversial companies at the minute. This can't be good for PR.

@bbondy bbondy added priority/P2 and removed priority/P5 labels Feb 11, 2019

@brave brave deleted a comment from jhabdas Feb 12, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment