Disable Web Serial API

[mkarolin]

Chromium 89 enables Web Serial API .

Per security team, this API should be disabled in Brave. cc: @jumde @fmarier

[mmiscool]

The implementation of the web serial API requires user interaction to enable and select the serial device. What are the security concerns about this API?

[fmarier]

In a nutshell, we share the concerns expressed by Mozilla and Apple.

[stylesuxx]

@fmarier Mozilla says:

Exposing that sort of capability to the web without adequate safeguards presents a significant threat to those devices.

and as @mmiscool states, it requires user interaction to allow access to serial devices, so I am not entirely sure what would be considered an "adequate safeguard"...

Anyway, the Web Serial API is not working with Brave as of now (Version 1.21.77 Chromium: 89.0.4389.90 (Official Build) (64-bit)
). I am not sure if this issues has been addressed by now, or if it is a bug. If it has been addressed, I would also recommend to remove the relevant settings.

I am running a PWA which uses the Web Serial API and am posting here since one of my users reported it not to work with Brave Browser, although all his permissions are set up correctly.

[drewgates]

Would love to see a compromise found allowing this to be implemented in the future.

[flywire]

It's reasonable to disable Web Serial API by default but user should be able to enable it rather than forcing users to Chrome or Edge.

[pjv]

Another happy Brave user here that would like to have a toggle to flip on support for the web serial API.

[mmiscool]

I would definitely have to say that the "Brave" folks seem to toooo scared to enable this feature. That's not very brave is it?

[nebbles]

I too have run into this issue expecting Brave (as based on Chromium) to support features working there. I've been reading a lot of the discussion here and particularly in Mozilla's threads as to why they chose not to support it. I understand their concerns, however I still think its possible to ship these features with enough sanity-check roadblocks for the average/low-technical users. I really hope that Brave considers a path to allow users to access it, even if it's in a very explicit way (see my post below):

My suggestion posted in #15637

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.

[RubenKelevra]

Actually, we could just use "disabled" by default instead of asking for the site settings. This way it would get denied, except if the user is going into the site settings below the HTTPS 🔒.

I feel that's a pretty good failsafe. :)

[ShivanKaul]

Looks like this was fixed in brave/brave-core@7e0dbdf, closing

[pattyland]

@ShivanKaul I'm not sure I understand your comment correctly. Will this feature be user-activatable on demand in the future like #18979?

More and more projects use web flasher like https://esphome.github.io/esp-web-tools/ and I find it really annoying to switch browsers every time. Deactivating things by default is good and helpful, but depriving the user of any possibility to activate it I think is a bad decision.

[ShivanKaul]

@pattyland we still have some work to do to figure out which APIs we should set as "disabled but enable-able by user". This is tricky because it increases implementation and maintenance burden on us (for e.g. if Chromium changes implementation) and we really want to make sure that we're not allowing privacy abuses even if the website convinces the user to enable the API (in the general case).

[JamesB7]

Discovered today that Brave disables this.
"You have to select the serial device to connect to" sounds like the user wants to enable it.
If it's really a concern, you could make the permission go away when the user closes the tab, or require extra permission and warnings for persistence.

[ocdtrekkie]

Very glad to see not all Chromium browsers are just rolling over and implementing Google's security holes. Another vote of confidence for Brave here for siding with Apple and Mozilla against an increasingly belligerent foe.

[stylesuxx]

Very glad to see not all Chromium browsers are just rolling over and implementing Google's security holes.

A functionality that explicitly asks the user for a permission for a specific device on a specific website. Stripping this functionality at best shows that Brave does not trust their users to make informed decisions on their own.

I understand that there is risk involved in sharing your serial device with a website, one could for example add another screen educating the user what he is about to do. It's really a shame that this functionality is not more wide spread, there are a couple of great projects that use this feature in a very responsible manner - in fact, I don't know of any that are exploiting this feature.

Also, if it would at least be consistent: How is webusb allowed and webserial not - it makes no sense to me.

