Deal with dangerous web features

We routinely disable web-accessible features in Chromium which we consider to be dangerous (e.g. WebUSB, Web Serial, file system, WebBluetooth), however this often leads to web compatibility issues and sometimes we end up re-enabling these features later (e.g. WebUSB).

Despite other browsers refusing to implement such features, the fact that Chromium ships it increasingly means that sites and users start to rely on it and expect it to be part of every web browser.

Some ideas for how to deal with this:

• put each feature under a new flag in brave://flags:
  • pros:
    • hard for users to enable it accidentally
  • cons:
    • not discoverable, which means we’ll continue to get issues/support requests, and less technical users have no way to find out that it’s supported in Brave
    • increases user awareness of brave://flags, which is full of flags that will break user’s browsers
• change the permission prompt to better highlight the risks (like the stern warning we show for non-whitelisted browser extensions)
  • pros:
    • maximum discoverability and web compatibility
  • cons:
    • users who don’t read prompts will just click through
• make these permissions ephemeral only
  • pros:
    • limit the damage that can be done with repeated use of these features
  • cons:
    • doesn’t do anything to protect against attack that require only a single access

Chrome’s policy for these kinds of features: https://source.chromium.org/chromium/chromium/src/+/main:docs/security/permissions-for-powerful-web-platform-features.md

[urbenlegend]

I just ran into this issue while trying to use the new VS Code for Web: https://vscode.dev/ I was sad that there wasn’t a way to enable Filesystem API support in Brave, even though its using Chromium.

I 💯 agree with what @nebbles said. The web is increasingly becoming the application platform of choice and users demand more and more functionality out of it. Holding back platform improvements without providing a discoverable way to re-enable these improvements is only going to push more users back to Chrome instead of improving privacy on the web.

Hiding things behind brave://flags is a bad idea. When a feature is outright disabled, most sites will just say “Your browser doesn’t support this feature. Please try Edge or Chrome.” Having users see this warning should be avoided as much as possible.

I am okay with having stronger alert dialogs when sites attempt to use these “dangerous” features. It’s still discoverable and its a great opportunity to educate users on the dangers of certain web capabilities.

[nebbles]

FWIW it would be great if Brave could restore some choice to the user. I personally use Brave because of its focus on reducing arbitrary tracking but whilst retaining close compatibility with Chrome by being based on Chromium. I respect the concern the team may have for features implemented in Chromium, but still believe this choice should be put in a users hands. My use case has been for the Web Serial API.

I’d suggest a mixture of suggestions above.

1. Instead of using brave://flags however, which is some really low-level/technical/raw functionality, adding an option (possibly even a section) to the standard Brave settings for advanced features achieves a bit of the pro whist minimising the con of suggestion 1.
2. In addition, strengthening the permission prompt with a stern warning, whilst also informing the user that they still need to go to the settings to initially turn on this feature on.
3. And finally, what I think would be a real Brave-esque move, allow users to enable this feature on a per-site basis, which further tightens up the risk exposure.