[cillian64]

If that’s the argument against, it could just be denied by default and require the user to go into settings to allow. The annoyance isn’t too bad given webserial is probably only used on occasion, and it means no concerns about consent spam or fingerprinting.

[troupo]

Why do people willingly ignore all the other APIs that require a consent dialog. And what happens when users are presented with a barrage of them.

[gregmac]

Users aren't presented with a "barrage" of consent dialogs. There's not even that many of them, and being able to access a serial port is a niche case where it does make sense -- just like accessing a web cam or microphone. It's certainly less annoying than the one for allowing push notifications.

Unless, of course, the site is malicious/spammy. It's possible to do all kinds of annoying things, from triggering consent dialogs, to opening new windows, to playing sounds.. and you can even do them in a loop. Adding (or not) a consent dialog for webserial doesn't change that.

[sfink]

> Users aren't presented with a "barrage" of consent dialogs. There's not even that many of them

And that is the result of a lot of hard work and pushing back on... well, on things like this. There are already enough that many people have been trained to click Accept without reading. Any new source of consent dialogs must be scrutinized very closely.

> being able to access a serial port is a niche case where it does make sense -- just like accessing a web cam or microphone.

If you agree to webcam access, then the site can see and record you visually. If you agree to microphone access, then the website can hear and record you aurally. If you agree to serial access, then your "TSMX9200b7 Larangipone GmbH" can... er... do something? Maybe it can turn on a blinky light. Maybe it can capture audio through an embedded IoT microphone (or speaker that shares wires with something else). Maybe it can use the debug interface on something you didn't realize had a debug interface to reprogram the device to emulate a keyboard or ethernet device and hack your system. Are you going to whitelist devices owned by big companies with lawyers and screw over experimenters? Blacklist devices so the well-behaved hackers won't hack you?

I wish we lived in a world where we could just add consent dialogs or config settings to allow things like this. Instead, we live in a world where if something like this is enabled, you'll get phishing emails with support tips for fixing your browser issues (or slowness) by going to about:config and twiddling some setting that is meaningless to the 1% of recipients who matter.

[saurik]

Those same phishing emails can just ask you to install some random non-browser software or activate any number of other insecure things. If you are trying to protect a user from going far out of their way to follow instructions they are handed by the enemy you simply can't win.

[troupo]

> If you are trying to protect a user from going far out of their way to follow instructions they are handed by the enemy you simply can't win.

With software that users install, there's at least the fact that users sort of vet the software they install, and there's a somewhat restricted set of software that is running.

However, even in a fully sandboxed environments like phones we know that users don't read the dozens of permissions that apps require. They just click yes.

However, even when there are attempts at restricting software like Windows UAC and MacOS's security warnings, we know for a fact that users don't read those warning and permission dialogs.

And this is for systems with a rather small restricted set of software.

Web sites are whatever link you click in the browser. There's not even the installation step. They just run. Including any and all advertising networks (all those 11472 partners for your privacy): https://en.wikipedia.org/wiki/Malvertising

[sfink]

> Those same phishing emails can just ask you to install some random non-browser software or activate any number of other insecure things.

Yes, because those native apps have access to a much larger attack surface. (As in, they already have all the permissions they need to do major harm.) Which is why OSes have their own scare screens when installing software, and why there's been some success in educating people that installing random shit they come across on the internet is not necessarily a great idea. (Unless you're installing the 432nd dependency of your CLI npm script. Then it's fine.)

Wouldn't it be great if we had a native app where you didn't have to worry too much about what people install, but could still run arbitrary code hosted anywhere? In the limit, you could make it so a single click—on a piece of text, say—would make it do a network request to pull down the arbitrary code and execute it, with no consent required! You'd just sandbox it so that if it needed to do anything requiring extra capabilities, it'd pop up a consent box. Of course, you'd better make sure it's not popping up too many when doing normal things, because then people would just start automatically agreeing to everything that popped up. And it's not just the number, it's also whether the consent popup describes what is being requested, why, and what harm it could cause, in a way that makes sense to nontechnical users. Which means you probably don't want to use it for things where you can't explain it well enough, since then it'll boil down to "will you allow dji@@fo&suR?JGkgslf.##!14* in order to do the thing that you want to do?"

Of course you will. If it was dangerous, then it wouldn't give me the option, right?

(For the sarcasm impaired, I am describing a web browser.)

> If you are trying to protect a user from going far out of their way to follow instructions they are handed by the enemy you simply can't win.

If we were talking hypothetically, I would agree. (And in fact, I do agree that we can't win. At least, not forever and not in all things.) But this isn't hypothetical! This stuff is happening, all the time. And when someone agrees to allow something that can do DMA to main memory and corrupt random bits of data, I have to debug that shit. Or more likely, someone has the great idea to dynamically load a shared library that does Super Secure Antivirus Stuff, which of course the user will agree to, and then I'll have to debug the crashes that result from the buggy thing crapping all over its nest in the browser's main process address space and hooking into things without delegating to any existing hooks. Hey, it worked fine six browser versions ago on the OS version from last year! If that sounds like an unlikely and rare case, then how unlikely is a random bit flip? Because we see ton of crashes from those every day. (Hint: if read-only memory that's supposed to contain code that lives on disk doesn't match what's on disk, then you can't really blame it on buggy code flipping a flag bit on the wrong address.)

</rant>

[troupo]

> Users aren't presented with a "barrage" of consent dialogs. There's not even that many of them, and being able to access a serial port is a niche case

It's amazing that you write this and then immediately find the (almost) right answer:

> Unless, of course, the site is malicious/spammy. It's possible to do all kinds of annoying things, from triggering consent dialogs...

And then immediately dismiss that as if that wasn't a valid concern:

> Adding (or not) a consent dialog for webserial doesn't change that.

Yes, yes it changes that. It increases the number of consent dialogs in a system that already has a few of those, and where users are already trained to click "yes" to thousands of annoying popups.

Oh, and these are not just empty words. Recently Mozilla relented and implemented WebMIDI. Guess what: https://x.com/denschub/status/1582730985778556931 It didn't even require a malicious/spammy site. Just regular ad networks.

[beeboobaa3]

Stop making up problems that don't exist.