This topic just triggers me so hard since I wasted countless hours explaining to users that although Brave is a Chromium based browser and yes, the Serial settings ARE THERE, no - you can't use this on Brave.

[ocdtrekkie]

@stylesuxx So, the issue that Google engineers don't understand, which is why they ship so much malware, is that people click on everything.

Stripping this functionality at best shows that Brave does not trust their users to make informed decisions on their own.

The problem here is your very incorrect belief that Brave users making decisions are necessarily "informed". Most web users, are, in fact, completely uninformed about the risks they take, and "adding another screen educating the user" also fails to recognize that people don't read stuff either. (I assume you read every EULA line-by-line too?)

How is webusb allowed and webserial not - it makes no sense to me.

I agree, and I'll happily support your request to have WebUSB removed from Brave, because that's an excellent idea.

there are a couple of great projects that use this feature in a very responsible manner

And here's the crux of why enabling such functionality is such an incredibly stupid idea: There's "a couple projects" that use it legitimately. One of the things Google engineers again woefully fail to comprehend is cost/benefit analysis. The huge attack surface of allowing websites to attack USB and serial device hardware, because it enables a couple cool projects is one of the most amazingly irresponsible actions ever undertaken in software engineering.

When you dump a feature like this into a browser, you have to acknowledge that yes, some engineers who like to tinker with crud are going to be delighted and build some little toy app they use once that uses the feature. However, you also have to acknowledge that the bad actors are going to find a way to use the feature to exploit 86-year-old seniors who use AOL.com for email and pay for Norton Antivirus. And those people are just going to click stuff, because that's what they do. And then when you add that Brave targets the crypto crowd, you've now potentially widened the attack surface to steal people's digital money.

These are egregiously irresponsible features to enable. You could still include them but disable them by default and bury the flags to turn them on so deep you'd need a tunnel-boring machine to find them, sure. That's okay, and if browsers want to do that, fine. But then what's the point of shipping all this additional code complexity into the web platform for a handful of Arduino users?

This is an area it is absolutely fine to hand off to native applications or third party software plugins, and plenty of enterprise software with web-based interfaces exist that are well-versed in handling hardware interaction for web-based applications. It's way too niche to justify the security risk and the platform complexity to include it, and Google should be ashamed their proprietary extensions of the web have gotten this far, but we all know that Google has no shame at this point.

I'm sure the guys who came up with, promoted, and launched WebUSB and WebSerial each got nice promo packets because of it.

[JamesB7]

WebUSB requires that the device has a WebUSB endpoint. That is to say, the device is /designed/ to be used with WebUSB. I am designing such devices myself right now, and combined with Mono WASM, I have so far been able to port a .NET native application onto the web. WebUSB is very useful.

As far as WebSerial, most people don't have anything on a serial port. Those that do are going to know what they're doing. You could make the same argument to disallow downloading files altogether, disallow uploading, disallow anything and everything. I'm sure you think you are better than all the people you want to inconvenience.

At any rate, for either of these, you have to specifically click your (supported) device. It's not something you can just click through. The guys who came up with WebUSB, WebSerial, etc. aren't likely getting bribes as you are suggesting. They're meeting real needs of real developers and real end users.

[ocdtrekkie]

aren't likely getting bribes as you are suggesting

I definitely did not suggest (or intend to suggest) "bribes", but it's well known Google engineers' promotional process is heavily driven by shipping new features or products, as opposed to improving existing ones. Which is to say, shipping bad web specs is extremely good for their careers, even if it's a net negative for the Internet, and even Google itself. (This particular perverse incentive is why Google has shipped over a dozen messaging apps in like the last five years... making a messaging app is straightforward and you're launching a Google product, and you don't really care what happens to it after you get your promotion anyways.)

I have so far been able to port a .NET native application onto the web.

How many users do you expect to use this application? And to be clear, you ported a .NET native application to Chrome, not the web. WebUSB doesn't become "the web" just because Google says it is.

[JamesB7]

It's not a bad spec. It's a very useful spec for embedded hardware.

