[Discussion] Remove Brave #657
No reviewers
Labels
No Label
🔍🤖 Search Engines
approved
dependencies
duplicate
feedback wanted
high priority
I2P
iOS
low priority
OS
Self-contained networks
Social media
stale
streaming
todo
Tor
WIP
wontfix
XMPP
[m]
₿ cryptocurrency
ℹ️ help wanted
↔️ file sharing
⚙️ web extensions
✨ enhancement
❌ software removal
💬 discussion
🤖 Android
🐛 bug
💢 conflicting
📝 correction
🆘 critical
📧 email
🔒 file encryption
📁 file storage
🦊 Firefox
💻 hardware
🌐 hosting
🏠 housekeeping
🔐 password managers
🧰 productivity tools
🔎 research required
🌐 Social News Aggregators
🆕 software suggestion
👥 team chat
🔒 VPN
🌐 website issue
🚫 Windows
👁️ browsers
🖊️ digital notebooks
🗄️ DNS
🗨️ instant messaging (im)
🇦🇶 translations
No Milestone
No Assignees
1 Participants
No due date set.
Dependencies
No dependencies set.
Reference: privacyguides/privacytools.io#657
Loading…
Reference in New Issue
No description provided.
Delete Branch "master"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This reverts commit
e06a19312a.Reasoning: we, the maintainers of Brave, do not have the necessary bandwidth to
respond to all complaints and/or trolling about Brave as a result of it
being listed on privacytools.io.
Fix #161
I'll remove any flames and trolling from this thread. I'd prefer not to remove Brave unless there's a good reason.
@diracdeltas, or anyone else from Brave:
Deleted comments:
@ciampolo
I said that if there's proof that they willingly mislead their users, we should warn our visitors. I did not say that Brave does willingly mislead users.
@diracdeltas
I meant the combination of that binary flag with other uncommon values. If you have a user with user agent X and a canvas fingerprint Y, and on next request he has a user agent X and a canvas fingerprint Z, they will appear as two different users. Though if you consider the canvas fingerprint variability a binary flag, you will see that it's the same user, characterized by
user agent: X, canvas fingerprint: variable.I once wrote a blog post about changing the canvas fingerprint once in a while vs on each request. I can't seem to find it now but generally, if you want to fade in, it's ideal to change your fingerprint on browser start. (It's ideal in combination with being aware of this, meaning that you will restart the browser/regen the fingerprint when you want a "new identity".)
Re: your last comment on the locked thread
Not sure I understand the difference between the two. My understanding is that it sums bits of entropy across all fields that it measures. Because bits is ~logarithmically proportional to the number of possible combinations of values for those fields, it is in fact "looking at the combination of your specific values".
(Another way of saying this is that the sum of entropy bits across different fields should be the same as the entropy of the total configuration. To give a basic example, assume you have two fair coins A and B, and want to know the entropy of the coin flip configuration A: heads, B: heads. The entropy of subsystem {A: heads} is
-1/2*log(1/2) = 1/2. The entropy of subsystem {B: heads} is the same. If you sum those, the entropy is 1. Now if you want to measure the entropy of the total system, you would do-1/2*log(1/4) = 1since now there are 4 possible configurations of the system. In either case the total entropy is 1.)May I ask you @diracdeltas how Brave's fingerprinting protection works?
What does the code do that is currently pushed into production for Brave. Just simple break down of the vectors and the way they are addressed is enough.
You're right, I guess. I meant the difference between summing the bits of unique fields and considering the uniqueness of the combination.
3+5 = 8b if you sum it. However, I now see that there's no other way to express the uniqueness of this combination than to sum these bits.
Look at the two bullet points in my comment if you reply to @ciampolo. A link to some document would be ideal. Resisting fingerprinting is difficult. Though it seems like fingerprintjs2 is capable of tracking Brave?
Sure. I am going to point at code that is in browser-laptop, even though that repo is now deprecated, since I'm most familiar with where things are in it. If something in browser-laptop has not been ported over to brave-core (the new rewrite of Brave), that is a bug. On iOS and Android (and the now-deprecated browser-laptop), we block various DOM APIs via a content script which is injected into pages prior to loading: https://github.com/brave/browser-laptop/blob/master/app/extensions/brave/content/scripts/blockCanvasFingerprinting.js#L169-L268. Equivalent in C++ in the b-l rewrite: https://github.com/brave/brave-core/pull/44
^ The settings in this file are all tied to the 'block fingerprinting' setting, which is set to 'block for 3rd party' by default (instead of 'block all') because blocking all breaks a lot of sites. I run brave with 'block all' and it usually works fine. Panopticlick will not account for our fingerprinting protection unless you use it in 'block all' mode.
Independent of fingerprinting protection, we also:
Re: the new brave repo, here is a large tracking issue for various things we have disabled: https://github.com/brave/brave-browser/issues/13
Experiment:
The fingerprints match.
Seems like Brave users can be tracked simply by their "ID" from fingerprintjs2?
@Shifterovich what version of Brave are you running? on 0.59, https://valve.github.io/fingerprintjs2/ doesn't report anything. EDIT: nvm, i see you mentioned i have to disable adblocking.
btw as noted above, we don't block fingerprinting by default (except for 3rd party frames) since it tends to break sites. it can be turned on in chrome://settings/ under 'Fingerprinting Protection'.
The desired result with the setting turned on is that all instances of Brave should report the same canvas/webgl fingerprint.
Changing the
Fingerprinting Protectionsetting does indeed change the fingerprint. It is still persistent with browser restart.Is it same for all Brave instances? If so, can you send the fingerprint it should show with the fingerprinting protection enabled, so that I can see that they match? The MD5 hash of the fingerprint (I want to make sure our values are the same, so I don't want to post my fingerprint here in plaintext) is
e2be8f03a707afc8733c0afb577ae72f:P.@diracdeltas So just the question then you (Brave) are aware that there are some vectors that cannot be fixed (easily) if you are using Chromium/Blink/Webkit as a base?
If you use Firefox as a base you actually help everyone since now there are way more internet users that look the same (Tor). The way you are currently doing it the system gets fragemented more and you (intentional or not) help in people being tracked more easily.
Also what is it about the Tor mode in Brave. What is Braves reasoning for this I am geninuenly curious as to why anyone should use Tor inside Brave instead of actual Tor Browser (which has probably like 99% of share of Tor users).
You can make a private FF by yourself. I'm glad they use Chromium, since it would be nice to have a private browser based on Chromium. I use Chrome instead of private FF because it's just so damn slow.
Also, Chromium is better security wise I think (likely related to its sandboxing).
On Linux I would kindly disagree (see archs reasoning why they disabled user namespaces; I agree with that decision whole heartedly).
Any browser run inside another user and something like firejail is more than secure.
Well then this is obviously just subjective but I for example assume that Chrome and Firefox are the exact same in speed (what a human can feel anyway). The difference is that Chrome's ui is more designed with psychology in mind. Remember the Windows Vista file dialog things ? People thought it was terribly slow although it actually wasn't; It was just the way the dialog was rendered and displayed information that made it feel slow.
@Shifterovich we did some internal testing with panopticlick and indeed noticed the fingerprint not being the same! that is either a regression on our part or fingerprint2.js has changed. i have opened an issue for this: https://github.com/brave/brave-browser/issues/2469
UPDATE: actually some of us didn't do the test correctly. on panopticlick, the value that we all get is
cf04c1dcb26ef79705764e5c22d0e711for canvas.https://browserleaks.com/canvas on the other hand reports n/a for fingerprint, which is expected.
https://audiofingerprint.openwpm.com/ also reports all 0's for audio fingerprint
@diracdeltas
Braves userbase is small so someone with your combination of protection scripts/extensions/whatever gets instantly flagged as Brave user. I am not saying to provide the real canvas/audio obviously not but that is what I want to say the whole time. A privacy browser cannot be based off of Chrom*. The only way to reliably fake data is to call oneself Tor. And in order to call onself Tor (and not be caught lying) you have to be Firefox.
If you have another way really please tell me I'd seriously love to hear.
Great. If all browsers have the same fingerprint with a specific setting enabled, that's fine by me.
Why does it report n/a? Does it (mostly) block canvas?
Note that the scripts can't be directly detected afaik. Though you can detect that the visitor is using a modern browser, yet doesn't support canvas. That's again a binary flag. It's tough to avoid them. For that reason, it's better* to change the FP on browser start, imho.
* but configurable, obviously
Well add to that all the other behaviour that only Brave exhibits (hiding WebRTC but leaking fonts) it is insanely easy to identify someone as using Brave.
And that is my second point I mentioned: You as Webkit descendant cannot (easily) fake Fonts and window decorations can you? Those are two things that will give away most users. You have to think about Braves target audience. Braves target audience is either people like @Shifterovich who just seem to like Chrom* for whatever reason or people who generally have an interest in privacy but don't want/know/care about the internals. The latter people will be the most vulnerable group but they will also be the exact one that will be the easiest to identify using e.g. Fonts and/or Window decorations.
Also how do you deal with the contentSize and media queries? Tor obviously reports the same for all 1000x900.
How does Brave tackle this problem since last time I checked it completely ignored it.
Also left off is the problem of zombie cookies. Firefox solves this with Containers. Webkit/Blink have nothing alike. What do you do against hosts that first party their trackers @diracdeltas ?
Btw read through your code a bit and good job on that part
Haven't seen that anyhwere yet.
@ciampolo i think you are saying two separate things:
Re: 2, I can't really argue with that until we grow more. If that is a basis for removing a browser from this privacytools.io, then I totally agree with removing Brave.
Re: 1, there's a lot of subissues you could be talking about. Let me try to enumerate a few of them.
Chrome is full of connections to Google domains - this is true and we try really hard to block/proxy all of them. We have a pre-build script that starts the browser for 2 minutes and looks for connections to Google domains, failing the build if any are found. For specific issues we have fixed, see https://github.com/brave/brave-browser/issues?q=is%3Aissue+label%3Aprivacy%2Fconnect+is%3Aclosed. At this time we don't think there are any google connections that are not initiated by the user. If we find any we mark it as blocking the next release.
It is difficult to leakproof Tor on top of Chromium - also true, because for one, Chromium uses the system TLS stack on MacOS/Win which doesn't respect whatever proxy is set in Chromium. For this reason we label Tor mode as experimental and state that the threat model is only to hide your IP from basic sites and network observers, not to protect against determined adversaries or give you true anonymity.
"You as Webkit descendant cannot (easily) fake Fonts and window decorations" - If by "cannot easily" you mean "requires C++ patching", that's not hard for us and we do it all the time for other stuff. We actually already have an issue for faking fonts: https://github.com/brave/brave-browser/issues/816
First party trackers - The old brave actually had the equivalent of containers (it was called "session tabs"). New brave doesn't have this because chromium doesn't easily allow you to put tabs from different sessions in the same window; there is an open issue for 'session windows' though. https://github.com/brave/brave-browser/issues/34
Also I want to reiterate that I am totally fine with removing Brave from privacytools.io; just joining this discussion to answer questions if people are curious.
That isn't my actual issue since that is easily verifiable and rather easily fixable. Idc about Google (literally blocked every known google ip) it is just about "Chrom* instead of FF" (I don't want to take "Brendan Eich" as a reasoning but whatever I guess)
That isn't really what I meant with "not easily" but regardless I'd love to know whether your variant works against https://browserleaks.com/fonts
Also the problem with window decorations is still there. And (I don't want to throw out wrong things as thus) I assume that you don't spoof contentSize, window size, media queries etc. because those values especially combined allow very easy identification and those values get updated instantly meaning there is a chance for race conditions which again would leak your true values. Firefox/Tor (as you probably know) just open the window so all of those values are just 1000x900
@Shifterovich I'd suggest to remove Brave for now. If the Browser actually reaches a mature state where it delivers on its premise add it back. At its current level there is no reason to use Brave over Ungoogled-Chromium with one or two extensions. Contrary it makes you more unique.
What? So what is the issue with Chromium?
Race conditions?
To be clear, right now we don't hide system fonts or window size but both are on the longer-term TODO list (not immediate priority but whenever someone has time to get around to it).
Implementation wise, for fonts I imagine we would do something like this:
For window size, IIRC Tor browser only reports large-ish discrete intervals for the height and width? We could do something like that.
The fact that Chromium can't hide itself properly without a huge amount of external investement (as seen by people developing addons to spoof the Fingerprint yet no one to date has been able to provide some solution), and the fact that Chrome does not have containerized tabs.
They seemingly do everything with userscripts. If you resize the window then both the Browser itself and the userscript try to update the window.innerWidth (example) which can still leak your real innerWidth. Although unlikely it can still happen which should never be the optimal/accepted solution.
@ciampolo yeah, there's a race condition with user-scripts and content scripts vs page scripts, which is why (in the new browser) we are doing the blocking in C++ instead of content scripts.
Does it not?
I remember Tor Browser told me to avoid resizing/maximizing the window (a long time ago probably), but that could have been fixed with their new version.
How exactly is it worse than Ungoogled-Chromium?
it goes in 200x100 steps if I recall correctly. But you don't want to fake that data though will you? Because that will again give you away since I can calculate for example the size of a div and then measure it with your reported screen size. Firefox resizes the window to like 1030x904 (random number) so the websites see 1000x900.
And it also affects media queries and all the js apis.
@diracdeltas The goals you posted seem very promising. If you actually reach (most) of those goals I will try Brave out. Until that time @Shifterovich should remove Brave from this list though since we clearly established that the current protection is broken malicious intent or not.
It does not since it would directly harm one of Googles primary ways of tracking people around the web.
This cannot ever be fixed (except VM and stream the contents terribly hacky stuff). See my first paragraph of this post.
Ungoogled Chromium is reported as normal Chrom*. So much higher user base than Brave. Now we established that Braves fp protection is currently broken (so it is actually easier to follow you than on Browsers without any fp protection). If I with a browser with 0.00001% market share visit a website and that website knows I am brave it is ridicolously easy to follow me is it not? Contrary if I use a stock Chrom* it makes it a little harder to follow me even if it is just 0.000001% more. And that is assuming I have no addons on Chrom*.
I'll redo the Panopticlick tests with FP protection on and will post the results here (in a few hours). Might be relevant.
User agent or otherwise? Brave's UA is also Chrome's. If you're talking about detection via non-UA DOM methods, I would be surprised if there was no way to tell Ungoogled Chromium apart from Chrome, given their differences.
Not sure what you mean by broken, but FWIW at least the canvas hash is always the same on panopticlick across various instances of desktop brave. https://github.com/brave/brave-browser/issues/2469#issuecomment-446395294
I know I made a bugtracker months ago on brave regarding among others the user agent.
And I would be surprised since the differences lie in the disabling of stuff that (should) is not accessible from JavaScript even through side channel attacks it shouldn't be. Else that would/should have already caused a huge uproar in Chromiums bugracker.
Well I thought we agreed that the fonts, the window sizes (etc.) are still leaking. As said go fix up your fp protection then @Shifterovich should gladly add you back. But currently there is no single reason to use Brave over ungoogled-chromium (give me one).
Seems like I always get
21.43 bitsregardless of FP protection being on/off.#661
This topic has been closed. but I will write my opinion here.
Yes Brave should be removed. why?
If you check the coders here:
https://github.com/brave/brave-browser/graphs/contributors
You will see that there is no a big community behind of project. No one (except the core developers) can tell us if the project is adware or not.
So no one from privacytools.io contributers can say if the project is safe or not. Maybe someone should listen the network with wireshark every second of the runtime of Brave. Or we should hack brave servers or something...
It is not enough to be open source. Android is open source, google chrome is open source but they are getting information more than closed source softwares.
If you can not say it is secure, you should not add it to privacytools.io.
That was the most important reason. If you will read this issue (and other old topics about Brave) from begging you will see that the problem is not technical. the problem is: no one is %100 sure if Brave is secure to use or not. So if we are not sure please remove it.
Something commercial must going behind of Brave. How the project goes without a big community. Let me answer! Money... So where the money comes from?
I can not say the same thing for Waterfox. because Waterfox has a realy big community, and it is not updated a lot like Firefox or Brave. I can say that waterfox project is not commercial.
Some other reasons:
it uses chromium. I will not going to find, but I had read many things on un-googled-chromium project, that they can not block google trackers %100 from chromium project.
for now firefox is enough (at least the best solution) with privacy extensions + user.js configs. So no need to think more until we feel realy safe with another browser.
The advertising think with brave is really scary. They block ads, and they show their own ads. is it not good to use firefox with open source adblockers?
I don't believe two things:
1- that the binary builds of Brave is only compiled from the source code from github repository. Anyway...
2- The contributors of privacytools.io does not use Brave browser all the time at home/work :) Please don't write apps that we are not feel free/safe with them.
We recommend many projects with less contributors.
I haven't noticed any ads on my computer created by Brave.
I guess you can create a pull request to remove index.html. It's very naive to think that it's possible to be 100% sure something is secure.
Another reason why we should remove Brave once and for all:
https://www.bleepingcomputer.com/news/security/facebook-twitter-trackers-whitelisted-by-brave-browser/
And: Brave Privacy Browser has a backdoor to remotely inject headers in HTTP requests
https://reddit.com/comments/ap9149
This isn't directly related to privacy or technology, but I have heard recommending to not use Brave, because the CEO is against equal marriage. Wikipedia
Edit: I 👎 the next comment for the words life choices.
@Mikaela irrelevant and besides the point. Political / humanist stances do not count where tech is concerned. You are either tracked or not. Whether your tracker disagrees with your life choices is completely unimportant here. Please keep it tech-focused.
@mikaela how is this relevant to the topic of discussion?
@beerisgood
https://www.reddit.com/r/privacy/comments/ap8rnv/brave_privacy_browser_is_whitelisting_trackers_of/eg74c8e/
https://www.reddit.com/r/privacy/comments/ap9149/brave_privacy_browser_has_a_backdoor_to_remotely/eg6vckb/
From https://github.com/privacytoolsIO/privacytools.io/issues/758 :
More evidence that Brave is just Malware to push profit towards their own cryptocurrency.
https://glitch.social/@tessaracht/101572578668968885
From my previous comment: https://twitter.com/BrendanEich/status/1094752832790552577 (thread)
@Shifterovich
Let take an example. For andorid yalp store is a must for rooted users (or ungoogled users). yalp store is developing by a few people. but there is no alternative.
But for now we have an alternative: firefox with usr.js + extensions.
You should not suggest an app which is writing by 2-3 persons with million lines of code. it is open source but will you suggest this app?
You can not notice. You should analyze... They change the ads with their own ads if I was remember... It is so easy to understand that?
No the project is yours. Its up to you. I just write my opinion.
Thank you
@beerisgood there is absolutely no information on that page to back up the claims made. It’s just FUD from what I can see.
I’ve used Brave for a while now and I haven’t seen any ads.
This idea they are replacing ads is kinda hilarious.
Show proof or seriously move on.
@androolloyd so I guess then all information about this on Internet is FUD then?
Must be the same FUD that they don't use YOU for creating their blockchain payment?: https://brave.com/features/
Made my day
@beerisgood you linked to the features page which doesn’t add anything to support your claim.
If you have more information to share from “the internet” I’ll happilly read it.
Would love to see some concrete evidence of users seeing Brave ads when ads are blocked.
Brave Rewards does not equal ad replacement.
@beerisgood @quantumpacket since you downvoted @androolloyd's comment, can you tell me which of the links above are backed by facts? It's some FUD that someone started on reddit from what I can tell (I don't visit r/privacy regularly).
Heya, Tom here from the Brave team. I don't relish the thought of jumping into this back-and-forth but I'd like to take a moment with some facts from our end.
We do have additional allow-list entires to unbreak sites which rely on third parties like Facebook for logins. We did this because we want sites to work when people try to use them. Without those allow entires, logging in with Facebook doesn't work.
We user the
x-brave-partnerheader to tell a limited number of sites that we're Brave rather than Chrome. We use this instead of a user-agent string because we want Brave users to be able to blend in with Chrome users in general. But sometimes we make deals with sites where the give stuff (like a free subscription) to people using Brave. So we have a list of sites which get to see this header and tell Brave apart from Chrome. That list isn't baked in, it's loaded dynamically so that we don't need to push a new release of Brave and wait for everyone to update before they can access whatever that offer is.On iOS where we're limited by WKWebView, we can't set that header properly when people are logging in — which is important for Coinbase Earn — so we switched to a cookie on iOS. The cookie just contains the same info, and it's the same for all Brave users.
We did make a security mistake in designing that system: the dynamic list could contain any header. Someone reported the issue via our bug bounty program and we're adding a strict check: we now only allow
x-brave-partner.@tomlowenthal Thanks for the explanation. I have a couple of questions:
x-brave-partnerheader? Again, some people prefer privacy over convenience and I think these things should be configurable. I can imagine some people being concerned about being detected as Brave by this header.it's loaded dynamicallyI assume Brave (the company) has to manually approve all of these sites?Thanks!
None of the lists we include are configurable yet. You can't add or remove additional blocked entries without manually editing files. More advanced configuration for people who know what they're doing is on our to-do list, but our current focus is reducing website breakage to make it easier for people without technical know-how to use Brave.
The only reason that we use Chrome's user-agent string is because there aren't yet enough people using Brave (in general) to use our own. We don't want a Brave user-agent string to be the thing which makes someone stand out in webserver logs. But we aren't committed to making Brave look like Chrome — only to making it hard to tell many instances to Brave apart from each other. If you're using Brave, sites can definitely tell that you're using Brave rather than Chrome, and that's only going to get easier as Chrome implements more web APIs which we don't include.
The only sites which get sent
x-brave-partnerare a handful of sites which we've manually chosen after careful vetting. You can see the list here — that's where the browser gets the list. We add sites to that list when we want to run a promotion with them, so they're always places where there'll be enough Brave traffic to hide in, not places where you'll stand out in a webserver log for using Brave. We're going to add a way to turn this whole thing off, but not urgently.