[jonathansampson]

A regional catalog is downloaded routinely. The only "data" going out is your region (e.g. the United States). This returns a protobuf catalog of ads for your region. Your device privately studies this catalog for relevant entries. When an ad is shown, it's presented as a native notification on the OS. This means the user sees a title (text), and a body (text). Screenshots of these notifications are on https://brave.com/rewards. I also covered this model in brief detail recently https://youtu.be/LsrrT502luI (skip to about 3:22 if you like).

[freediver]

> The only "data" going out is your region (e.g. the United States).

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?

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

[dane-pgp]

> private data like IP address of the user and browser fingerprint

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

[ehutch79]

How does it report the ad was viewed?

[jonathansampson]

When the notification pops on screen, you are granted the rewards. If your OS is not able to show the notification (due to Focus Assist, DND, or some other reason) then you are not rewarded (a future update to Brave will let users control visibility from within the browser entirely).

[nieve]

I believe the question was about the mechanism by which you viewing the ad is reported to Brave, not how the ad display was implemented. (A weird interpretation of "reported".)

[jonathansampson]

Our Rewards server distributes virtual tokens to the instance of Brave (which has an associated Payment ID). These tokens can be exchanged when ad notifications have been viewed, and when other ad-related events occur. The tokens aren't tied to any user information.

[9935c101ab17a66]

Not to nitpick, but you still didn’t answer the question. I don’t think anyone is confused over the concept “view ad -> get token”. The parent comment was wondering how you determine an ad was viewed.

[jonathansampson]

Apologies, I thought I did address that. Here's a deep-link to the process of "confirmation," which means a user has viewed an ad: https://github.com/brave/brave-browser/wiki/Security-and-pri....

[gentleman11]

and how do they prevent users from faking ad views to accumulate bat?