I expect some thousands to use it. It's a great feature add for our product, and will help our customers. It means a mobile version independent of app stores entirely. It's not ported to Chrome -- WebUSB works on Brave right now as well. The only thing missing will be Safari. "The web" isn't what the W3C says it is, never was and never will be, and I don't care to engage in pedantry because I have actual work to do. I am grateful for WebUSB support, and hope the Brave team will be sensible about WebSerial as well.

[ocdtrekkie]

Nothing about it was a mistake. Every principled browser developer has passed on this one. Here's Mozilla's position: HARMFUL. https://mozilla.github.io/standards-positions/#webserial

It's time to look at your own biases, and accept that just because you personally want it, doesn't mean it's the right thing for the web.

[mmiscool]

@ocdtrekkie The statement that "Every principled browser developer has passed on this one" is completely incorrect and implies a nefarious motive to those who support the inclusion of this API. Not only does it presume to apply a level of virtue to opposing implementation but also calls in to question the ethics and principals of those who do not share your extremest views about what APIs to include. One might say you are biased about what can be considered for inclusion in the browser technology stack.

[ocdtrekkie]

@mmiscool Can you cite a single example of a browser doing more than a git pull from Chromium, having an actual discussion about this API, and deciding to include it?

This antifeature is solely written by Google, and is considered harmful by the developers of the two other major browser engines, and Brave has also declined to include it for security reasons.

[mmiscool]

By "actual discussion" do you mean something other than digging in the heels and crying about how much of a security risk a conscious user has to do to enable such an API. It seems there has been no discussion about allowing the API to work at all. Only discussion about how scary serial devices are. It is also clear to me that installing exclusively the brave browser is not possible and you must fall back to one of the major browsers like Microsoft edge or chrome to get any real work done.

[Edit] Also remind me again but is webUSB supported?

[mmiscool]

@mmiscool So you don't have one. Cool.

Is webUSB supported and why is webserial more scary?

[ocdtrekkie]

Mozilla and Apple both consider Web USB equally harmful. Brave looks like it did as well, but a search suggests they may have added some limited support back for hardware crypto wallets? Having a hard time finding any actual statement they were adding it back. Maybe if they pivot away from crypto at some point that'll go back away too?

[bugs181]

Whatever your stance on the security implications, it comes down to personal choice. I as a user, need this feature due to reasons already listed (ESPHome). This is the ONLY reason I have Google Chrome installed besides Brave.

As for ESPhome, there are no simple-to-use UI alternatives. I create a "new" device in esphome (which lives on a NAS server), plug my device into a remote computer, click flash over browser and it's done. I now have a Home Automation device within MY control, rather than using a "cloud connected" device, doing who knows what on my network AND privacy. Yes, there are other "programming" tools, primarily CLI like esphome.py flasher. I as a user, do not want to use the CLI. It's a major hurdle to onboarding others into the locally hosted home automation ecosystem.

So, as we stated there is a NEED for this feature whatever your other opinions may hold. Put this feature behind a checkbox flag in settings if you're worried about the Brave userbase attack surface. It simply won't be enabled for people who don't know what they're doing.

Also stated, the attack surface isn't very large as others have also mentioned. Multiple steps need to be taken before anything even happens. You NEED to have a serial device, you NEED to select the device, you NEED to accept your selection. Adding a feature flag adds a FOURTH safety parameter. That's plenty.

[ocdtrekkie]

@bugs181 I think the problem there is ESPhome. They should not be building on Google-proprietary protocols. It's well within technical capabilities to build a cross-platform application which uses HTML/JS as the UI front end, that doesn't run in Chrome-only scenarios.

[bugs181]

So your solution is that the Web SHOULDN'T be a standard and ESPHome should instead build a cross platform applications which then users must install? Why even program for the Web to begin with? Why not just dump Brave browser and use only mobile apps for EVERYTHING? Strawman argument there bud, sorry.

Your answer: New features that enable quality of life don't belong in the browser. So much for HTML5 video, etc. Flash was an app that you used to have to install. Hmm.

