5 ms·

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

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.

dmitriid 5y ago
> 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.
- RReverser 5y ago
  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.
  - dmitriid 5y ago
    > 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.
chrismorgan 5y ago
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.
- RReverser 5y ago
  > 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 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.

dmitriid 5y ago

> 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.

RReverser 5y ago
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.
- dmitriid 5y ago
  > 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.

chrismorgan 5y ago

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.

RReverser 5y ago
> 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 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.