Comment by chrismorgan | Hacker News Reader

Comment by chrismorgan | Hacker News Reader

Parent Full thread

WebUSB is not finalised in any way. It’s a WICG draft (draft means not finalised, and WICG means explicitly unofficial), with only one shipping implementation in browsers. (There’s also an implementation for Node.js, but I think that’s considered irrelevant.) My recollection of the rough processes is that to become a Candidate Recommendation (which is the first stage you could reasonably argue “finalised spec” corresponds to) it would need at least a second shipping implementation, and to be adopted by a working group.

As it stands, there’s no short-term prospect of a second implementation: Mozilla’s current position is that WebUSB is harmful because it’s super dangerous and the risks can’t be adequately explained, and is a tracking hazard <https://mozilla.github.io/standards-positions/#webusb>, and WebKit have likewise consciously decided not to implement WebUSB for similar reasons (“due to fingerprinting, security, and other concerns, and where we do not yet see a path to resolving those concerns”) <https://webkit.org/tracking-prevention/#anti-fingerprinting>.

That multiple browsers use the same engine and implementation is irrelevant for standardisation—otherwise Chromium would be the very definition of the standards. To show this even more clearly, WebSQL was scuttled because everyone used SQLite and there was no satisfactory way of specifying what would be permitted.

Speaking frankly here: as the post author and a “WebAssembly Advocadoer @Google”, you’re speaking from a position where authority will be assumed, but in this comment you expressed some very significant errors and presented a badly biased view. This is not good.

Thank you for clarification. As an ill-informed reader, by reading the parent comment I was under the impression that it was already a standard.

Considering the hazards, the last thing I want is random js in random website start messing with my operating system file system and USB connected devices.

It sounds like you're talking about the W3C standards track (correct me if I'm wrong, just guessing from the context) whereas I'm talking about the spec itself as the document and the API. Those are two different things after all.

All browser engines have been following living specs even for core stuff like HTML/CSS instead of the W3C "officially finalised" standards for a while now, so I didn't bring the latter up as they weren't relevant to the conversation about the spec itself or its stability.

However, I admit that I missed myself and should've called out that the spec, while stable, is still a draft - that's a mistake on my part.

The spec is not on the standards track at this time, but is in a place where that is the explicit goal (the I in WICG stands for incubation). Combined, these facts emphatically mean that it’s not finalised. The whole purpose of these standardisation processes is to get multiple parties working on something in order to produce a better result than any one party would achieve. I have two clear examples in mind, both from IETF rather than W3C, but the principle transfers: Google presented QUIC and Fastmail JMAP to IETF as complete, functional protocols matching what they had been using themselves, but there were some pretty radical changes based on other people’s feedback before each was declared stable.

How much more in this case, given Mozilla and Apple’s positions on it! It’s extremely likely that if it does get taken onto the standards track it will only be with breaking changes.

WebUSB is not finalised and is not stable, even if it hasn’t changed recently—because the only reason it hasn’t changed is because no one but Chromium is willing to touch it because it’s such a run-away-screaming scary idea for security. That it is metastable (that’s a more suitable word) in its current state is an indictment against it, not a good thing.

The WHATWG Living Standards are a completely different kettle of fish—it’s not a case of even for core stuff, it’s a case of that being a model that makes sense for the well-established core stuff where changes affect many places, given implementation practice (and indeed that’s why browser makers forked HTML, because the W3C development model wasn’t working for them); but the Living Standard approach doesn’t make sense for new stuff and well-isolated functionality, like most CSS and JavaScript APIs.

Slightly tangential, but I still find it fascinating that it was Firefox OS was the first to introduce the idea of adding all sorts of hardware APIs accessible from JavaScript, or at least that was the first time I heard of that idea and played with it (and still have a ZTE phone from the time), but, after the Firefox OS was discontinued, they essentially stopped being interested in those capabilities altogether and started to even actively discourage others from exploring it.

I guess it makes sense from business perspective, but I still believe in the original idea of making more powerful apps with Web technologies, even though the companies that work on those ideas changed over time.

Yeah, I’m sad that Firefox OS died.

Firefox OS needed those sorts of things for its “apps” since it had no lower-level “native”, and I think that they were only exposing features like that to trusted code (meaning apps you deliberately installed) rather than general web content, until they could be sure it was reasonable.

