Yves: this seems to be a huge chunk of work - espeiclaly aropund privacy .. didn't make that much progress yet. We need privacy / security attention.,

Dan: should we get Anssi on a call?

Yves: yes but Amy should be ...

Matthew: and Martin...

Matthew: Well written explainer...

Yves: agree...

Matthew: local collaborative document editing...

Max: I think it's already ... available in the OS... they just propose to add a new feature for web...

Yves: it relies on existing things... mdns... they have a toggle to make it discoverable or not as a way to secure that... not wide open. In the browser API... it would be on the page.

Dan: ...security & privacy .. vector for malware ...

Dan: leaves comment suggesting first week of may for an interactive session with them.

Matthew: we should have questions written down and circulated beforehand.

Max: The use cases make sense for me, and are clear. We may have some queestions regarding privacy protection and the security perspective. Some questions raised on the thread, and an offer of joining a meeting. Breakout A would be good for me - not sure if for Lea though.

Matthew: Let's chat internally about having a meeting (and when).

Scheduling options for call with the group:

Sorry for the delay in getting back to you. We'd like to invite you to join one of our breakout calls for the week of the 10th of June:

• Breakout C (21:00 UTC, 10 June 2024);
• Breakout D (22:00 UTC, 11 June 2024); or
• Breakout E (07:00 UTC, 12 June 2024) -- this one

/cc @martinthomson

posted

Anssi: this is a WICG - but it's built on top of the openscreen protocol...

Michiel: implementation

Wei: implementing open screen library

Anssi: presents slides

Anssi: new WICG incubation ... prototyping activity going on in Chromium ... also a Go library by Michiel. This became the 2nd most discussed API in WICG... Most was positive feedback. There seems to be developer demand and user demand. We are trying to accomplish an off-line first version of peer-to-peer focusing on LAN use cases... connect securely over a local communication medium without the server in the middle. We want to serve the needs of the user first. The user is in control - through the user agent. We expose only the minimum functionality to get the job done. Local network currently not a first class citizen of the web... easier for the browser to trust a server far away than trust a device you have in your local network... coined local communication medium. Discovery, request, connect to peers, send and receive data, enable secure https connections... We've looked at https for local domains and incorporated... We want to build an open tech ..

Martin: What is your security [story]?

Michiel: from a high level .. how the 2nd screen protocol .. advertising pees over mdns... then establishing trust ... using a PIN code that you enter to connect to a device you're expecting to connect to... that creates trust. Each peer creates a self-signed cert. Now the relationship between these 2 peers - they trust because of the handshake - then use that cryptographuc material to do bi-directional communications - then use those certs as trust anchor to do PKI for the local network.. because devices trust eachother use that to start securing services... it's all based on the 2nd screen protocl. described independent on what network you're using but initial imlementation is on local area network...

Martin: a bunch of question s... what's the origin you're talking to? this sits on top of certs. you need to opaque bind to the TLS connection... Sounds like it requires a lot of analysis. Are you asusming that the person has physical access?

Michiel: we're replicating the same user experience [from chromecast]

Martin: there is a person sitting in front of a screen attached to both devices... that can show something... similar to bluetooth pairing codes but none of that is clear in the description.

Anssi: use cases off-line collaboration - tools working without internet connectivity... illustrated as a version of google docs that works offline across peers; sending and receiving files instantly; export to "nearby" devices - from a web application - you don't need to go to the cloud and back; video editing also becoming a thing on the web <- we got feedback from users; Use your mobile phone as a game controller; disaster relief - feedback from people who work in this area that there is a need for ad-hock web-based tools that work offline. Home services, IoT, attached storage...

Michiel: use case for baby monitors at home...

Dan: abuse scenarios, e.g. abusive partner mis-using?

Anssi: contrasting with WebRTC we expose the friendly name.. don't provide programmitic API...

Michiel: that's a tricky one... from a tech pov it's hard to provide an answer... doesn't create a new attack surface that doesn't exist...

Anssi: please feel free to open issues in our repo...

Simone: Considerations like the one from Dan - one level is trust between peers... Peer to peer devices can be misused... inside a network you can use these to [inject] malware... How to avoid that I have an device with me that gives my position... how to avoid... giving info with privacy. Also with openscreen protocol ... this could be used to fingerprint the network...

