Brave vs Trivalent Security

  • Re-enabling anarchic extension permissions, aka MV2 :slight_smile:. 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.

9 Likes