jonathansampson

Brave engineer here.

> "Monopoly money for watching ads"

What does Firefox pay you for piping your keystrokes off to Google? BAT is a reward for your attention; far better arrangement and exchange than what has existed up to this point. It's not perfect, but what's your solution?

> "injected affiliate links"

You seem to be a little free and loose with _facts_. Rather than exchange your data for revenue, Brave explores revenue streams which won't keep us up at night. One such consideration was affiliate links. We had a couple (quite literally a couple/few), that would appear when you typed certain crypto-related keywords into the address bar. When suggestions were offered, so too would be our affiliate option.

This solution presented a means by which users could support Brave without involving their data. Unfortunately, a UI/UX bug caused the affiliate option to appear even for a fully-qualified domain, which meant a user who quickly typed a URL for which we offered an affiliate link and mashed Enter, could unintentionally have selected the affiliate option. That isn't _injection_.

The issue was identified pretty quickly, and a patch was sent out. Guess how much Brave made from the buggy behavior before it was patched? I'll help you: $0.

You can read more at https://brave.com/blog/referral-codes-in-suggested-sites/, though I must warn you ahead of time that it isn't as exciting or shocking as you might have liked.

You know what would be SHOCKING though? Imagine if Mozilla had tried to do something quite similar. Oh, wait… https://www.malwarebytes.com/blog/news/2021/10/firefox-revea....

> "installed their commercial VPN without asking"

This one is actually somewhat true. We did indeed ship an inert service for some Windows users. The goal was to have the VPN option be immediately available to users who wished to purchase it, as a means of supporting Brave. Details are in the GitHub issue: https://github.com/brave/brave-browser/issues/33726.

> "and leaked DNS traffic when using Tor in its 'privacy' mode."

Oh, this is one of my favorites. It's a classic story with depth, misdirection, unexpected side-effects of decisions made years in between, and more! This one is the type of thing I would have expected to read about in _Joel on Software_ many years ago.

So, we shipped a browser with a "privacy" mode, much like everybody else. But, we weren't fans of the common approach used by Chrome, Firefox, Edge, and others. Their approach doesn't really make you _incognito_, or _private_; it just creates an ephemeral account locally and basically does some file-system cleanup. We wanted something stronger!

As fans of the Tor project, we opted to bake-in support for Tor as an optional enhancement to private tabs. This would give you one extra, super-thick layer of incognito-ness. Tor Private Tabs were shipped back in mid 2018, and the next couple of years were pretty awesome. Brave users who enabled optional Tor support enjoyed a superior experience to that found in other popular browsers.

Years later—as the tracker wars waged on—some data-harvesters got the idea that they could evade detection by way of CNAMEs, giving them first-party privileges. So in late 2020, Brave shipped CNAME decloaking, unmasking more trackers than Mystery Inc., and dramatically expanding the privacy moat.

But the story wouldn't be all that exciting if it didn't have a twist, right!? Brave's new CNAME-decloaking didn't consider the Tor scenario, and performed DNS lookups outside of an existing proxy!

While the combination of these features didn't make Brave as porous as ordinary "incognito mode", it did punch an embarrassing hole in the Tor boundary: page traffic still went through Tor, but CNAME adblocking DNS lookups accidentally went out through the user's normal DNS path.

For that narrow slice of activity, Brave drifted uncomfortably close to what Mozilla calls "private browsing": https://support.mozilla.org/en-US/kb/common-myths-about-priv... ("Private browsing [in Firefox] doesn't hide your activity from your ISP, mask your IP address or location, or stop websites from identifying or tracking you…)

> "I'd say Mozilla dodged a bullet there."

Let's check in again in another 5 years ;)

Not quite. We had a couple domains that—when typed into the address bar—would offer a referral-option in the browser UI. If you quickly hit the enter key, you might mistakenly have selected one of those unintentionally. This was a UX bug on our end as the feature wasn't intended to match complete URLs.

The goal was to offer folks a means of supporting the development of a privacy-preserving browser, at no cost to them. We blogged about the feature at https://brave.com/blog/referral-codes-in-suggested-sites/, and ultimately disabled it by default. But there was never any "hijacking of links," or "swapping of affiliate codes".