I think they also designed the OS with a better peripheral security model than Windows/Linux/macOS, nullifying or mitigating one of the two critical problems of WebUSB (that the computer trusts peripherals too much, so that one that’s hijacked can more easily become a remote code execution vulnerability).

(I write all this as one who kept a fairly close eye on Firefox OS, but has never run it.)

> and I think that they were only exposing features like that to trusted code (meaning apps you deliberately installed) rather than general web content

I'd actually be pretty happy if browsers chose to implement those APIs with the same restriction in mind - that is, only for explicitly installed PWAs. I said this elsewhere in the past, and I still think that's a reasonable restriction that could provide a path forward.

> or mitigating one of the two critical problems of WebUSB (that the computer trusts peripherals too much, so that one that’s hijacked can more easily become a remote code execution vulnerability)

I'm not very well-versed in the details, but I believe that's also the reason why WebUSB (or Chromium implementation of WebUSB?) doesn't allow certain classes of devices to be ever accessed via that API.

Limiting it to installed apps still has the problem of users blindly agreeing to something that is fundamentally super dangerous. I don’t believe installing PWAs currently exposes any new security surface, so this would be a significant change, and worse still a persistent hazard with probably no indication of what’s going on when it’s in use. I think there’s still potential in the general concept, but it’d take work and is certainly not ready yet in any browser.

Yes, certain classes are restricted from access via WebUSB for security, https://wicg.github.io/webusb/#protected-interface-classes. But as the note says, it’s about balance: that list is necessary for security, but not sufficient.

> Limiting it to installed apps still has the problem of users blindly agreeing to something that is fundamentally super dangerous.

Same can be said about native apps. Like with other hazards, in the end it's all about balance - you can't stop users from _ever_ doing stupid things.

> because it’s such a run-away-screaming scary idea for security

I think that's the root of our disagreement. Few years ago I've been of the same mind about giving the web new powerful features, but after watching the space and seeing the existing alternatives I've come to change my mind.

As mentioned in another thread below (https://news.ycombinator.com/item?id=30013287), vendors who need this sort of functionality, already find ways to implement it via other proprietary methods like local executables that, unlike implementations of Web APIs, are not reviewed by other teams and usually expose all sorts of critical stuff over local HTTP servers or in another insecure fashion.

In the end, it's not a question of "if" we want to expose those features to the web apps, it's "how" we can do so with minimal risks to the users, and that's where web APIs with thought-out permission models, explicit requests and history of cross-origin checks can help.

Of course, you can also say that vendors can continue to implement those things insecurely anyway even when new APIs exist, but 1) in practice when they're given a simpler way to do the same thing, they tend to go for that more often instead of inventing custom hacks and 2) that's where advocacy of the new APIs comes in, and what I'm trying to do by showing what the web can be if we let it.

As for your other arguments about potential for breaking changes if/when those APIs get adopted by other browsers, I agree I might be overoptimistic and your prediction might very well turn out to be true. Those APIs map to basic USB concepts quite closely, so I can't imagine what changes would be necessary, but, of course, I don't have enough experience with WebUSB outside this project to say that it's 100% impossible :)

In the end, it's a bit of a chicken-and-egg problem - in order for browsers to see the interest or get feedback, there have to be apps trying to build something with those APIs and reporting bugs / feature requests, and for those apps to use those APIs, there has to be at least one implementation first. This problem can be chewed from either end, and I'm trying to do my part by showing developers how those APIs can be used for porting interesting apps and libraries.

My main disagreement with you is not based on the soundness or otherwise of WebUSB functionally, but your position on it as a specification. Still, I’ll address the matter of WebUSB itself.

WebUSB is so scary for security because neither USB devices nor desktop operating systems have been written with such a use case in mind. There are two key problems in WebUSB: ⓐ USB devices weren’t designed with public exposure in mind, so that they’re commonly insecure and brickable or hijackable if you get access to them; and ⓑ operating systems weren’t designed with malicious USB devices in mind. Combine these, and you’ve got potential total sandbox escape and remote code execution, guarded only by a flimsy permissions popup that doesn’t explain what can happen—can’t explain what can happen. The threat here is probably the most severe (using the definition in the severity/probability model of risk assessment) ever contemplated for the web.