Edit: Also, this is out of your control now. Your opinion isn't valid about WHETHER Brave should have this feature. The W3C group, ya know... the standards people that make the web go around already has a working draft for Web Serial API. If Brave doesn't comply with a way to use this (even behind a security flag), then they're not standards compliant.

Source: https://wicg.github.io/serial/

What I'm failing to understand, is why you're so dang opposed to giving users the FREEDOM to choose to use this "technology". Sure, good.. I'm glad you don't have a need for this. SEVERAL audiences do however have a need for this. We're not going out of OUR way to tell YOU that YOU don't need something. The decision to add this feature as a flag does NOT affect YOUR life in ANY way.

Having this feature means it's ONE less piece of software to install on computers. I can think of a few scenarios where your argument about "just install software" falls apart. Think of the educational sector where the students receive Chrome books and they're NOT allowed to install anything. Web serial would come to the rescue and students could achieve programming microcontrollers and other devices, right from their browser. Your solution is, "welp, shouldn't use a Google product". They're not the ones who decide what money get's alloted and where. So due to this, the students are the ones that must suffer the decisions of others? Doesn't that ideology COMPLETED detract about what the Web is? OPEN FOR THE WORLD TO USE.

[ocdtrekkie]

@bugs You'll note at your link "It is not a W3C Standard nor is it on the W3C Standards Track." It has not been implemented by anyone but Google, and remains solely a proprietary API which every other major browser developer, like Mozilla and Apple, have defined as "harmful". The fact that Google does it doesn't make it a standard, they do not own the web.

where the students receive Chrome books

FWIW, these are almost certainly illegal in almost every jurisdiction, so... probably not a long-lived problem.

[bugs181]

@mmiscool Can you cite a single example of a browser doing more than a git pull from Chromium, having an actual discussion about this API, and deciding to include it?
This antifeature is solely written by Google, and is considered harmful by the developers of the two other major browser engines, and Brave has also declined to include it for security reasons.

That's exactly what's happening. Don't see any problem, issue should be closed. Wasn't even about that, the issue.

Because Browsers have NEVER gotten anything wrong. Should we look at the history of how Javascript was executed thus a need for a standards committee there too? I fail to see the security implications of ASKING a user to connect to a device. Since when is ASKING for permission ever been a bad thing?

[arch-user-france1]

Whatever your stance on the security implications, it comes down to personal choice. I as a user, need this feature due to reasons already listed (ESPHome). This is the ONLY reason I have Google Chrome installed besides Brave.

As for ESPhome, there are no simple-to-use UI alternatives. I create a "new" device in esphome (which lives on a NAS server), plug my device into a remote computer, click flash over browser and it's done. I now have a Home Automation device within MY control, rather than using a "cloud connected" device, doing who knows what on my network AND privacy. Yes, there are other "programming" tools, primarily CLI like esphome.py flasher. I as a user, do not want to use the CLI. It's a major hurdle to onboarding others into the locally hosted home automation ecosystem.

So, as we stated there is a NEED for this feature whatever your other opinions may hold. Put this feature behind a checkbox flag in settings if you're worried about the Brave userbase attack surface. It simply won't be enabled for people who don't know what they're doing.

Also stated, the attack surface isn't very large as others have also mentioned. Multiple steps need to be taken before anything even happens. You NEED to have a serial device, you NEED to select the device, you NEED to accept your selection. Adding a feature flag adds a FOURTH safety parameter. That's plenty.

Brave doesn't allow enabling it in the flags. A proper warning could have done it, I agree. But I don't understand why one creates a GitHub issue for making pressure only and ranting about the devs.

[arch-user-france1]

I found a nice list, a summary of which browsers support it (only Google-Browsers).

[bsclifton]

Thanks for the comments folks - I did some cleanup here of some off-topic conversations. I'm going to lock this issue

Let's please create a new issue if we'd like to make a suggestion. I personally think having a flag or way to enable would be nice (and keeping off by default). Or asking first time it's used. But other folks would need to weigh in. Let's have that discussion in a new feature request issue. Thanks!

[fmarier]

Update on this issue: we are planning to re-enable this API: #38791