Adam Caudill

Security Leader, Researcher, Developer, Writer, & Photographer

30 Days of Brave

Brave is a web browser available for multiple platforms that aims to provide additional security and privacy features – plus a novel monetization scheme for publishers. I gave it 30 days to see if it was worth using. I switched on all platforms I use to give it a fair shot, I normally use Chrome which made the switch less painful, though the results were very much mixed. There are some things I honestly liked about it, some things I really disliked, and at least one thing that just made me mad.

The Good #

There are some truly good things about Brave, here are a few that are important to me.

Brave is built on the Blink engine, the same engine that powers Chromium & Chrome – this gives Brave some of the better security properties of Chrome, and Brave actually uses the Chrome user-agent to pretend to be Chrome. This means that Brave has similar performance and rendering quality to the other Blink browsers, which gives it an edge over Firefox and keeps it on par with Chrome.

The use of Blink is a key to making the switch reasonable, there are no issues with sites breaking, as is so common when switching from one browser to another.

HTTPS Everywhere #

Brave integrates HTTPS Everywhere to force connections to use TLS when possible, this is great, though the same can be achieved by using the HTTPS Everywhere plugin. During my time using Brave, it reports having performed over 15,000 TLS upgrades – just on my personal laptop.

Ad Blocking & Payments #

Brave takes an interesting view of ads, it includes ad blocking, but also includes Brave Payments (disabled by default), which allows you to give something to the sites you visit most often. I put $5 into it, and let it run for a month – it tracks how much time you spend on each site, and splits up the money between them.

Of all the sites that Brave lists in my top sites, only two are setup to actually receive the payments – this site (which I setup during the testing process), and Archive.org. There are a number of sites that are included that really make little sense – for example, sites like RSA.com, PizzaHut.com, TeeSpring.com, Namecheap.com, Oracle.com, and Eventbrite.com all made the list to be paid. These aren’t content sites, but they all got a share of the money. You can selectively disable certain sites from being included, but that requires watching the list, and making sure that it’s maintained. You don’t have the opportunity to confirm who gets paid before the payment takes place, so make sure you check the list often.

When a payment is made, the money (Bitcoin actually), is transferred to accounts that Brave Software controls, and when (if) a site receives $100 in payments, one of two things happens:

  • If the site has already been setup for payments, the money is transferred to the site’s Bitcoin wallet.
  • If the site isn’t setup, they will attempt to contact them to set up the site so they can receive their money, if they don’t after a period of time, the money is distributed to other sites that are properly setup.

It’s an interesting setup, and somewhat cool to be honest – though does leave a decent amount of money in the control of Brave Software. Will this site ever get $100 in revenue from Brave users? I’m not holding my breath. That means that the money will stay in the control of Brave Software essentially forever.

The ad blocking itself works well, roughly the same you would get from uBlock Origin.

Performance #

It’s hard to quantify just how much time is actually saved by using Brave; it’s not just general performance, but the integrated ad blocking that saves bandwidth and processing time. It claims to have saved me 18 minutes on my laptop and 5 minutes on my iPhone.

It does feel a bit faster, but the placebo effect may explain it.

The Bad #

There are some things about Brave that just didn’t live up to my expectations, some of these are from a lack of polish – things that will likely be fixed as time goes on, others were more fundamental.

Private Browsing #

Like pretty much every major browser today, Brave offers a private browsing feature, but it’s implemented in a way that I find troubling. Typically when you using Private Browsing, a new window is created, and everything in that window is held to a private scope. In Brave, a tab is private – so you mix the scopes, and can easily cross that boundary. When you right-click a link in a private tab, you can open the link in a new private tab, or in a new normal tab. This makes it extremely easy to cross the line, and expose activity that was meant to be isolated.

For me, I often use this feature to separate session scopes, logging into the same site in a normal window, and a different account (or no account) in a private window. This design makes it trivial to take an action under the wrong account. I think they were trying to make things easier, but what they did was make it easy to make mistakes.

Memory Leaks #

