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

Fin.