Hacker Newsnew | past | comments | ask | show | jobs | submit | jonathansampson's commentslogin

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!


oh now i get it, thanks :)


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.


For now. Remote attestation will devalue non-attested advertising. Once your stream of revenue dries up due to devaluation, that's when the executives will have a choice to make.


Does Brave support this proposal?


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.


It's not a clever approach, it's basically scraping Google results because that's where your users are searching. You follow the bread crumbs from Google searches.

Cliqz entire history was based on this kind of thing, milking off other search engines by just deducting their ranking methods, it's parasitic. There's no cleverness about it.


I don't know a lot about this particular approach but your comment that it's just using Google results is blatantly false. It all depends on the search engine that the brave user is leveraging, or no search engine if they type in the URL directly into the header.


Nonsense. This naive idea that Brave innocuously looks at user's traffic patterns.

Google owns 95% of the market in most Western markets. There's no "blatantly false" about that.

They scrape search engine results and present them as their own.

Do 10,000 searches on Google and Brave and you'll see how similar they are. It's as simple as that, scraping by sleight of hand.

Why can't they be a normal search engine - because they need to scrape others. Simples.


I had a discussion about this on Twitter with Brendan Eich. He became hostile very quickly. He is not a very nice person.


I would expect most people today find interesting content via social media, and not search engines.


.es?


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.


Ah, tried Ctrl+B with the mini side bar already open and found it works. Thanks.

The two recent culprits that didn't toggle password autofill were eBay.co.uk and Gumtree.co.uk. I'd be grateful it if this could be investigated; the latter prevented me from checking an address in the Gumtree PMs whilst on the road delivering a purchase.

On the issue of sending multiple tabs, it is frustrating enough that it prevents me from adopting Brave as my main browser. I often open a few sites that interest me on mobile then decide to read more on my desktop. If you could pass the word along for someone to investigate that, all the better.

With that said, it's commendable being the only browser on iOS with first class advert blocking & sync with every other platform.


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!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: