For example, File System Access API was also part of WICG and similarly deemed by commenters as Chrome-only API because it implemented it first, but is now at least partially implemented in Safari 15.2. Who knows what we'll see adopted next? As long as there's a Web spec and apps using an API, browser vendors can prioritise.
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.
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.
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.
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.
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.
That's a really terrible argument, tbh.
Ah yes. As we all know, Chrome is very well known for how well it listens to users. Remember the alert fiasco? And many other fiascos?
Or remember "standards" like WebHID which are so bad that Mozilla engineers couldn't even understand them, but you still shipped them?
Or other "standards" which have multiple issues pointed out and still shipped by default in Chrome?
Please don't insult our intelligence by pretending that you, or Chrome team care at all about users or standards.
> This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
At the dame time both Firefox and Safari consider this feature harmful and will not implement it.
Just because you rammed it through standards bodies doesn't make it standard, or good.
And, unfortunately, you've co-opted web.dev to be a full-on Chrome propaganda machine.
Additionally, the status of this "finalized spec" is, quote, "Draft Community Group Report". It's nowhere near to being a) finalized and b) standardized.
The "finalized spec" literally has this in its description: "It is not a W3C Standard nor is it on the W3C Standards Track."
> For example, File System Access API
1. Is anyone talking about this API here? No. Only you, trying to pull conversation away from WebUSB
2. Filesystem API suffers from the same thing: it's a "standard", and now your team is busy pushing three more file standards
