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!
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
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.
> "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 ;)