The truth is less exciting, I know.

There's a lot of confusion around the "brave-reward holding garbage."

To be brief, Brave issued grants to users, which those same users could then direct to their favorite content creators. So, the grants _started with Brave_, and initially _remained with Brave_ until they were claimed by the designated content creator. If the content creator never claimed the grant, it could be recycled back into the pool, and re-issued to another Brave user in the future.

The _grossness_ of this "controversy" is in the fiction surrounding it, and not in the details itself. Some falsely claimed Brave solicited donations on behalf of content creators—that was never the case. _Falsehood flies, and the truth comes limping after it._

In fact, Brave was the first browser to block nasty crypto-jacking/mining scripts (e.g., CoinHive) when they began to appear on the scene, nearly a decade ago.

Sampson here, from Developer Relations at Brave. Would you mind telling me a bit more about how you have Brave configured, so that I can make sure local testing and troubleshooting on my end reflects your scenario accurately? Any input would be greatly appreciated.

You are presumably using the "Clear on Exit" feature, located within settings at brave://settings/clearBrowserData. When you select the "On Exit" tab of that view, which options do you have selected? Do you find that none of the data types are cleared when you close the browser (via › Exit), or only some of them are cleared?

I'm also curious about the state of two options within brave://settings/system, namely "Close window when closing last tab," and "Warn me before closing window with multiple tabs". Are both of these enabled?

Thank you in advance

<transparency>I'm an engineer at Brave.</transparency>

Not quite. Not unless by "stupid stuff" you mean shipped-and-fixed a couple bugs here and there (including confusing UI/UX), etc.

Brave operates in such a way that even an occasional misstep on our part puts us on equal footing with other popular browsers, but never worse.

Our "can't be evil" approach to data/privacy/security has yielded pretty stellar results over the years, and will continue to do so in the future.

Brave published a blog post regarding this feature/news; you can read more (as well as see images of the feature in action) at https://brave.com/referral-codes-in-suggested-sites/. I hope this helps!

Hello! I am Sampson, from Brave.

Brave is an advertising company, but we’re quite different from Google and others in this space. Brave's ad notifications are opt-in and engineered in such a way to protect and preserve user privacy. I'm not sure where you saw Brave engineers talking about ways to prevent users from blocking our ads—we don’t try to prevent users from blocking Brave Ads.

If you wish not to see Brave’s ad notifications, you can easily avoid them (by not opting-in in the first place, or by throttling/disabling-entirely). There are no special hoops to hop through, or technical incantations to utter. We believe digital advertising is better when it is built on user-first principles and consent.

If a user opts-in to Brave’s ad notifications, their device proceeds to routinely download-and-maintain a regional catalog of available inventory. The user's device then evaluates the catalog entries for relevance. User data is NOT sent off-device in Brave’s model. If a relevant ad entry is found, it is then displayed to the user in such a time and manner for minimal distraction. When an ad notification is shown, the user receives 70% of the associated ad revenue for their attention (no clicks required).

Again, if the user wishes to not see ad notifications, they can simply choose not to opt-in to viewing them. If the user wishes to not see the occasional sponsored image on the New Tab Page, they can turn those off from the New Tab Page itself with 2 clicks ( Customize › Show Sponsored Images). Importantly, the user is always in control. They decide whether ads will be displayed, and to what degree (e.g., the user can set a limit on ad notifications per hour).

Brave isn't interested in coercing users to view advertisements.

I'm Sampson, from the Brave team. The Web Discovery Project is a clever approach. For Brave to compete with Google, and offer a truly novel index of the Web, a novel approach must be taken. The WDP is an opt-in, privacy-preserving approach which gives Brave a fighting chance against the Search incumbants. Due to our preference of "Can't be evil" over "Don't be evil," the WDP is not only designed with privacy and anonymity as a prerequisite, but it is also open-source for public scrutiny and evaluation: https://github.com/brave/web-discovery-project.

