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.
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…)
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".
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?
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.
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.
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.
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!
With all due respect, that isn't how the solution works. Users must first opt-in to Brave Ads. Once they do, they download a regional catalog. This is a text document, compressed down to about 3 MB in size. Your machine (via on-board machine-learning) studies this for relevancy. When a relevant ad is found, you are given 70% of the revenue, and a notification is displayed on your operating system. You have control from the start, even over the frequency of ads you'll see within an hour.
Your beautiful drive through Colorado requires quite a bit of maintenance and financial support. Somebody has to pay for that. With Brave, Advertisers can pay for it (without getting hold of your data) by way of users. Alternatively, you may choose to "fund the roads" yourself by depositing your own tokens into Brave's wallet—that too is possible.
Brave aims to sustain the roads that grant you access to that scenery. For some users, they are able to pay a bit out of pocket (depositing their own tokens). For others, they can take advantage of a private advertising system that finds relevant ads, while paying the user 70%. This allows users to passively support the roads, if you will.
Unlike billboards down the side of the highway (which, I agree, aren't pleasant to see), only the users who wish to see ads are shown ads. And they always determine how many are shown (which is not the case with billboards). Brave Ads are tuned over time, too. As a user engages the app, the ads will become more and more relevant (unlike billboards). All that said, the default experience is (and will remain) an ad-free experience.
To your Krebs citation, he is absolutely correct. Give your data to somebody, and it's likely they'll lose it, leak it, or sell it. That's why Brave avoids your data as best we can. Brave Ads takes place _on your machine_, where your data naturally lives. You don't entrust us or anybody else with it.
We don't rely on extension and/or DOM APIs like other approaches—we're the browser. It's much harder to fool the browser. Additionally, because our models are built on client-side operations, analysis on the client can be done without the need to leak any data from the user's session. That's about as much as I'm happy to discuss. Fraud prevention is one of the few opaque areas in our project, for good reason. I hope that helps!
Ads first appear as OS notifications on your desktop. This notification displays plain-text content from the regional ad catalog. You get 70% of the ad revenue at this point.
If you click the notification, Brave opens a tab in the Brave browser and navigates to the advertisement location. At this point, the ad can load images, video, etc.
Important to note, however, that ad pages are not given any special treatment in the Brave browser. They are subject to the same privacy/security restrictions on all other pages. Third parties are severely limited, if not entirely prevented from engaging in the session.
The problem is more nuanced than "they block someone elses ads, and display their own," though. Modern digital ads (since their start in the early-mid 90s, have been about data collection. In 2009, online advertising was further adapted to include a process known as Real-Time Bidding, where users are auctioned off (usually in less than 100ms) for each ad-slot on each page they visit. The ad industry has been transforming more and more into a system of _surveillance capitalism_.
These changes to the digital advertising industry have driven mass adoption of ad and content blockers. In 2015, more than 500 million users were blocking trackers, and ads/content that relied on them. This protects user privacy and security, but hurts the sustainability of the Web we all know and love. Brave aims to deliver a fully developed solution.
Brave's model (which is predicated on user-consent, and privacy-by-default) seeks to fully-solve the aforementioned problems. We offer advertising without compromising user trust, and better value to advertisers/publishers during the process. Perhaps most importantly is that Brave Rewards brings disillusioned users who once ran ad and tracker blockers back into the fold.
The types of ads shown by early participants is skewed toward blockchain and security topics. For many users, this is not very interesting. But the inventory changes and diversifies with time. We're seeing this happen today, already. The machine-learning model within the browser will also adapt over time, getting smarter and more attuned to your interests and habits.
Quality will increase with Time and Inventory. We're seeing positive trends here, as more and more diverse advertisers are lining up to join the platform.
> "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 ;)