Which security features would be missing in Brave compared to Trivalent?
Disabled JIT and CFI? Plus some other patches from Vanadium.
Type-based CFI is standard on Chromium browsers on desktop.
That’s something you can do any Chromium browser via start flags. Or use the V8 toggle to disable only two of three tiers.
Which of them are significant compared to what Brave has?
Not sure if if is completely accurate but here are some items:
Brave includes built-in ad-blocking and tracker-blocking features, which are enabled by default.
Brave also removes tracking-related query parameters from URLs.
Brave reduces the amount of information present in the referrer header, which can tell sites you might not trust about your browsing behavior.
Brave’s privacy protections are integrated into the browser and include features like partitioning, which improves upon the limited network-state partitioning in Chromium.
Brave’s sync feature encrypts data at the client level, ensuring that your data is hidden from the browser and much more secure.
There is a last one that is a bit polemic Brave has committed to maintaining Manifest V2 support.
Not sure what of those things were incorporated in the Trivalent browser.
Edit: adding some items that I missed:
Brave also includes built-in Shields that protect against malicious scripts, trackers, and intrusive ads, providing advanced protection.
Brave also integrates IPFS, a decentralized network for accessing and sharing content, and offers private browsing with Tor to enhance anonymity.
Brave encrypts every connection possible and includes On-by-default Global Privacy Control to stop websites from selling and sharing data.
Most of them if not all of them? Brave isn’t a security oriented browser. It doesn’t do much hardening I’m aware of, and actively de-hardens the browser in some aspects.
Never heard this, do you have an example?
Would you mind telling me a few significant ones which Brave or a default Chromium build does not have on desktop?
In which aspects?
Since the default builds for Linux and Android are different for Chromium did you check which of Vanadium’s patches are already included on desktop by default?
- 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.
- 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. Even without zypak, this replacement is required for any flatpak chromium browser to ship, and it’s a major security degradation. Even if you don’t use the flatpak, this alone makes it evident that brave will make decisions that ignore security considerations.
- As of the end of last year, Brave still defaulted to the X11 ozone backend, which Chrome et al don’t. I have no idea why they chose this and hopefully they’ve fixed it by now.
- Brave adds additional services to enable their crypto wallets. However you feel about crypto, this is a significant attack surface increase
- 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: Subresource Filter
This is just ways security is reduced relative to upstream, and doesn’t cover hardening they’re missing.
a default Chromium build does not have on desktop?
All of them
Our build would fail if any of these were present upstream, since the patch won’t apply if the target content mismatches.
Since the default builds for Linux and Android are different for Chromium did you check which of Vanadium’s patches are already included on desktop by default?
We only included vanadium patches that are desktop relevant. Like I said above, every patch in that repo is necessarily not applied upstream.
Brave includes only some of this that I’m aware of, like some partitioning improvements.
The only thing in this list that’s a security feature is the partitioning. And adding back “permissions anarchy” aka MV2 is a security anti-feature.
edit: “Brave encrypts every connection possible” is also a security feature (aka kHttpsOnlyModeEnabled
)
Sorry, not a native speaker, maybe I didn’t express myself as I intended to: Emphasis was on significant .
Reason being, I would only consider switching away from Brave in case of rather significant improvements, because I like the convenience of Brave’s excellent content blocker, cross-platform sync, its many privacy features and overall consider it secure enough with disabled JIT for most of my use cases.
Is this really a problem since it is written in Rust?
Emphasis was on significant
.
It would be quicker to list the ones that are insignificant…
https://github.com/secureblue/Trivalent/blob/ffdc92ee42e54403788d1855f9ac57927ee24572/patches/add-feature-to-disable-pdf-javascript.patch
https://github.com/secureblue/Trivalent/blob/ffdc92ee42e54403788d1855f9ac57927ee24572/patches/build-hardening.patch
https://github.com/secureblue/Trivalent/blob/ffdc92ee42e54403788d1855f9ac57927ee24572/patches/default-disable-3d-apis.patch
https://github.com/secureblue/Trivalent/blob/ffdc92ee42e54403788d1855f9ac57927ee24572/patches/disable-gssapi-to-enable-network-service-sandbox.patch
https://github.com/secureblue/Trivalent/blob/ffdc92ee42e54403788d1855f9ac57927ee24572/patches/enable-audio-service-sandbox.patch
https://github.com/secureblue/Trivalent/blob/ffdc92ee42e54403788d1855f9ac57927ee24572/patches/enable-network-service-sandbox.patch
https://github.com/secureblue/Trivalent/blob/ffdc92ee42e54403788d1855f9ac57927ee24572/patches/linux-gpu-sandbox.patch
https://github.com/secureblue/Trivalent/blob/ffdc92ee42e54403788d1855f9ac57927ee24572/patches/revert-upstream-Revert-clearing-javascript-JIT-site-settings.patch
https://github.com/secureblue/Trivalent/blob/ffdc92ee42e54403788d1855f9ac57927ee24572/patches/revert-130-optimizer-jit-change.patch
https://github.com/secureblue/Trivalent/blob/ffdc92ee42e54403788d1855f9ac57927ee24572/vanadium_patches/0008-switch-to-fstack-protector-strong.patch
https://github.com/secureblue/Trivalent/blob/ffdc92ee42e54403788d1855f9ac57927ee24572/vanadium_patches/0009-enable-fwrapv-in-Clang-for-non-UBSan-builds.patch
etc…
Is this really a problem since it is written in Rust?
Yes, Rust isn’t a panacea.
Brave only allow installation of specific MV2 extensions AFAIK.
Good to know, that’s slightly less bad
The only patches I don’t know how to enable in Brave (if possible) are those related to blocking dynamic code generation
Edit: + compiling options, unless you use Gentoo
Adding to the list
I believe this only applies to the 4 extensions whitelisted at brave://settings/extensions/v2
I think it is very unfortunate that Google decided to bundle unnecessary and monopolistic policies alongside the few legitimate security improvements MV3 provides, but this is a direct result of Google’s monopoly status in the browser engine development field that people in privacy spaces have indeed been complaining about for many years.
Browsers (currently!) “get a pass” not for no reason, but because no engine developer has (yet!) released a way for MV3 extensions to provide the same privacy-protections that only MV2 extensions can provide at the moment.
Mozilla has already committed to implementing these privacy-related features in MV3 with Firefox, and I expect when their work is done and extension developers follow suit, then Brave can implement these changes in their browser as well. Until then, it is not really Brave’s fault that Google rushed an intentionally incomplete API because it suited their business needs. The fault here lies entirely upstream.
Google decided to bundle unnecessary and monopolistic policies alongside the few legitimate security improvements MV3 provides
Which specific policies are you referring to? Also, MV3 provides major security improvements.
to provide the same privacy-protections that only MV2 extensions can provide at the moment.
No amount of “privacy protections” is worth the attack surface introduced by enabling MV2 extensions.
intentionally incomplete API because it suited their business needs.
Do you have evidence that this is the case or is this speculation?
MV3 doesn’t affect anyone’s ability to block youtube ads for example, since UBO-lite does so well. If Google’s intent was to weaponize MV3 to prevent their ads from being blocked, they did a pretty poor job of it. But as far as I know, there isn’t any evidence out there that this was actually their intent. Only unfounded conjecture.
There are two facts about MV3 I do know:
- It is possible for the features needed by uBO to be securely incorporated into MV3.
- Google did not do this.
Why exactly this happened, no, I can not know for sure, but I use the duck test in situations like this.
MV3 retaining the Web Request API and only removing the content blocking aspect of it is the most clear evidence of MV3 targeting content blockers. Keeping the Web Request API totally undermines the stated purpose of introducing declarative net requests, because other extensions are still free to do all sorts of malicious things.
From a practical perspective the drawbacks of these missing features in MV3 are well known: Frequently asked questions (FAQ) · uBlockOrigin/uBOL-home Wiki · GitHub
Anyways, like I said, I do look forward to the legitimate security benefits of MV3 eventually being made available to extensions like uBlock Origin. I’m sure it’ll happen someday
If anything this just looks like google being apathetic towards content blockers. I prefer not to skip to further conclusions on the matter, especially since it’s still very easy to block google’s ads with MV3 like I mentioned.
On top of that, there are other MV3 improvements, like the prohibition on remote code.
MV3 eventually being made available to extensions like uBlock Origin.
UBO-lite works well