Lie. Brave doesn't track you. Your ad data never leave your machine (a bit like your bookmarks). The ad engine works privately on your computer and not on Brave server.
I can't really see how zero-knowledge proofs could solve this. There is no cryptographic way to prove that software executing on a clients machine triggered a notification. Especially on Linux where an open source notification manager could be modified to reject it.
I'm equally not so convinced on this anonymous ad system they claim to have built. The browser claims to generate an adID based on your history but encrypt this info to the advertiser. Maybe someone who has actually interacted with the ad platform can provide more insight on what information is exposed.
Zero-knowledge advertising sounds practically like an oxymoron to me, but hey they claim to have made it work.
A sufficiently-capable attacker could conceivably trick the browser into thinking a native OS ad-notification was displayed, we do rely on the OS to inform us at this point (though preview versions of Brave do not have this dependency), but we have considered this as well.
The main threat here would be an attacker who attempts to automate the confirmation process, and potentially duplicate it across various VMs or OS instances. Fortunately, we've considered this too. For reasons I hope are obvious, I can't go into greater detail here.
But yes, when you view an ad, that gets recorded somewhere (so that you can get rewards, and the advertiser can be billed).
You decide if you’re comfortable with this or not. The feature is easily turned on or off.
Every request Brave makes "home" will transfer private data like IP address of the user and browser fingerprint, regardless of the payload. Can you clarify what is done with this data?
Also if it is true what says in the article that some requests "home" can not be disabled, why is that the case?
Presumably it would send the same data whenever it checks for software updates too.
I can't think of a threat model where downloading updates and downloading ads are different in terms of user privacy (except, of course, that a malicious update can do far more harm).
I'm happy to discuss any requests you like; we also document all of this to the best of our ability on GitHub as well (https://github.com/brave/brave-browser/wiki).
As for disabling requests, this is a valid petition. Our goal is to have no extra requests when and where possible. We've worked hard to keep them to a minimal. There are some requests (e.g. product update requests) that we've been hesitant to make more easily blockable, since this could potentially leave large swaths of Brave users disconnected, and increasingly vulnerable.
> We've worked hard to keep them to a minimal.
How is 80 requests minimal? (source: your own above-mentioned article). It seems to me that 0 requests would be minimal.
What is preventing Brave from being a zero-telemetry browser by default?
I'm not sure where you saw 80 request; my network analysis post (https://brave.com/popular-browsers-first-run/) shows Brave issuing 70 requests over a 10-minute period. Compare with Chrome (91 requests), Firefox (2,799 requests), Edge (367 requests), and Opera (106 requests).
0 requests is not realistic, IMHO. When you launch a browser you want to make sure the user has a fresh local DB of known-malicious URLs (so you don't have to pipe each request through a look-up service, like Opera does) for client-side checking. You also want to make sure the client has an updated list of blocking rules for other types of content. There's quite a bit of setup needed when you launch a web browser.
Zero telemetry is unwise, assuming you want to build a product that works for a diverse set of users, devices, and environments. The main issue here is not whether you collect telemetry, but [how] you do so, and what that looks like. Brave is careful to preclude abuse from the design phase; see https://www.brave.com/p3a for more on how we handle Privacy-Preserving Product Analytics.
>0 requests is not realistic, IMHO. When you launch a browser you want to make sure the user has a fresh local DB of known-malicious URLs (so you don't have to pipe each request through a look-up service, like Opera does) for client-side checking. You also want to make sure the client has an updated list of blocking rules for other types of content. There's quite a bit of setup needed when you launch a web browser.
And maybe I just do not want the browser to send requests home.
And even if both of these are enabled these should be just two requests - what is going on in the remaining 68? It just looks like a very high number even if it is smallest among other test browsers (which doesn't make Brave good, just makes every tested browser broken in this regard).
>Zero telemetry is unwise, assuming you want to build a product that works for a diverse set of users, devices, and environments.
Zero telemetry should be the corner-stone of any privacy respecting product. Only zero telemetry ensures and guarantees that user privacy will be 100% respected. Everything else, even sending just one unwanted request "home" or anywhere else, can and should raise valid questions about what is done with the data including IP address since this will be closed source even in an open-source browser like Brave.
Telemetry is crucial to understanding how your product is used, as well as understanding what works and what doesn't. You cannot have one-on-one conversations with 30M+ users, which is how you learn, develop, and improve.
Brave needed to find privacy-respecting ways to achieve similar "conversational" insights. That's what we've done with Privacy-Preserving Product Analytics (https://www.brave.com/p3a/). P3A doesn't collect any user data, operates on a set of published "questions", and uses vague, range-based "answers". We also split up the requests to avoid developing a "fingerprint" from the answers.
Besides, malicious URLs directory and content blocking hardly qualify as 'security’ features.
Telemetry can be useful, and totally feel free to have as much of it as you want, as long as users opt-in into it. You seem to be making a lot of choices on the behalf of the user, when your default setup has whopping 70 requests “home".
There is a way to achieve everything you want, and for a privacy respecting product (or one claiming to be one) these choices absolutely need to be users' and not yours (by the very definition of the term privacy)