"Their adblocker is just a fork of uBlock Origin…"
Claims like this should be supplemented with links to our source code (see https://code.brave.com), if true. I'm not sure what gave the author this impression; Brave's built-in ad-blocking does use public lists in addition to our own efforts, but that isn't the same as being a fork of uBlock Origin. That being said, uBO is a fine extension, and you should definitely be using it (if you're not using Brave).
"They’re whitelisting trackers from Facebook and Twitter, so they can use scripts in third parties' websites to track you across the web."
This is also quite misleading. It stems from a claim made back in 2018 about our now-retired "Muon" build of Brave. We had a file which listed third-party scripts which shouldn't be blocked (so as not to "break the Web"). Among these were particular Facebook and Twitter scripts, because Facebook and Twitter content is embedded all throughout the Web (think of embedded Tweets, posts, videos, etc.). As such, it's important to permit this content to load, but to prevent it from utilizing any persistent storage (e.g. cookies). Not only were these scripts prevented to accessing storage, Brave also modified or discarded the referrer header on these request. This wasn't ever a case of "whitelisting trackers".
"They’re blatantly lying to their users. Anyone who knows a bit about how JavaScript…"
Responding to a previous explanation for the "whitelist", the author emphatically claims the engineers at Brave don't understand how JavaScript works. If I'm not mistaken, the author is responding to Brendan Eich (Brave's CEO), who happens to also be *the creator of JavaScript*.
"Another problem with their built-in adblocker is that it’s better for extensions to be separated from the core of the browser, since they don’t follow each other’s update cycles. This means that you need to update the entire browser to fix a bug in the adblocker. Stupid, isn’t it?"
Agreed, which is why Brave's ad-blocking logic is broken out into a distinct component. You can see it enumerated on brave://components, and even request updates from that page as well. It would have been very unwise to require a full browser update just to deliver updates to ad-blocking rules, etc.
> Note: By this point, it should be clear to the reader that the author is unqualified to conduct such a review. A cursory review of Brave's source (both in the archived 'Muon' repo and our active code.brave.com endpoint) would have answered many of their questions. A review of Brave's network activity, such as the one I conducted this year (see https://brave.com/popular-browsers-first-run/), would have addressed many claims to follow.
"It’s important to bring focus to the fact that Brave isn’t more than Chromium with another skin and a built-in adblocker with reduced functionality."
"Rewards is their shitty program that will replace ads displayed on websites with their own."
Another easily-disproven claim, showing the author likely has never used Brave. Brave *does not replace ads on websites*. Brave's Ad system is opt-in, user-configurable, and displays ad notifications as native system notifications. These appear as prompts on your desktop or screen, outside of the browser itself.
"…they’re tracking you with Rewards…"
Again, where is the network analysis or source code to substantiate this claim? The author doesn't provide anything, because it's simply not true. Brave Rewards is designed to preclude tracking. Rather than having user data flow out to remote servers (the way Google Ads and more work today), Brave Rewards keeps the user's data on their device, and routinely downloads a regional ad catalog. This inverts the traditional digital advertising model. I covered this system in a bit more detail recently in a 5-minute talk on the history of digital advertising, and how Brave is fixing the industry. You can watch that talk at https://www.youtube.com/watch?v=LsrrT502luI.
"…it’s important to say that Rewards uses Uphold…"
The author then takes a jab at KYC, the process of confirming your identity by providing ID and other information. No user of Brave Rewards is required to do this. Users are able to opt-in, participate, earn, and pass along rewards to content creators and publishers. If a user wishes to "cash out," however, they do have to verify their identity in compliance with relevant laws and regulations. But this is not handled by Brave; we do what we can to stay away from your data. Instead, Uphold (and soon Gemini) handles this process.
"Contrary to popular belief, Rewards isn’t opt in."
The author here conflates calls to certain endpoints with program participation. They are correct that Brave would make calls at times to our own rewards server, but not because the user has been auto opted-in. Those calls would attempt to locate rewards for the current user, and they would respond with an error or an empty balance, since the user hasn't opted-in. We've been working on cleaning up these types of unnecessary calls; I think this one resulted when the user clicks on the Rewards panel. By default the panel would expand and ask the user if they would like to opt-in. If the user were already opted-in, the panel would expand and attempt to retrieve their balance. The buggy behavior here was the attempt to retrieve a balance in both states. If you ever spot an issue like this, please do let us know But again, no ad notifications are shown, and no ad catalogs are downloaded until a user opts in.
"…they fetch affiliates for Brave Rewards, with pings such as Grammarly, Softonic, Uphold, etc."
Another basic mistake from this author. They're referring to custom headers. These don't ping anybody. We document the headers on GitHub (see https://github.com/brave/brave-browser/wiki/Custom-Headers), explaining there that these serve as a substitute for a custom user-agent string (which Brave lacks). These don't identify the user to anybody, make any bad-door network calls, or anything. Again, the user is clearly not qualified to discuss these technical topics, and has done little (if any) homework on the matter.
"They also make requests to various domains… There isn’t a way to opt out from sending this requests."
A few domains are shared, but these again aren't explored any more deeply. I covered these endpoints in my network analysis (see https://brave.com/popular-browsers-first-run/); many are also covered in the document detailing proxies (see https://github.com/brave/brave-browser/wiki/Deviations-from-...) we have setup with Google services to prevent users from making contact with Google. This is yet another example of where the user could have opened a Web Proxy Debugger like Fiddler or Charles and examined the network activity to understand what's going on.
"Brave has built-in telemetry. …a lot of people believe in their marketing and think that Brave is private out of the box."
The author is, again, showing their lack of experience and effort in this area. Again, they could have found this information covered in our source code (see https://code.brave.com), in my network analysis (see https://brave.com/popular-browsers-first-run/), or even by inspecting the CRX files themselves in something like Rob Wu's CRX Viewer (see https://robwu.nl/crxviewer/).
"There is a ton of criticism about Firefox’s Pocket. But Brave has something similar, which is called Brave Today."
Brave Today is available on the new tab page, but doesn't actually make any network calls unless you open it up. This was important to us, since we aim to keep Brave as clean and quiet as possible. From a new tab page, you have to scroll down to trigger network activity. But this deferring of request isn't all we've done to make this system as private as possible. Brave also drops request headers, pads resource bytes, and more. The padding of resource bytes is really neat; no matter which image is being requested from the Brave CDN, its file-size is always the same (meaning no network-connected sleuth can infer your network activity by watching image file sizes). We talk about this system in greater detail on our blog. See Brave's Private Content Delivery Network (see https://brave.com/brave-private-cdn/).
The author then takes aim at Brave’s “SafeBrowsing”. Brave uses Google's SafeBrowsing service to protect users from harmful sites and more. Similar services are used by practically all major browsers today (many using SafeBrowsing). What matters most here, again, is implementation. SafeBrowsing has a LookUp API and an Update API. One of these sends data with each request to Google for their judgement. The other routinely downloads a database of potentially harmful URLs and performs the lookup locally, on the user's device. Brave takes the latter route. And the routine database updates are proxied through Brave server's, meaning users aren't making any direct contact with Google. This was also covered in my network analysis (see https://brave.com/popular-browsers-first-run/) earlier this year. Compare and contrast with something like Opera to see how others perform similar lookups.
"It’s a concerning issue for a “privacy” oriented browser to connect to Cloudflare’s and Google’s domains, since both of them are telemetry."
The author here is referring to proxied URLs, which were already addressed. They claim these are "telemetry," which is absurd. Telemetry is about understanding how users and products intersect. To suggest Brave is doing any telemetry here, or assisting Google/Cloudflare with Telemetry, would require the author to provide something substantive. They don't, however, because they aren't technically qualified to conduct this type of review in the first place. Also, they note receiving a 404 when attempting to access these endpoints. This is because the user failed to note that these receive POST requests, rather than GET requests. The latter results in a 404.
"Brave will check for updates every time you run it. …Brave’s dedication to privacy is truly amazing /s."
Yes, and? Software that remains up-to-date typically remains safer and more secure. We're not about to have our 30+ million users running outside, vulnerable, and brittle versions of Chromium which have known, published exploits in the wild.
"Brave has been caught inserting affiliate codes…"
Not much of a scandal here. Brave shipped an update which would offer users affiliate-versions of particular URLs. The goal here was to detect pre-search input (no network activity involved), and offer up an affiliate link if one was available. The user could then decide to visit a URL with or without traffic attribution. We blogged about this in "On Partner Referral Codes in Brave Suggested Sites (see https://brave.com/referral-codes-in-suggested-sites/)". As stated there, the intent was to offer referral options during searches. Our mistake was also matching fully-qualified URLs. Once the issue was found, it was quickly resolved. It's important to note that traffic attribution is not necessarily malicious, anti-privacy, or a matter of security. The author has been suggesting users switch to Firefox; has the author conducted a search from Firefox? Is the author aware, as revealed in a network analysis (see https://brave.com/popular-browsers-first-run/), that keystrokes are asynchronously fed to Google, and that each request is marked with a Firefox identifier for traffic attribution?
"Who the fuck implements Tor but doesn’t change the DNS?"
Ah, that issue. Again, the user hasn't done their homework. What they're referring to here was the recent bug with Brave's Tor context which would emit a DNS lookup, potentially exposing your traffic to your ISP. Let me be quite clear, that is bad. Really bad. Which is why we fixed it without hesitation. That said, was this an example of Brave not knowing how Tor works? Or how DNS works? Not at all, as the author seems to have left out some important context.
Brave has supported Tor for a long time, and without any DNS lookup issue. So what caused this issue? It was actually Brave's effort to remain ahead of the industry in terms of security and privacy, believe it or not. In late 2020 we blogged about Fighting CNAME Trickery (see https://brave.com/privacy-updates-6/), and the growing trend of third-party trackers finding ways to plant themselves on first-party domains. To combat this, Brave added a DNS lookup to resolve first-party endpoints and evaluate the endpoint with our block lists and more. This gave Brave the unique ability to identify third-party trackers even when they masquerade as first-party requests. But, we failed to limit this feature only to standard browsing contexts. Having a feature like this makes you one of the most secure and private browsers on the market. Having it in a Tor context, however, means potentially leaking some network activity. This was not a case of Brave failing to understand how Tor or DNS works; this was a case of Brave taking the initiate to do something bold, and stumbling in the process. When you lead, everybody gets to see your mistakes.
"Possible scam and theft?"
Betteridge's law of headlines is an adage that states: "Any headline that ends in a question mark can be answered by the word no." One issue the user does bring up here (by link, not explicitly) are a set of changes made to Brave's UX/UI following feedback from content creators in 2018. We blogged about this in greater detail at https://brave.com/rewards-update/. In summary, our UI/UX was somewhat confusing. We made a few rapid changes, which resulted in a substantially much better system. This was, in my opinion, a stellar example of how crucial community feedback is to developing a solid product.
"Hostility towards forks"
More nonsense. Brave has no problem with forks; we do have a problem with those wishing to copy and paste Brave under the name "Braver". That should be quite obviously a bad-faith gesture. The individual(s) behind this proposed browser (there were at most 2 or 3 people) soon realized how much work goes into developing a browser, and the effort fell apart. But forks of Brave exist today; Dissenter (don't use this browser! (see https://twitter.com/BraveSampson/status/1350685642846572546)) and PreSearch for iOS being a couple examples.
In summary, if you want a technical review of Brave, don't get it from randos on the Internet Look instead to competent engineers, such as the work done by Douglas Leith (see https://www.scss.tcd.ie/Doug.Leith/pubs/browser_privacy.pdf) and others at Trinity College in Dublin. Their abstract is as follows, "We measure the connections to backend servers made by six browsers: Google Chrome, Mozilla Firefox, Apple Safari, Brave Browser, Microsoft Edge and Yandex Browser, during normal web browsing. Our aim is to assess the privacy risks associated with this back-end data exchange. We find that the browsers split into three distinct groups from this privacy perspective. In the first (most private) group lies Brave, in the second Chrome, Firefox and Safari and in the third (least private) group lie Edge and Yandex."
"Their adblocker is just a fork of uBlock Origin…"
Claims like this should be supplemented with links to our source code (see https://code.brave.com), if true. I'm not sure what gave the author this impression; Brave's built-in ad-blocking does use public lists in addition to our own efforts, but that isn't the same as being a fork of uBlock Origin. That being said, uBO is a fine extension, and you should definitely be using it (if you're not using Brave).
"They’re whitelisting trackers from Facebook and Twitter, so they can use scripts in third parties' websites to track you across the web."
This is also quite misleading. It stems from a claim made back in 2018 about our now-retired "Muon" build of Brave. We had a file which listed third-party scripts which shouldn't be blocked (so as not to "break the Web"). Among these were particular Facebook and Twitter scripts, because Facebook and Twitter content is embedded all throughout the Web (think of embedded Tweets, posts, videos, etc.). As such, it's important to permit this content to load, but to prevent it from utilizing any persistent storage (e.g. cookies). Not only were these scripts prevented to accessing storage, Brave also modified or discarded the referrer header on these request. This wasn't ever a case of "whitelisting trackers".
"They’re blatantly lying to their users. Anyone who knows a bit about how JavaScript…"
Responding to a previous explanation for the "whitelist", the author emphatically claims the engineers at Brave don't understand how JavaScript works. If I'm not mistaken, the author is responding to Brendan Eich (Brave's CEO), who happens to also be *the creator of JavaScript*.
"Another problem with their built-in adblocker is that it’s better for extensions to be separated from the core of the browser, since they don’t follow each other’s update cycles. This means that you need to update the entire browser to fix a bug in the adblocker. Stupid, isn’t it?"
Agreed, which is why Brave's ad-blocking logic is broken out into a distinct component. You can see it enumerated on brave://components, and even request updates from that page as well. It would have been very unwise to require a full browser update just to deliver updates to ad-blocking rules, etc.
> Note: By this point, it should be clear to the reader that the author is unqualified to conduct such a review. A cursory review of Brave's source (both in the archived 'Muon' repo and our active code.brave.com endpoint) would have answered many of their questions. A review of Brave's network activity, such as the one I conducted this year (see https://brave.com/popular-browsers-first-run/), would have addressed many claims to follow.
"It’s important to bring focus to the fact that Brave isn’t more than Chromium with another skin and a built-in adblocker with reduced functionality."
Wrong, again. Brave is a heavily patched version of Chromium, deviating in many ways (see https://github.com/brave/brave-browser/wiki/Deviations-from-...) from the base project. Again, this would have been quite clear to the author if they compared the network activity of Chrome and Brave (see https://brave.com/popular-browsers-first-run/).
"Rewards is their shitty program that will replace ads displayed on websites with their own."
Another easily-disproven claim, showing the author likely has never used Brave. Brave *does not replace ads on websites*. Brave's Ad system is opt-in, user-configurable, and displays ad notifications as native system notifications. These appear as prompts on your desktop or screen, outside of the browser itself.
"…they’re tracking you with Rewards…"
Again, where is the network analysis or source code to substantiate this claim? The author doesn't provide anything, because it's simply not true. Brave Rewards is designed to preclude tracking. Rather than having user data flow out to remote servers (the way Google Ads and more work today), Brave Rewards keeps the user's data on their device, and routinely downloads a regional ad catalog. This inverts the traditional digital advertising model. I covered this system in a bit more detail recently in a 5-minute talk on the history of digital advertising, and how Brave is fixing the industry. You can watch that talk at https://www.youtube.com/watch?v=LsrrT502luI.
Continued below...