Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You might be a little biased if you think Google is trying to tamper with your USB devices.

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?



> You might be a little biased if you think Google is trying to tamper with your USB devices.

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.


It does create some interesting security implications that I hope get addressed properly. But I think you are not seeing its potential.

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.


> As someone who dabbles with Arduino

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.


I agree that some things should be hidden in "developer mode" (as it's called on Android). That might work for Arduino.

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.


It's possible that's what Google wants, but it's also a terrible idea. Browsers should be reducing their attack surface, not increasing it.

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?


I disagree that it's a terrible idea, particularly if the alternative is Wifi-enabled devices from dodgy vendors.

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.


The answer there would be desktop apps, though, not introducing a massive new hole in browser sandboxing. And it's also a dream of something unlikely to return, I think my Vive is the last product I've seen have wireless devices you plug into a desktop to update, and it's kinda a pain in the rear.


> It does create some interesting security implications that I hope get addressed properly.

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.

https://webapicontroversy.com




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: