Brave-browser: block domains on the tracking protection list until user consents

[tomlowenthal]

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?"

[bsclifton]

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)

[markwylde]

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.

[BrendanEich]

@markwylde please see https://www.reddit.com/r/privacy/comments/ap9149/brave_privacy_browser_has_a_backdoor_to_remotely/eg6vckb/.

@diracdeltas had a better idea noted here: https://twitter.com/brendaneich/status/1094752832790552577?s=21

[diracdeltas]

fwiw https://github.com/brave/brave-core/pull/1770 + https://github.com/brave/adblock-lists/pull/45 would make it such that fb/twitter are blocked as third parties except for the specific URL paths that are needed to make login/embedding work

[bbondy]

On this topic, I posted a new issue which describe some upcoming changes which will help get us to the place we need to be. It also clarifies some misconceptions that have been happening about our blocking.
https://github.com/brave/brave-browser/issues/3475

PRs for this are in progress now but nearing completion:
https://github.com/brave/brave-core/pull/1770/files
https://github.com/brave/ad-block/pull/181/files

[ghost]

fwiw brave/brave-core#1770 + brave/adblock-lists#45 would make it such that fb/twitter are blocked as third parties except for the specific URL paths that are needed to make login/embedding work

The reason Brave gained traction in the first place is because it showed people you could use Chromium (then in a Muon wrapper—which I quite liked) but still block all the adware on the internet. Until it was discovered you weren't blocking some of the biggest offenders. You lost me personally—an early promotor—when you went full Chromium. But this was the icing on the cake.

Again, for users who are confused about what's going on here Brave promised to block trackers and whitelisted some of the worst ones. If that doesn't say gatekeeper I don't know what does. I personally switched to IceCat on mobile and Firefox on my Desktop because of this and other missteps in this software.

Best of luck keeping your traction. Really.

[bbondy]

@jhabdas please stop assuming malice.

Not all users want to have a broken web for social login buttons, we're adding full control for those that prefer a partially broken web for extra protection.

See the future work section here:
https://github.com/brave/brave-browser/issues/3475
We're actively working on this on many fronts.

[ghost]

I don't assume malice. I assume negligence. As for social buttons—let them break they're all trackers.

[bbondy]

Your opinion is valid, but it's one of many. We'll be continuing with the plan which is detailed in the issue I mentioned above which will work for everyone.

[ghost]

I took a look but don't really follow the specifics. Here I just want to mention as a user I'd want to _opt into_ less security (perhaps with an _allow social_ in settings) as opposed anything else. In this browser you're mixing crypto with the social graph and that is a dangerous proposition IMO.

[bbondy]

Thanks @jhabdas, I appreciate the feedback.

Here's the summary of the plan:

• [x] [Step 1](https://github.com/brave/brave-browser/issues/3475): Unify tracking protection and ad-block exception handling in 1 place (via ad-block lib rules since they can be very specific)
• [x] [Step 2](https://github.com/brave/brave-browser/issues/3489): Add options to easily disable the exception rules, it will be allowed by default when this step lands as it is today for FB login buttons, embedded tweets, and embedded FB posts.
• [ ] [Step 3](https://github.com/brave/brave-browser/issues/3490): Add a UI which allows us to block by default but inform the user in case they want to enable the functionality.

We're moving forward on all 3 steps now, but we'll get there sequentially. Step 1 should land early this week.

About the prioritization change that you noted, yes it was wrongly prioritized and so it had to be updated. It won't be the last time that happens but thank you for calling it out.

There are issues that we have, we'll work on them transparently in the public as we go. Thanks for your understanding and for your time and focus.