WebHID (Human Interface Device) API

[nondebug]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: WebHID
• Specification or proposal URL: https://wicg.github.io/webhid/
• Caniuse.com URL (optional): https://caniuse.com/webhid
• Bugzilla URL (optional):
• Mozillians who can provide input (optional):

Other information

This API is in Origin Trial starting from Chrome 86.

[martinthomson]

I don't see enough information in the API to understand the proposal. There is a bunch of IDL, but no normative citations to definitions for many of the fields that are exposed. There is discussion of security and privacy threats that are akin to those for WebUSB, which suggests this might share some of the same sorts of risks as WebUSB, but there isn't enough information available to make any sort of determination.

Suggesting defer until this can be documented properly.

[nondebug]

Please take another look, I've updated the specification and I believe everything is now sufficiently specified.

[dmitriid]

@nondebug

• Asked for position on Dec 1, 2020
• One month later, on Jan 4, 2021, received input: this is not even close to being even a draft for a standard
• Two months later, on March 9, 2021, enabled by default and shipped in Chrome 89, and advertised it as fait accompli on web.dev
• Two more months later: added 2669 lines of text, "hey, there's this "standard" that we enabled by default, so we won't be able to change it since people probably already depend on it, why don't you take a look at it?"

Is my timeline correct? Why does Chrome team even bother pretending they care about standards and standards processes?

[beaufortfrancois]

Here are some events to add to this timeline:

• blink-dev - Intent to implement on Sep 27, 2018
• blink-dev - Intent to experiment on Jun 10, 2020
• Safari blog post - Tracking Prevention in WebKit on Jun 24, 2020
• Firefox tweet on Jun 20, 2020
• TPAC - Devices and Sensors F2F on Oct 23, 2020
• blink-dev - Intent to ship on Dec 1, 2020

[scheib]

I'd like to address dmitriid@'s and beaufortfrancois@ comments with a personal opinion. I work on Chrome adding these capabilities. We do strive to develop in the open, solicit feedback on proposals, and draft specifications & cross browser tests. In our ideal world we would communicate and reach relevant interested people as early as possible and have constructive discussions. My personal belief is that in WebHID we understood that the web application developer need was strong and established years ago with Chrome Apps. We knew that some of the other browser vendors were not interested in cooperating on a timeframe we and application developers were motivated to execute on. The timing dmitriid@ details particularly highlights a frustrating lack of meeting good communication goals. I'd like our Chrome team to have done better there. I'd like to share that we understand and have heard you. It is also unlikely that changing those particular timeline items would have changed Mozilla's position in 2020 or 2021. We understood that from Marcos's tweet, non recorded communications, and the previous USB position etc. However, ideally we still would have had more communication earlier.

I am glad there are so many developers passionate about creating a successful web platform, and encourage as much proactive communication as possible.

For those interested in solving problems related to this, the Device and Sensors working group has been an excellent forum.

[dmitriid]

@scheib

Actions speak louder than words: https://webapicontroversy.com

We knew that some of the other browser vendors were not interested in cooperating on a timeframe

What actually happened: The only two remaining competitors have explicitly stated that these poorly thought-out and underspecified "standards" (which are nothing more than Chrome's internal APIs) pose a significant security and privacy risk. Chrome said: we don't care.

It is literally Chrome who's not interested in cooperating.

in WebHID we understood that the web application developer need was strong and established years ago with Chrome Apps.

Translation: we have a bunch of APIs that are: developed by Chrome, enabled by Chrome and that exist only in Chrome that we just enable by default regardless of consequences. Our goals:

• secure Chrome dominance [1]
• gaslight other browser vendors and misrepresent their positions

Ah yes, and do so under the guise of "developers want it" and "this is for the better of the web".

I am glad there are so many developers passionate about creating a successful web platform, and encourage as much proactive communication as possible.

Translation: we're busy fracturing the web platform by replacing it with Chrome, and we couldn't be happier doing that.

[1] This is a longer issue than can be effectively put into a GitHub comment. The gist is:

• Google as a company doesn't exist outside the web
• The only stack it owns is the web
• What better way to keep control of the stack if not by subsuming and replacing it?
• You can achieve it, partly, via platform fatigue (as Rich Harris described it): throw stuff at it until even Microsoft with their unlimited money and resources says "screw this, we cannot sustain developing our own browser anymore"
• And as Jonathan Nightingale, former VP/VP Engineering of Mozilla, said in hist thread about Google sabotaging Mozilla, "The question is not whether individual sidewalk labs people have pure motives. I know some of them, just like I know plenty on the Chrome team. They’re great people. But focus on the behaviour of the organism as a whole. At the macro level, google/alphabet is very intentional."

The pretence that Chrome "cares for the better web" should just stop.

[martinthomson]

@dmitriid that is off-topic for this repository. Please limit your comments to the merits (or otherwise) of proposals.

[chengweih001]

We have seen interest in this API from extension developers and on WICG/webhid#97 we are currently exploring the changes necessary to support it in extensions using Manifest V3, which require service workers and thus lose access to APIs that were previously available on a background page, which had access to the full Window object. Given my understanding that Mozilla intends to enable the WebMIDI API for sites blessed by an extension I am interested in a signal of whether Mozilla supports work specifically targeted towards enabling this API in extensions.