Alice: Bumped a week since Sangwhan sent apologies

Skipping, Sangwhan is absen

Hadley: looked like we had question about whether communication was possible across origins

Kenneth: Also question about whether works over bluetooth classic, or only constrained to USB.

Hadley: Said we'd put it in our device enumeration issue on design principles but doesn't look like we did ... I'll do that now.

Peter: Looks like Dan set milestone to face-to-face. Maybe more to discuss then

Sangwhan: I finished a review...

[discussion on whether this applies to bluetooth...]

Sangwhan: browser doesn't care... it's an implementation detail...

Sangwhan: 2 issues - 1 is that HID devices are 2-way. You can write to a HID device. You can read from a HID device. Given that the user has said "you can use HID devices on these 2 origins running in 2 different tabs" they could communicate with each other. That breaks the [web security model]. Leak cross origin information... They are aware of one device..

Ken: you could make that not possible.

Sangwhan: block writes? that might be problematic.

Dan: couldn't the spec mandate that one context could have a connection to a single device (exclusivity)

Sangwhan: i mentioned that - also in the context of race conditions. They said it needs to be implemented carefully... They don't have a proposal to address this.

Ken: also with Native apps to and from webapps..

Sangwhan: yes you could leak between web and native. This can be a side channel... I mentioned that. they did suggest it might make sense to restrict write access to a single tab. Also: they expose serial numbers which is problematic.

Dan: maybe ping them and see what the current state is and mention these issues?

Sangwhan: OK i will do. One architectural question - unique identifiers that come from the system...

Dan: we need to put that into https://github.com/w3ctag/design-principles/issues/152

Hadley: don

Sangwhan: Sort of OK about the spec now aside from the side channel. HID can be anything. Means you could potentially write to and read from the device. SO you could use it as a cross-origin communication. Exclusive access is something I suggested. If you have 2 game tabs, switching from one to the other would involve a hand-over process.

Dan: [nonedebug comment]

Sangwhan: I'm concerned about using it to share tracking cookie identifiers across origins.

Dan: agreed.

Sangwhan: tracking companies do whatever it takes to track you across origins.

Dan: ref unsanctioned tracking

Sangwhan: something innocent like a gamepad you leave plugged into your computer could be abused like this

Sangwhan: I read the feedback. I am unconvinced that there is no way to mitigate the problem. I think we should request exclusive access.

Dan: I support. I think web APIs should not allow for unsanctioned tracking.

Sangwhan: Even making it more uncomfortable - e.g. making the user re-allow permissions - would significantly change things. If the user is asked for HID permission for e.g. Reddit then they might know something fishy is going on. Anything that makes it annoying to do this practice of cross-origin communication.

Dan: what is the argument about only allowing one origin?

Sangwhan: i think there is a valid use case but it's not a common one.

Hadley: what's the use case?

Sangwhan: one example: music controllers. E.g. drum machine - on native you can have it read by different pieces of software...

Dan: That sounds like the web midi API....In in our Security and Privacy checklist, it asks things like "does the utility of the thing outweigh the risk?" One corner case maybe doesn't happen on the web then?

Sangwhan: maybe something you have to explicitly opt in for it... There may be valid use cases... Default should be single origin exclusive access.

Ken: then you can see if people actually request this other feature...

Sangwhan: when you switch tabs and go to a new device you don't just magically get access... I will have a chat with the spec author.

Ken: I could imagine playing a game , a chat window opens, and then you lose the connection...

Sangwhan: [will take offline]

[bump this 2 weeks

Sangwhan: commenting and bumpin

Ken: This was mostly the issue that Sangwhan had...

Sangwhan: Someone brought the issue to our attention that some devices can enable tracking... some devices can even be bricked, including one very common device... allows firmware updates.

... Also the problem that these devices also have a microphone and allow you to record sounds through HID... bypass mechanism for WebRTC permissions.

... Device that is problematic DualShock game controller (3 and 4). One of the most common gaming controllers on the market.

Yves: Playstation one...

Sangwhan: Right, it's the most popular on the Playstation

Ken: Comes with the device :)

Sangwhan: Suggestion from Chrome engineer was that 3 and 4 should be added to a blocklist that they maintain. Not a standards thing, but a Chrome thing.

Ken: Wasn't the idea for HID to support these types of devices?

Sangwhan: Right, so blocking it somewhat defeats the purpose.

... Spec author suggested that Sony and Google take the mitigation discussion off-thread... a little concerned that this is being done behind closed doors.

... Would like to hear your opinions on this...

Ken: Blocking... would it block the device itself? Or some of the specific logic for exposing the MAC address?

Sangwhan: Suggestion from Chrome guys ... block it at the OS level... expose it as a gamepad. Or, blocklist the device altogether. Can blocklist the device at the browser level... if it's a raw HID device you just blocklist it altogether... otherwise you can expose it as a very primitive gamepad.

Ken: I see they have a blocklist for all these devices... shouldn't this list be shared in public?

Yves: Shared would be good for interop.

Ken: Should devices be able to opt out of being shared on the web?

... USB can have different profiles, some of it may be no exposed?

Sangwhan: ... can set an origin .... web USB ...

... removed because device vendors wouldn't do the work needed. Also there's already a lot of devices already out there.

Ken: Blocklist should be public.

Sangwhan: List should be a shared resource, not browser-specific.

Ken: And we need info about why the device was blocked.

Sangwhan: I don't like the possibility that websites can brick people's gaming controllers. That's definitely not good.

Ken: A gaming device also seems like something people are even more likely to give websites access to compared to, say, scales.

Sangwhan: I can write some feedback... last comment seemed to have been ignored.

Ken: If we do this blocklist as a github repo or other public location then device manufacturers can ask to be blocked.

... Could have a nice README explaining how to request to add your device to the blocklist. Right now if I were a device manufacturer, and I didn't want my device accessed on the web, how would I go about that? Who would I talk to?

Sangwhan: Implementer-level blocking definitely isn't going to scale. Would like to hear what they have in mind before we go making assumptions.

Sangwhan: Propose closing and see where it goes

Hadley: security and privacy issues are thes same as other peripherals, they might get something out of looking at other ones.

Sangwhan: it doesn't let you fingerprint based on number of devices because you get a device picker, you get to know only one

Sangwhan: we just need a final comment from them to close it off... Some final changes. Same goes for Serial.