That was my bad :(

I forgot the "w-full" class on the Shields image. I set the "max-w-md" class alone, which sounds like it's supposed to prevent the image from being wider than the viewport itself, but that isn't the case.

Apologies.

You can always check the internal task manager to see which tabs/extensions/child-processes are using the most resources. To do so, visit › More Tools › Task Manager in the browser, or press Shift+Esc.

In Brave, you can select the Bookmarks panel from the side bar, and then toggle it open/closed from then on with Ctrl+B.

Regarding iOS, it's entirely possible there's a bug in our code. I'll definitely take a closer look and speak with the team regarding this report. That said, it's also not entirely uncommon for users to enter a site through a slightly different URL, or form, which complicates the credential-autofill logic. If you have an example or two of sites where this behavior is consistently observed, that would be much appreciated.

That's quite misleading; please see my response to a previous comment regarding the initial "payments" UI/UX: https://news.ycombinator.com/item?id=32755143.

There's some considerable context missing here. When Brave held its token sale in 2017, we allocated 300M tokens to the User Growth Pool. Shortly thereafter we began staking Brave users with tokens to identify creators for whom they would like to offer support. Brave's UI showed a check-mark for verified creators, and nothing for unverified creators (we naively followed the Twitter model).

Some users took the BAT grant they received from Brave, and attempted to tip it to unverified creators (which landed those tokens in an omnibus settlement wallet where it could later be claimed, similar to the PayPal model of sending money).

The UI/UX of this feature and process caused a great deal of confusion towards the end of 2018, leading to monumental feedback from several content creators, including Tom Scott of YouTube. Tom's insights gave us the direction we needed to overhaul the Rewards (called 'Payments' at the time) system in major ways.

Ultimately, Tom approved of the changes. But note, there was clearly no scam involved. Additional details are provided in our 2018 blog post at https://brave.com/rewards-update/. I hope this helps!

The United States Postal Service handles mail for the United States. Them having my name and address is quite a bit different than Google having the same data (in addition to the mountains of other data-types Google tends to harvest).

Switching back to Firefox means your keystrokes are literally handed off to Google in real-time. Please take some time to review the privacy practices of your preferred browser: https://www.scss.tcd.ie/Doug.Leith/pubs/browser_privacy.pdf

If any data is being collected and stored on servers, it would first need to be transferred off the installed client (the instance of Brave running on the user's device). Network analysis would capture this (as it does with Google, Bing, Firefox, and other browsers). But you don't see this with Brave, because it does not take place. Again, please consider the review of a reputable source: https://www.scss.tcd.ie/Doug.Leith/pubs/browser_privacy.pdf

Data-harvesting would be quite difficult to hide given our source code is open to the public (i.e. https://code.brave.com and https://github.com/brave), and that we encourage web-proxy evaluation of network activity (a la https://brave.com/popular-browsers-first-run/). In fact, reputable researchers in the privacy space have reviewed Brave, finding it to be the "most private" browser, in a class of its own: https://www.scss.tcd.ie/Doug.Leith/pubs/browser_privacy.pdf. But does not collect user data--we don't want your data.

You've mischaracterized features of Brave. Our code is open-source, it's not difficult to literally "go to the source," (https://code.brave.com and https://github.com/brave) and test the claims of others. You claim that Brave profits off of user data--show me where that is the case. Brave does not collect any user data; we were found to be the "most private" popular browser by reputable researchers in this regard: https://www.scss.tcd.ie/Doug.Leith/pubs/browser_privacy.pdf

Brave has never been "caught" collecting user data, or abusing user data. Not a single instance of this exists. We believe in "Can't be evil" over "Don't be evil," which means we aim to preclude the potential for abuse at the design stage of ever major effort tied to Brave, and our services/offerings. On the other end, the harvesting and leaking of user data is [standard] in all other major browsers.

This was not an example of data-sharing; the data in question (names and addresses) resides with the United States Postal Service. That data is never accessed or viewed by Brave.

You're absolutely right; no-addresses is the ideal, and what we would have preferred over no-names from the beginning. We have a call this week to investigate further why addresses were included in the first place, and why our request to exclude any personalization was not respected.

The names and addresses are with the USPS. Brave (hello, I'm a team engineer) used the EDDM offering of the United States Postal Service. We were attracted to this method of advertising in part because it never exposes sensitive information to us at Brave. User data, instead, is with the USPS, which has legitimate claim over such information. As stated in our blog post, we sent only the artwork (for the mailer itself), and the Zip Codes we aimed to reach. That's it. We also asked that names NOT be printed, which was the case for earlier batches (e.g. https://twitter.com/TravelTechGuy/status/1513965348177219588). I hope this helps!

Brave never has access to your information. We didn't use "a service that collects data about people," we used the EDDM offering of the United States Postal Service, which has legitimate claim to names and addresses. This service is attractive in part because it exposes no data to Brave in the process.

No privacy impact. Brave doesn't have any names or addresses; those are with the United States Postal Service (never exposed to Brave). We asked that names NOT be printed on these mailers. Previous batches went out without names, as intended. You can see an example of this from a Tweet last month: https://twitter.com/TravelTechGuy/status/1513965348177219588.

We did communicate our desire to exclude names from mailers; you can see an example from last month at https://twitter.com/TravelTechGuy/status/1513965348177219588. Because we wish not to be exposed to any user data, our QA process ends prior to the stage where names would be printed. Once we learned names had been printed on a recent batch (a deviation from previous batches), we took prompt action to "halt and catch fire," so to speak.

Brave doesn't harvest or collect any user data; we explicitly requested that no names be printed on these mailers (which was the case prior to this recent batch). You're mistaken about the other issues as well (they are every bit as overblown and misrepresented as this present issue).

"Stealing money from creators" is quite misleading. When Brave held its token sale in 2017, we allocated 300M tokens to the User Growth Pool. Shortly thereafter we began staking Brave users with tokens to identify creators for whom they would like to offer support. Brave's UI showed a check-mark for verified creators, and nothing for unverified creators (we naively followed the Twitter model).

Some users took the BAT they received from Brave, and attempted to tip it to unverified creators (which landed those tokens in an omnibus settlement wallet). The UI/UX caused a great deal of confusion towards the end of 2018, leading to monumental feedback from several content creators, including Tom Scott of YouTube. Tom's insights gave us the direction we needed to overhaul the Rewards (called 'Payments' at the time) system in major ways. Ultimately, Tom approved of the changes. But note, no money was ever stolen from any creator. Additional details are provided in our 2018 blog post at https://brave.com/rewards-update/.

It was also never the case that Brave was "redirecting legitimate links to shady crypto sites," either. You're referring to our Partner and Affiliate Links in Suggested Sites. That is, if you typed "bitcoin" into the address bar, prior to any network activity, Brave could list (among other options) an affiliate link to binance.us. The user could then decide to visit the bitcoin-related property using Brave's affiliate link, or disregard the suggestion entirely. This feature is off by default in Brave today, but you can read more about it on our blog at https://brave.com/referral-codes-in-suggested-sites/.

Not at all. EDDM doesn't impact user privacy. Brave never sees any user data during this process.

It's EDDM, and previous mailers lacked printed names. Our request to exclude printed names, while honored in the past, was not honored with a recent batch. Rather than brushing this off, we chose instead to investigate where the break-down in communication occurred, and share our findings in the blog post. Thankfully, this issue has no impact on user-data, privacy, or security. But it is definitely frustrating for us when we expect names to NOT be printed, only to learn that a batch of mailers contained them after all.

Brave doesn't ask you to trust it with more and more data; we explicitly do not want any of your data. This issue did not impact user data or privacy in any way either.

Brave didn't do the printing; that is (and has been since 2020) handled by the EDDM vendor. Brave doesn't want any user data; we prefer that information to stay with the United States Postal Service, which has legitimate claim over such information.

I work at Brave. We don't get addresses; we don't want that type of data (we don't want any of your data). The addresses are printed after Brave's QA process has completed. We asked that names NOT be printed on the mailers, but have no way to verify that they were excluded, since that would expose sensitive user data to us (which we do not want). We didn't work with any data broker; we simply provided mailers and desired zip codes (for 7 cities) via the EDDM service.