Deal with dangerous web features

[fmarier]

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

Related: https://github.com/brave/brave-browser/issues/15032 https://github.com/brave/brave-browser/issues/24404 https://github.com/brave/brave-browser/issues/31605

[EternityForest]

Doesn't it say somewhere in the promo materials that Brave believes in giving control back to users?

If users don't read privacy info and just click through, they probably don't care that much and are only using Brave for ad blocking and opportunistic privacy, to stop the low hanging fruit trackers. If something I need to access is blocked, I'm just going to use a browser that doesn't block it.

For permissions that can actually DO something besides violate privacy ephemerally, like filesystem access, a full page warning seems more than sufficient.

If they click through that on some random shady site, than their system is probably already compromised by yayhou_bazoobuddi_toolbar.virus.txt.exe which they happily installed a month ago.

I think there's no need to hide things in flags or even make them ephemeral really. Users should be able to choose for themselves.

[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.

[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.

[goodov]

Recently we've implemented a change [1] that allows brave://flags to re-enable Chromium features we forcibly disable/enable by default. We might want to revisit the current issue and add flags for some frequently requested features.

1. https://github.com/brave/brave-browser/issues/18829

[kjcole]

I'm showing the brave://flags that I turned on as being Enabled but they still don't appear do do anything:

I'm in my living room, trying to pair an open source Bangle.js 2 watch over Bluetooth LE, in order to perform firmware updates, and do app development.

However, after following the Bangle.js 2 instructions and enabling #enable-experimental-web-platform-features and #enable-web-bluetooth-new-permissions-backend, Brave fails to find the watch, despite reporting that the two are, indeed, enabled.

[proffalken]

@kjcole FWIW, this is being discussed at length over at https://github.com/brave/brave-browser/issues/13902

Basically the current state is that the toggles still exist but the code has been permanently disabled on the backend, so it doesn't matter what the UI says, the features are unavailable.

This results in a really poor user experience.

Whilst I'd love to see these features enabled as they mean I currently have to switch browser for all kinds of IoT products that require webSerial, it almost feels like if the functionality has been disabled in the back end then the toggles should be removed completely from the front end to avoid hours of debugging a problem that has nothing to do with the website I'm visiting or the device I'm trying to programme, but is entirely due to the way the Brave developers chose to remove trust from their users.

[mmiscool]

I would strongly advocate for at a minimum making the webusb and webserial functionality something that could be enabled. I can understand having it turned off by default but leaving the option open to enable would be great.

[fmarier]

WebUSB is already enabled (see https://github.com/brave/brave-browser/issues/4669), and I just filed https://github.com/brave/brave-browser/issues/24404 for WebSerial.

[proffalken]

Good luck with this.

I've gone back to Chromium as a result of the attitude towards my request for similar in the past from some in this community.

If webSerial does get enabled then I'll be back to Brave like a shot, but I have too many development setups these days that rely on WebSerial to continue using Brave as my primary browser.

This is not a decision I've taken lightly, and I'm all too aware of the phrase "this isn't an airport, you don't need to announce your departure", but in the current state and given the prevailing attitudes I don't feel I have any other option.

Hopefully, this will get merged and I'll be back in the community soon!

[Auxority]

I also use WebSerial to communicate with Arduinos from my browser. Sad to see that I cannot use Brave for this. There's not even a flag for it.

[FidgetyRat]

It's interesting that a Crypto-oriented browser disables WebBluetoothAPI in essence force-disabling bluetooth hardware wallet support...

Might want to add those suggested advanced toggles in and let your users decide their own level of safety vs. the current "nanny" state.

[heksesang]

What's the current status on this?

[mmiscool]

@heksesang Brave still won't budge on making the browser a real drop in replacement for chrome. If you want fun stuff like web serial use Microsoft edge or chrome. Who are us plebs to argue with the wisdom of the dev team.

[ktecho]

Yeah, we've been trying to use bluetooth-web for some time... At least you should put something on the experimental flag so users know that bluetooth-web is not support.

Or better: support it!

[tylermercer]

One way to improve the permission prompt option could be to make the prompt require typing something to confirm that it was read. Admittedly, that's still far from perfect, but I agree that the current state of Brave not supporting these things at all will simply push more people back to Chrome.

[konradgorni]

@tylermercer it's true what you said i have to work with chrome because i need bluetooth api in browser to connect with device.I am sad.

[UbioZur]

Same here (Web bluetooth),

To be able to use a privacy respecting watch (banglejs), I have to make the decision to use a non privacy respecting browser now! Or at least finding an alternative

At a minimum making it clear in the brave://flags that the feature is disabled, or not allowing it to be "enabled" when it is not enabled (UX things).

Or of course, disable it by default if it's considered a privacy risk, but allow the user to actually decide to take such risk!

[nicoandmee]

Yet another disturbing example of software that used to be good treating users like children who are unable to make even the most basic decisions for themselves. By all means, please shove that BAT down my throat and upsell me on various crypto products, but God forbid we enable the Web Serial API. Brave developers should be focused on empowering users to make informed security decisions for themselves.

This feels more like trying to force your particularly niche views of what constitutes acceptable security risks onto an entire user base, some of whom actually are mature adults. Last straw for me bois 👋🏾

[waldoc89]

why is this still a thing :/

[fmarier]

WebSerial is now behind a flag and we are planning to add a flag for WebBlueTooth too.

[mmiscool]

This is amazing news. Thanks!!! @fmarier