Anssi: we could document these attack vectors... and figure out how they're currently mitigated... Please open issues in our github repo...

Dan: abuse scenarios

Michiel: yes we do want to do this - we have done a lot of work here e.g. fingerprinting... noe of the discovery information is leaked to the browser without user consent... I think we can step up our game...

Anssi: we've learned from WebRTC so we can do better...

Martin: needs more detail in the spec ... or explainer ...

Michiel: implementation on top of OpenScreen protocol... What we're showing is what's happening at the protocol level - during the discovery phase we involve the user agent ... not exposed to the JavaScript realm... Could be similar to the Matter protocol where the key is something on the device itself (a sticker). Protocol negotiates which is the displaying party and which is the entering party... Uses mdns, ... they (openscreen) has a network of trusted devices on your network... We're doing bi-directional communication - taking inspiration from RTCDataChannel... also exploarion on how we get closer to WebRTC... If we do TLS between these peers then you could create a chain of trust for certs for these web services... Mitigate agains the browser saying "this is unsafe" when you're connecting to a device next to you.

Yves: WebTransport is not p2p, per charter

Michiel: we're looking a P2P version of webtransport ....

Martin: suitability of things like webRTC... there was a deliberate choice of making webrtc and web transport different. Quic is an evolution of what we'learned in sctp... There is work in IETF to evolve... I would encourage dropping WebRTC and concentrate on webTransport... client-server roles... then we have a basis in the origin model and thinking how this fits with existing things... One of the nice things about webtransport - once you have negotiated a connection, the API is symetric...

Anssi: comparisin between WebRTC and Local Peer-to-Peer.

Michiel: we are leaning more in this direction... we would prefer to use Quic and web transport API - there needs to be some canonical library...

Martin: a few things that can't be shimmed on the top...

Martin: that is my opinion...

Michiel: interesting to ... be able to assign peers a clear role...

Martin: webrtc works with a signalling arrangement... an offer and an answer... one peer becomes a server and one becomes a client... here you have a clearer scenario... there's a thing sitting in the network disovered using mdns... then the browser discovers it and acts as a client... Now what you're doing is looking up a special name... most APIs won't care... they're just names - some of them end in .local then you're establishing a webtransport connection to that name...

Michiel: effectively all those pieces are in place... we need to figure out how to define that more properly...

Martin: need more detail in the spec... There's a lot of useful work on building frameworks... in IETF .. had this not already been put on the rec track... i would have advocated doing the protocl in the ietf and the API work in W3C... We're doing that in web transport... that's worked out very well... That adds rigour.

Anssi: we did consider that... the rationale was that the openscreen protocol people were in the working group... also particiapted by people who are in IETF... it was raised but not easy decision... It's not always smooth sailing to split work like that ... e.g. web sockets.

Martin: i think stuff after websockets has worked better.

Matthew: bootstrapping process. devices with screens... my initial thoughts was this about higher level devices... but if some devices are like a mouse that doesn't have input or output... we need to think about the bootstrapping process - in web-of-things you can get into issues with accessibility... e.g. a device where you have to press a button to reset which is inaccessible.... Just to keep in mind.

Martin: this is a fundamentally new capability ... there is some advice that a11y group can give... it would be great to signal this is coming and get people thinking about it...

Yves: I think it would be better to wait...

Matthew: Should we summarize what we talked about in terms of the plenary ... and the call itself and put that on the thread?

Dan: Point them to our minutes and minutes?

Matthew: I'll look at it and see if I can summarize. Certain things about handshaking and security that were signifigant concerns...

Dan: assigns to f2f

Martin: one thing I like about the things they've done: the device is explicitly opting in...

Martin: not a whole lot of discussion since we gave the feedback...

IETF vs W3C

Dan: leaves a note asking Anssi for any update

No info...

Dan: anything at TPAC

generally no

Matthew: there was a breakout with a similar title... local https...

Martin: no details yet on that...

Yves: anything on local TLS in ietf?

Martin: there is mutual TLS .. but that was a little controversial.

Martin: concluded that needed more time - we gave Anssi & co info to consider. we expect a major update before we re-engage on that one.