Brave is leaky, like Titanic kind of leaky. I once left a Twitter tab open over a weekend, when I came back on Monday Brave had consumed every available byte of RAM. So much so, that even killing the process turned out to be impossible and I had to perform a hard reboot. Chrome is known for its high RAM usage, though Brave has pushed it too far.

PDF Handling #

Built-in PDF handling is essentially a must these days, and Brave tries here – but ultimately fails. The integrated PDF viewer works well in most cases, unless the PDF is behind a login. In these cases, it fails and requires that the feature be disabled to be able to download them. As changing this setting requires restarting the application, so I eventually just left it off.

Rough Edges #

Brave is a perfect setup for a death by a thousand cuts, from oddness with tab management, painful auto-complete in the search / address bar, the inability to search for anything with a period as Brave treats it as a URL, and many others. Much of this will improve as Brave matures, though for now the rough edges are a constant annoyance that make me want to switch back to Chrome. Some I’ve learned to work around, others are still painful every time I run into them.

The Mad #

Brave recently published a highly misleading article that painted a very negative view of the standard QUIC protocol, trying to accuse Google of using QUIC as a way to circumvent ad blocking. The article was built on, at best, a significant misunderstanding on the part of Brave. The article was later updated, though the update was entirely insufficient to set the record straight, leaving users with a misunderstanding of the technology, and how it applies to Chrome and other browsers.

Whether purely from a lack of understanding, or something else, the issue was poorly handled – they attacked a competitor (one which makes their product possible) without understanding the details they were talking about, mislead users of Chrome and Brave, and failed to accurately update their article to undo their misstatements. There are some people at Brave Software that I greatly respect, so this was shocking for me, and I lost a great deal of respect for the organization as a result.

Overall #

Brave is an interesting experiment in how a browser can address privacy concerns, and provide an avenue for monetization; I hope that others in the market look at it and learn from what they do right. The application for iOS feels a lot more polished than the desktop version, and while I’m going to switch back to Chrome as my primary browser, I may keep the iOS version handy.

Adam Caudill

Related Posts

  • IETF Action on Secure Email

    Early last week I emailed a group of IETF Area Directors, for the Security and Applications areas, asking them to start the process of creating a new Working Group to address the issues around email security. (Thanks Adrian Farrel for the prodding!) Today, the first result of the effort has been completed – the new endymail mailing list. An IETF venue to discuss how these issues can be addressed, hopefully laying the groundwork updated standards to improve email as we know it today, and eventually standardizing a replacement to SMTP and related protocols.

  • The Sinking Ship of E-Mail Security

    E-Mail, the venerable old standard for internet text messages, dating back to the early 1980s – and back to the early 1970s in other forms, has long been the “killer app” of the internet. While so many companies try to make the next great thing that’ll capture users around the world – none of these compare to the success of e-mail. It is likely the single most entrenched application-layer protocol used today.

  • Security By Buzzword – Why I don’t support Ensafer

    Update: I had a call with Ensafer’s CTO, Trygve Hardersen to discuss the issues I brought up, and what they can do about it. First, they updated the site so that downloads are now over HTTPS. He stated that the infrastructure that powers their service is separate from the website, and everything is over HTTPS. They are working on making documentation available, and hope to have the first documents available soon.

  • HTTP Considered Harmful – The Need For Negative Feedback

    We all know, and well understand what this means when we see it in a browser: It means that the connection is encrypted, and that some degree of validation has occurred to verify that the server is who it claims to be. Through the years, users have been taught to trust sites when they see that, or the all too familiar ’lock’ icon – when users see it, they assume their data is safe.

  • On Opportunistic Encryption

    Opportunistic encryption has become quite a hot topic recently, and blew up in a big way thanks to an Internet Draft that was published on February 14th for what amounts to sanctioned man-in-the-middle. Privacy advocates were quickly up in arms – but it’s not that simple (see here). As pointed out by Brad Hill, this isn’t about HTTPS traffic, but HTTP traffic using unauthenticated TLS; thanks to poor wording in the document, it’s easy to miss that fact if you just skim it.