Literally mostly from Google employees just mad their pet project doesn't work on iOS. I, and plenty of others, appreciate the position Safari (and sometimes Firefox) holds in only supporting web APIs that provide value greater than the security and privacy risks they introduce.
Google's busy trying to invent ways for websites to tamper with your USB devices, and it hasn't even managed to deal with how much malware it distributes through it's extension store alone, much less through it's ad platform and misuse of the notifications API.
You’re also trying to put yourself in a position of speaking for other developers, which is something we should avoid. How do we know what most developers want?
That is not what I said. I said they are trying to let websites tamper with your USB devices. Aka, they introduced WebUSB, yet another mostly-useless browser feature that exposes a large attack area to the web which I need to block by policy, that was probably solely introduced so they could release https://flash.android.com/ which very few people need or use, and could just as well be a desktop app.
As someone who dabbles with Arduino I actually do want USB support. I don’t particularly like installing everything but the kitchen sink on my desktop via homebrew just to get a decent development environment going. (Last time I tried it, the Python install failed because homebrew doesn’t support the OS version I’m running. I really dislike homebrew.)
Running embedded development in a browser and just giving access to a certain USB device would be an improvement, letting you do it on any machine or even a Chromebook. It’s going to take a long time to get there but I can see it being useful someday.
And you've just picked another extreme niche, like flashing Android ROMs.
Here's the problem with things like WebUSB that Google injects into Chrome: It's going out to over a billion users, including seniors, enterprise environments, and the technologically inept. And it introduces security risks. Why would anyone launch WebUSB out to, say, my grandma, just because maybe 100,000 people in the world might use features that require websites directly talk to a USB device?
Ironically, I could tell you how Google could fix this right now, but I'm confident they won't do it because it's not Googley enough: Leave it and a dozen similarly obscure web features permanently disabled by default behind an about:config flag. Google is obsessed with making things "just work", so they enable everything, even though something like WebUSB will only ever be used by people who are doing something sophisticated enough that flipping an about:config flag is in their wheelhouse.
As an IT admin, what's really frustrating is having to edit group policy every month to disable each and every new security hole and pop-up call-to-action feature browsers introduced that month. (Google is not alone in this, Firefox is guilty too to some extent, and Edge clones all of Google's bad ideas, of course.)
And for people at home, the thing is, non-technical users approve everything. They hit that accept button on every bloody prompt they get. And I know this because I spent a lot of time cleaning out the Privacy permissions tab on people's browsers when they have problems. "Why are three porn sites able to send desktop notifications on this browser?" Who the heck knows?
Just to make it easier for you to play with an Arduino, everyone else shouldn't have to play whack-a-mole with "features" silently injected into their browser via evergreen updates.
But the audience for WebUSB might grow. Many consumer electronic devices have companion desktop apps to configure them. Wouldn't it be nice if we didn't have to write them multiple times, and you could use the same software to configure them on Linux or a Chromebook as well?
You're claiming that Google just wants this for flashing Android but how do you know? Maybe they're thinking bigger.
If I was to characterize most of my issues with the Chrome team, it'd be that they need to stay in their own lane. They've injected a botched antivirus app into their releases before, DoH basically sidesteps the OS' networking stack because it was inconvenient for them they couldn't change it, etc.
At what point can we tell the Chrome team to stop feature creeping and just try to make their web browser waste less RAM?
It would be useful to have devices that don't talk to the network at all unless I plug them in and open a particular web app.
They won't. Both Mozilla and Safari pointed out the security issues and refused to implement WebUSB (along with a host of other APIs) as specified.
Google said: we don't care, it's now enabled by default in Chrome.
Making it clear that it’s Chrome only (for now) would be good and they should do that more prominently. Making it possible for other browsers to implement by designing it with standardization in mind also seems good? (Unlike the situation with web extensions.) Lock-in is bad, Chrome-only websites are bad, so they should be trying to standardize things and avoid using it as a point of differentiation between browsers.
Not speaking for other browser vendors is also good. Like, it’s all very well for us to say that Firefox seems unlikely to pick it up, but someone on the Chrome team should definitely not say that, because it jinxes the effort and Firefox might change their minds if web developers seem to want it. (The comment you link to raises security concerns but I don’t think they claim to be giving the final word about Firefox’s position.)
So we see the state of standardization a bit hidden behind euphemisms like saying that there are “no signals” from other browsers yet.
There’s also the danger of having early articles become out of date by claiming that things are Chrome-only when actually the situation has changed and the person writing the article doesn’t know about it, so there is a tendency to avoid saying too much.
The underlying assumption is that web standards evolve by browser vendors starting to implement things ahead of getting consensus. Implementation and documentation start ahead of the standardization effort, which goes on in parallel.
(And underlying that assumption is the notion that rapid adoption of more powerful web api’s is desirable and “stagnation” is bad. Safari gets a lot of grief for being too slow, while Chrome gets grief for being too fast.)