Yes, there are legitimate uses of such an API. Yes, this makes life much easier and even safer for such uses. But if the concept doesn’t also give you the heeby-jeebies, you haven’t thought the implications through enough, haven’t seen how bad programmers are at their jobs, and haven’t observed how hopelessly ineffective permissions popups are at protecting users. I watched the video in your article and was horrified that it’s not even trying to protect you or indicate that this is anything other than routine: you just get a “‹origin› wants to connect” popup with a list of routinely-cryptic device names (“ILCE-6600” rather than “Sony α6600”) that you can choose from. Yet this is a thing that, with the wrong USB device and a malicious attacker that knows about a vulnerability in it, could literally set fire to your computer, steal all your passwords, or silently install malware on the USB device or computer.

For myself, I might prefer to have WebUSB, because I trust my judgement in what I execute and because it’s more likely to support my platform. But for the population at large, on the balance of things, no, I agree with Mozilla’s position that it’s harmful, and would regretfully condemn people to continue downloading and executing untrusted code from the manufacturer, because that’s more likely to be done deliberately and only for first-party code.

WebUSB is problematic because there’s probably no safe subset of its functionality: it seems to be fundamentally dangerous. People have tried proposing a few subsets, from memory (I’ve occasionally paid a little attention to it), but so far they’ve all been rejected as either not safe enough or too crippling; and so Chromium has declined to be crippled and implemented the wildly unsafe with only mild mitigations to limit the class of devices exposed, and Gecko and WebKit have declined to play it dangerously. It’s similar to the question of exposing raw TCP, which was contemplated, but ended up being deemed too dangerous, and so it was wrapped up in HTTP as WebSockets: something not quite as useful, but safe. It’s possible someone could come up with something like that for WebUSB, something that constrains it to something safe. Such a constraint could easily require major API changes. That WebUSB currently matches the fundamental USB concepts closely is no saving grace in the stability of the protocol.

> It’s possible someone could come up with something like that for WebUSB, something that constrains it to something safe.

That sounds like WebSerial and WebHID to me, which don't require similar shenanigans with Zadig on Windows or Linux permission changes, because they allow access to a limited subset of USB device functions.

But that will never cover all the use-cases for USB apps. For those the only choices are not to do anything at all and let closed native executables to continue dominate this space (which gives them unlimited access without even those simplest permission prompts), or to work on WebUSB and encourage devs who do need to interact with such devices over USB to switch to that instead. I don't see 3rd option or how it would be possible in our non-ideal world, and among those two WebUSB still seems like a better idea.

> However, I admit that I missed myself and should've called out that the spec, while stable, is still a draft - that's a mistake on my part.

As is never mentioning the fact that WebUSB is considered harmful by both Safari and Firefox, and hiding it behind "oh, I do hope other browsers will implement it". They won't, you are perfectly aware of it, and the reasons why they won't.

I think I already made it clear in another thread why I'm not going to interact with your comments in particular. There's no need to try and post variations of the same comment throughout the tree.

At the same time, I'm perfectly happy to respond to questions and concerns of other people like the one above who can express their thoughts without resorting to personal attacks.

> I'm perfectly happy to respond to questions and concerns of other people

What a wonderful word, "respond". Not answer. Respond. That's exactly what you're doing: responding

HN: This is not "finalised"

Respond: oh yes, it is finalised. Because browsers [sic! plural] conform to the living standard

HN: It's not implemented or supported by browsers (plural).

Respond: Oh, it doesn't matter, all that matters is that Chrome implemented it

(Aside: for something to be considered standard and finalised there should be at least two independent implementations. See history of why WebSQL on top of Sqlite never happened)

HN: Others view this standard as harmful

Respond: why are you attacking me personally

> who can express their thoughts without resorting to personal attacks.

To me you are just another in a long list of Chrome's talking heads who all behave absolutely identically (and their behaviour is very well documented across various internet platforms): ignore, deflect, gaslight. What you see is simply a reaction to this. To your credit you haven't stooped down to gaslighting.

Want to see a different approach? Change your (as in Chrome team's) behaviour. That is, however, unlikely: Chrome stands nothing to lose by ignoring any and all concerns about its behaviour.

Reply on news.ycombinator.com