There's a balance between breaking the web and being as strict as possible. Saying we fully allow Facebook tracking isn't right [1], but we admittedly need more strict-mode like settings for privacy conscious users.
We do block Facebook at least as good as uBlock origin with EasyPrivacy. The referenced code is in a separate component which does the same as Disconnect blocking.
We're taking this seriously internally and we'll iterate on where we are to improve the situation. We're looking at if we can polyfill a local JS resource instead for example as one option if it doesn't make further requests.
The related commits are years old. This isn't new. Last commit to that line was 3 years ago with the comment "unblocking embedding of twitter timelines".
I'm trying to figure out if the code is still active case, but this is a quite recent ticket (after the release of the Chromium-based edition, and updated 4 days ago)
Then link to the new repo and provide context. Just highlighting a line with absolutely no context is sensationalist. I'm sure there have been public discussions about this.
I'm sure there have been public discussions about this.
Can you substantiate this? Because that would be extremely relevant to the conversation. Making statements with absolutely no context just seems sensationalistic.
If you're sure that there's been public discussion about the matter, then surely you won't have to spend too much time looking it up on Google? Backing up assertions takes energy. Are you motivated enough to champion your own assertions?
Hi Im Brave's CTO.
There's a balance between breaking the web and being as strict as possible. Saying we fully allow Facebook tracking isn't right [1], but we admittedly need more strict-mode like settings for privacy conscious users.
We do block Facebook at least as good as uBlock origin with EasyPrivacy. The referenced code is in a separate component which does the same as Disconnect blocking.
We're taking this seriously internally and we'll iterate on where we are to improve the situation. We're looking at if we can polyfill a local JS resource instead for example as one option if it doesn't make further requests.
[1]: https://github.com/brave/adblock-lists/blob/f25b698aff4666bb...
https://github.com/brave/adblock-lists/blob/f25b698aff4666bb...
https://github.com/brave/adblock-lists/blob/f25b698aff4666bb...
// Temporary whitelist until we find a better solution const whitelistHosts = ['connect.facebook.net', 'connect.facebook.com', 'staticxx.facebook.com', 'www.facebook.com', 'scontent.xx.fbcdn.net', 'pbs.twimg.com', 'scontent-sjc2-1.xx.fbcdn.net', 'platform.twitter.com', 'syndication.twitter.com', 'cdn.syndication.twimg.com']
a better solution for what, i wonder
That line is three years old, so how is this news now? And what's this "i wonder," do we not know how to use git here?
https://github.com/brave/browser-laptop/commit/c4cd7c1dc41a0...
https://github.com/brave/browser-laptop/commit/6edf56775f256...
https://github.com/brave/browser-laptop/commit/4c30cd08af9dd...
https://github.com/brave/browser-laptop/commit/0652274db0aee...
I guess it's new that it was discovered, nobody seems to have noticed while it's a major issue for a privacy tool.
Security vulnerabilities commonly are discovered after a product releases... sometimes many years later.
The related commits are years old. This isn't new. Last commit to that line was 3 years ago with the comment "unblocking embedding of twitter timelines".
https://github.com/brave/browser-laptop/commit/c4cd7c1dc41a0...
Also I just realized that is an archived repo that isn't used any more.
I took a quick look through the newer repos and couldn't find any kind of hard coded whitelist like that.
Am I missing something?
As mentioned by phit_: https://github.com/brave/brave-core/blob/master/components/b...
Ah, they put an underscore in the var name this time. Thanks for the link.
Huh ... I thought that must be a sensationalist headline but sure enough - a fresh download of Brave browser loads facebook.com on pinterest.com.
https://imgur.com/a/M4B9kJ2
"until we find a better solution" to what? More context would help.
Is this still in the current version?
It is not.
It's on the master branch... How did you determine it's not in the current version or will not be in the next version?
Brave has two versions, Muon (legacy) running mostly JS code, and the Chromium-based (current), running mostly C++.
The whitelist is in both versions
looks like it is? https://github.com/brave/brave-core/blob/master/components/b...
What makes you believe so ? https://github.com/brave/brave-browser/issues/1108
I'm trying to figure out if the code is still active case, but this is a quite recent ticket (after the release of the Chromium-based edition, and updated 4 days ago)
Looks like their claim about privacy protection is bogus, eh?
It is still whitelisted in current.
Three years old in an archived repo, hmm…
Way to ignore the comment directly before that line:
> // Temporary whitelist until we find a better solution
This post is sensationalist, flagged.
It's temporary since 3 years, that's why ;)
Then link to the new repo and provide context. Just highlighting a line with absolutely no context is sensationalist. I'm sure there have been public discussions about this.
I'm sure there have been public discussions about this.
Can you substantiate this? Because that would be extremely relevant to the conversation. Making statements with absolutely no context just seems sensationalistic.
I'm not entirely sure how I can substantiate an assumption.
If you're sure that there's been public discussion about the matter, then surely you won't have to spend too much time looking it up on Google? Backing up assertions takes energy. Are you motivated enough to champion your own assertions?