The founder and head of the security focused Linux operating system secureblue, RoyalOughtness, posted some security concerns about Brave. There are several concerns, so making one topic per concern would cause spam. Still, please let me know if it is against guidelines that this one topic covers several concerns.
Here are some ways Brave could possibly address them:
Re-enabling anarchic extension permissions, aka MV2 . If Android allowed all apps all permissions, with no mechanism to set granular permissions on a per-app basis, no one in privacy spaces would be using Android. Yet for some reason, browsers get a pass when it comes to doing the same for extensions.
MV2 extensions can be very useful, but they are a security concern. I suggest making them an opt-in toggle in Brave Flags.
Shipping an official flatpak, which they accomplish using zypak, which is both no longer maintained and a hack that replaces the layer 1 component of the otherwise robust chromium sandboxing with flatpak’s much weaker sandboxing.
[/quote]
Flatpak browsers have notable security concerns, but are really convenient. If it is necessary to keep the Flatpak, I suggest adding a warning that Flatpak Brave has a weaker sandbox and is not recommended if other options are available.
Brave adds additional services to enable their crypto wallets. However you feel about crypto, this is a significant attack surface increase
This can be solved with something like Brave Lite, which is a separate discussion.
Brave’s built-in adblocker accepts arbitrary content, making it a source of significant attack surface. The method Vanadium (and Trivalent) uses to implement adblocking by preprocessing filter rules at build time mitigates this risk significantly
[/quote]
This could be solved by having a Lite mode of Brave Shields that acts like Vanadium and Trivalent’s adblocker.
Lastly, Trivalent has extra security patches including but not limited to these:
@2F6V I’m kind of curious if you and the person you’re quoting ever spent much time learning about Brave? Many of the things you are saying are misleading or entirely incorrect.
Update: As of v1.81, we host the following Manifest V2 (MV2) extensions on Brave’s backend: AdGuard, uBO, uMatrix, NoScript. These extensions operate independently from the equivalent versions that are currently present on the Chrome Web Store, and have to be downloaded separately. Users can download and enable these 4 extensions from the brave://settings/extensions/v2 page.
When Google removes MV2 extensions from Chrome Web Store, they will be disabled for Brave users as well, except for these 4 supported extensions. This is to prevent users from using out-of-date extensions which might have serious security ramifications, as mentioned in the blog.
Brave is available as a Flatpak package from Flathub. While it is maintained by Brave Software, it is not yet working as well as our native packages. In addition, it modifies Chromium sandboxing in ways which have not been vetted by the Brave or Chromium security teams. We currently recommend that users who are able to use our official package repositories do so instead of using the Flatpak.
So it’s weird that you speak like there is nothing said.
Issue 3
Not really. With them just throwing out a vague mention with no details, it’s hard to address it. Needless to say, I don’t feel like writing out a huge article about all the specifics of how this works. Instead I would much rather the people making the claim actually put some “meat” to what they are saying.
Overall it just sounds like this person was grabbing at straws. “Oh, it does something other browsers don’t, therefore it has more attack surface.” I mean there’s a vague hint of truth there in that the more features offered or API calls made can be more ports of entry, but it’s also misleading.
Issue 4:
I don’t care to click and review each link. This just seems like something unique to them. Brave has a their own code structure and is heavily increased for privacy and security. They also have bounty programs for people to try to find weaknesses so they can be fixed.
If you can give any very specific issues that you think exist and need patches, I’m sure someone from Brave would take a look and implement if it makes sense.
Issue 5
You didn’t list it, but he also complained about users being able to create their own scriptlets.
As the article they linked to mentioned, scriptlets can allow for users to modify webpages for a wide variety of privacy, security, and usability purposes.
Of course, anyone who doesn’t know how to make them and just pastes in some random scriptlet could do the reverse. This is why there are warnings given in Brave and elsewhere:
Arguing against it is like saying people shouldn’t be allowed to connect to the internet at all because there’s a risk that someone can hack your device; therefore, you should never connect any device to the internet. Would that make sense to you?
Other Issue:
Many features are opt-in. Majority of things can be disabled in settings or at brave://flags or by people using Group Policy. That said, these things are not a vulnerability to the browser nor are they any bloat in terms of eating additional resources.
That said, discussion does occur around things on a regular basis. Something like a Brave Lite is on the table for discussion. I actually made a topic on this when I found an X (Twitter) post from Brendan Eich having a discussion with someone on it. Would you pay for simplified version of Brave?
But one of the things that’s been made clear is this would be a lot of work to maintain. The team is already small enough that they haven’t been able to get everything going for the browser as they would like to be done. So deviating from the path would be more time and resources than they have. If they were to do it, they would need to look for funding to make it happen, such as charging for it.
There is a much higher demand for everything as Brave offers it, so the primary browser and everything built into it is getting the priority attention.
- Reminder-
I’m just an active user who helps here. I don’t work for Brave or anything. So make sure you keep in mind the answers given are my own.
Thanks for your throrough response! I admit the security concerns mentioned are biased, but the thread I linked was specifically asking for security differences.
For MV2, Brave has built-in features covering nearly all the usecases for those 4 extensions, so I would say enabling them with an opt-in flag would be better
I didn’t catch that, I should have done a bit more research.
Unlike the whole internet, changing scriptlets is mostly a stylistic feature that isn’t necessary for most people’s livelihoods, so it’d be more like legalizing cars without car doors. Sure, people can choose to keep their doors, it might be helpful for uncomfortable parking positions, and it’s a lower risk at slower speed, but safetywise it might overall be better if it wasn’t permitted.
Edit:
Turns out including Trivalent patches is already an issue on the Brave Github!
. If Android allowed all apps all permissions, with no mechanism to set granular permissions on a per-app basis, no one in privacy spaces would be using Android. Yet for some reason, browsers get a pass when it comes to doing the same for extensions.
