[jonathansampson]

What browser fingerprint are you seeing in your research? I don't believe Leith et al found any such issue in their review at https://www.scss.tcd.ie/Doug.Leith/pubs/browser_privacy.pdf, nor did I in https://brave.com/popular-browsers-first-run/.

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.

[freediver]

Thanks for the attempt to clarify. My question was, what do you do with the IP address of the user that you get through these “phone-home” requests and I think it is left unanswered?

> 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?

[jonathansampson]

We drop the IP address. When needed, we'll convert it to a regional identifier (e.g. United States) so that we can have a count of how many users are in the US, UK, etc.

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.

[freediver]

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

It is quite realistic and possible. Both examples you gave can be opt-in. Perhaps I do not want my browser to arbitrarly show a malicious URL warning. Updating content blocker can and should be opt-in as well. Maybe particular rule set work well for my setup and I do not want the update to break it.

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.

This is based on what? You should really provide an argument when making a bold claim like this.

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.

[jonathansampson]

A browser which doesn't update security features upon install, startup, and on a regular interval, is an unsafe browser. Such an application might be okay for a power-user who understands the risks, but not for a popular browser built for all types of users.

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.

[freediver]

The browser should be a secure app to begin with, without making any automatic external requests (if anything, theses can make it less secure). Almost every other application behaves in this way.

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)

[jonathansampson]

The browser is secure "to begin with" because it is designed to adapt to the moving threat landscape of the Web. Attackers aren't static; we don't want to their targets to be static either. A browser that doesn't adapt rapidly, dies.