Our great sponsors
-
-
crxviewer
Add-on / web app to view the source code of Chrome / Firefox / Opera 15 extensions and zip files.
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
"…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."
Telemetry and Privacy aren't necessarily at odds with one another; it depends on how your telemetry is implemented. We have detailed our approach in detail on our Blog (see https://brave.com/privacy-preserving-product-analytics-p3a/). We also document the questions and possible answers on GitHub at https://github.com/brave/brave-browser/wiki/P3A.
"Suspicious behavior which installs 5 extensions"
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.
Continued below...
"…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."
Telemetry and Privacy aren't necessarily at odds with one another; it depends on how your telemetry is implemented. We have detailed our approach in detail on our Blog (see https://brave.com/privacy-preserving-product-analytics-p3a/). We also document the questions and possible answers on GitHub at https://github.com/brave/brave-browser/wiki/P3A.
"Suspicious behavior which installs 5 extensions"
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.
Continued below...
Is anybody is looking for more information, check out https://creators.brave.com
> HTML filtering is the ability to filter the response body of HTML documents before it is parsed by the browser.
> For example, this allows the removal of specific tags in HTML documents before they are parsed and executed by the browser, something not possible in a reliable manner in other browsers. This feature requires the webRequest.filterResponseData() API, currently only available in Firefox.
https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...