Put webserial functionality behind a flag

[fmarier]

As mentioned in #15637 WebSerial was disabled (in #13902). It seems that a lot of users would like to be able to enable this in their browser in order to update the firmware of some devices.

Right now, there is an option which claims to enable this functionality (e.g. brave://settings/content/siteDetails?site=https%3A%2F%2Fgithub.com):

but it doesn't do anything because it's fully disabled.

We should provide a flag in brave://flags (default off) to allow users who need it to enable it. When that flag is off, it should remove the Ask and Ask (default) options in brave://settings/content/siteDetails, as we plan to do for all disabled features.

[7ombie]

Endusers should not be directed to copy and paste the chrome://flags URL, then change various settings (often requiring a full restart), to be able to use a webapp. These APIs need to be enabled when the browser launches, whatever other hoops the user has to jump through to actually use them.

A persistent, per-domain, opt-in would be cool, if it was workable. You could go further, and make it a catch-all permission for all of the powerful APIs (that are enabled by default in Chrome).

The dangers of enabling one powerful API are broadly the same as the enabling the others (at least from the user's perspective). Ultimately, users will either trust the site (and enable whatever it requests) or not trust it (and reject everything), in the same way that users either install an app or don't install it. Trust is generally binary in practice.

On the other hand, it may be technically difficult to implement the opt-in dialog on a per-domain basis, as it's not part of any web standard, so apps that require powerful APIs would need to implicitly trigger a permission dialog (for example, by calling navigator.usb.requestDevice). Any explicit API that's non-standard would be Brave-specific.

It also obscures which APIs are actually being used. The user would just be asked if they trust the site to do powerful stuff or not, so suspicious requirements would not need to be explicitly requested. This is mitigated by the measures that Chrome relies on, which would all still apply. For example, the user would still need to explicitly select specific peripherals to expose to specific APIs.

[7ombie]

If it was possible to reliably know when an app tried to use a power-API and failed, those specific exceptions could trigger a dialog, which could then refresh the page with all of the power-APIs enabled, assuming the user confirms.

One problem is that a lot of apps feature test, so if the API is not defined, they will not try to use it at all. However, if the APIs were defined, but just threw (dialog-triggering) exceptions as soon as you tried to use them, that would only require Brave-specific exceptions.

Brave-specific exceptions would not create any issue (in this context), if the user grants the permission during the dialog, as the page is refreshed with the APIs available. However, if the user rejects the request, then a completely unexpected, non-standard exception will be raised in otherwise perfectly valid code, unpredictably breaking apps.

However, the dialog could always refresh the page, either reloading with the APIs fully enabled (as in Chrome) or completely unavailable (as in FireFox and Safari), so apps would never get rug-pulled.

Users would only see the dialog the first time they visit the app, and there could be a little UI element in Brave to indicate whenever a page is privileged or expressly unprivileged (allowing users to change the setting).

Users who don't want these APIs enabled at all could disable them globally in the settings, and they would not get any dialogs, as the relevant APIs would always appear unimplemented (which would be the default setting for at least as long as these APIs remain Chrome-specific). There should probably be an enable-everywhere-option too, for people who want a Chrome-like experience out the box (so the global configuration would contain three options: Always Ask, Always Reject and Always Permit). Note that this assumes power-APIs are treated as a group (not enabled individually).

This approach would not work on a per-API basis generally, as apps that use multiple power-APIs would need to be refreshed multiple times (at various points), which would suck horribly. Refreshing the page once, the first time it's visited (for those users who want that extra control) seems tolerable, but that implies a catch-all permission for the power-APIs.

[true2thepen]

Deep-sixing Brave and moving to Opera. It allows the use of webserial. Since the Brave developers aren't brave enough to trust the user to make an informed decision it's good-bye to Brave. This issue is years old and the continued resistance to allow the user to make the decision shows the cowardice of Brave.

[nicoandmee]

Deep-sixing Brave and moving to Opera. It allows the use of webserial. Since the Brave developers aren't brave enough to trust the user to make an informed decision it's good-bye to Brave. This issue is years old and the continued resistance to allow the user to make the decision shows the cowardice of Brave.

I love Brave for the good parts but have to agree. It's similar to how there's no way to disable the This file can harm your computer message.

I am not five years old