[BrendanEich]

We do not insert any ads.

In 2016 we proposed that Brave, a browser, could allow users and publishers to get better revenue through a private ad model that does not entail any tracking or user data in the clear on servers. We ran some placeholder ads to show the concept off. These are disabled now.

This caused a reaction. The letter we got (I mentioned it in my last comment) from a publisher group asserted that the publishers own copyright and trademark on third-party ads on their sites. This was comical in view of malware getting on the New York Times, BBC Online, AOL and other sites the month before (March 2016). Publishers do not own (c) or (tm) on any ads they don't create, of course -- certainly not on so-called third party ads, especially malware. Or they'd be liable.

Anyway, baseline Brave is just a top-speed (better than using JS in extension code) blocker by default. All token options are optional, users and (if involved) publishers choose.

[pythux]

> Brave is just a top-speed (better than using JS in extension code) blocker

Did you run some comparison to back this? I would love to see some numbers.

[BrendanEich]

Manuel Araoz did a very early benchmark, one site, where we beat uBO. I don't cite it as fresh or large-N/controlled, but Manuel noticed and asked why. The reason is extensions must be in JS, in API and process sandboxes. uBO does great, uses the chromium extension background page facility to share code among tabs, but still must use JS. C++ beats JS. Also, we block ASAP in the network threads, in the browser "kernel" process. That helps win too.

If anyone wants to benchmark, results welcome, but we do not view uBO on Chrome as competition -- rather we cooperate on blocking tech where we can with @gorhill et al. We are out to take unblocked Chrome user share.

[pythux]

Thank you for the clarification! Do you know how much time is lost between the time a request is handled by the kernel in C++ and the time it would trigger a callback of the web request API? In other words, what is the overhead of the JS API compared to the raw C++ API?

I understand that you are not competing with uBlock. But I’m always a bit sceptical when I read that it’s faster because it’s C++. Since it is not necessarily true and some measurement is needed before being able to reach this conclusion. I understand though that blocking from the network gives some (constant factor?) advantage compared to a JavaScript extension.

[BrendanEich]

I don't have measurements, as noted (others should chime in), but it matters not only in time to get to extension page process or tab process -- C++ in same process vs. JS after C++ across process boundary matters in memory use terms too, direct (allocation) and indirect (cache effects).

I've been doing browsers since JS was super-slow, advocated its use in Mozilla XUL UX back in the day without it being an issue _per se_, watched JITting JS engines make it even less of an issue for such 10Hz or even 60fps deadlines when done right -- but C++ over JS and in same process vs. multiprocess matters for blocking, due in large part to how many requests there are, and how they affect page rendering.

We are benchmarking again now that we have staff, so I'll try to update here if I do get any results. I don't believe we are yet testing vs. uBO+Chrome, though, for the reason given. We are allies.

[BrendanEich]

Note that browsers already do the mechanics of inserting ads today, unless the ad is a fixed element on the served page, which is quite rare. Even then, to pay, ads need confirmation tracking if not target tracking before placement by scripts.

In this sense, all browsers insert the vast majority of ads today. Intermediary businesses insert scripts before, during, and after ads too. Browsers and extensions may block scripts.

The part of the ad ecosystem that Brave transposes to the browser, again if and only if each user and (if in the deal: ad slot in page, not in user space) publisher agrees, is the matching of ad to context including user interest, and the attribution and confirmation of ad view or interaction. This is done without any tracking or user data on servers — including our servers. Also no user fingerprinting on any blockchain, it is super-important to avoid this.

How matching works: if you opt into the ad system, you get a catalog, same as everyone gets in a large region speaking the same natural language. The catalog lists edge url and metadata on each ad or offer. It compresses well and slowly updates. Downloading it or updating it with new ad deals for all in the region/language does not identify you. We have started with global/English for trials.

Local machine learning studies local data, again only if you opt in. This agent sees the sum of all user inputs to the browser: search queries (you own your query log — the search engine does not and the agent does not scrape search results, just user inputs and navigation); e-commerce form filling and buying; social graph edges from you to your friends; tab and window constellations; scrolling on actually viewed content.

With our secret-key cross device sync option, your data can be a full cross device view of your browsing, and only you have the key to decrypt this data. We cannot see it, we see only encrypted blobs in cloud storage. QR code and camera pairing with secret key as wordlist are what you see and do, to use Brave Sync (user testing soon).

Say you are shopping for a new camera during lunch, but on most days go back to work after lunch. The agent knows this and does not bug you too soon. But later, after work, when you are idle, an OS notification floats a brief call to action ad (like a search ad, a few lines of text and minimal image branding). This self dismisses but you can find it in Brave. If you click the View button, Brave is focused if not already and a new tab opens with a full landing page ad or offer.

You can thumbs-down on the ad if it didn’t work. You can close the tab whenever you like. You are not identified to the ad’s brand or any other party by opening tab — Brave shields are still up. But if you like the ad, you can act on it. You get 70% of the gross, which can be large for lead-gen ads such as making a test drive appointment with a car dealer.

Publisher ads work similarly and can even place just based on page context, not on any local user data. We always give the ad space owner 70%. We always pay the user >= what we make.

If you just form an impression, view a video by quartiles, even click on a download button for an app, or open further pages, you are not identified. Chaum blind certificates attest to your ad actions but without any user identifier. We already use the ANONIZE protocol for anonymous contributions to your top sites and YouTube accounts.

In no case do you identify to any party, including us, as a tracked user — unless you choose to, in a clear page in tab aka first party setting.