Local Peer-to-Peer API

[anssiko]

こんにちは TAG-さん!

I'm requesting a TAG review of the Local Peer-to-Peer API.

• Explainer¹ (minimally containing user needs and example code): explainer

• User research: see use cases and references with supporting user discussion and open-source projects

• Security and Privacy self-review²: self-review

• GitHub repo (if you prefer feedback filed there): WICG/local-peer-to-peer

• Primary contacts (and their relationship to the specification):

  • Anssi Kostiainen (@anssiko), Intel Corporation
  • Belem Zhang (@ibelem), Intel Corporation
  • Michiel De Backker (@backkem), Twintag
  • Wei Wang (@wangw-1991), Intel Corporation

• Organization/project driving the design: Intel, individual contributors

• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status):

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
• The group where standardization of this work is intended to be done ("unknown" if not known): currently unknown, possibly Second Screen WG due to the Open Screen Protocol foundations
• Existing major pieces of multi-stakeholder review or discussion of this design: Local Peer-to-Peer API WICG/proposals#103 received encouraging feedback from multiple stakeholders and motivated this further work
• Major unresolved issues with or opposition to this design: no opposition per se, major unresolved issues noted as ℹ️ open points below
• This work is being funded by: Intel

You should also know that...

The following design considerations would especially welcome TAG's feedback:

• The Local Peer-to-Peer API aims to give browsers the means to communicate directly, without the aid of a server in the middle. It is designed to enable this communication within the confines of a local communication medium, a purposefully broad term defined for the purpose of this proposal.

  • ℹ️ We are seeking feedback on the local communication terminology and level of abstraction this specification establishes. Is this level of abstraction desirable? Early feedback suggests web developers prefer to work with an API that abstracts out details of the underlying communication technologies.

• For improved developer ergonomics, APIs are provides for both simple message exchange and advanced data exchange use cases. Also shorthand APIs are under consideration and will be develop further subject to feedback.

  • ℹ️ We would be in favor of a unification effort that aligns the DataChannel and WebTransport APIs across all transports (such as LP2P, WebRTC and HTTP/3).
  • ℹ️ DataChannel vs WebTransport: should we keep both? Tracking issue
  • ℹ️ Adding the appropriate teardown/shutdown logic & events is pending. This will be addressed by studying precedent set by specs such as WebRTC and WebTransport.

• Local HTTPS is proposed to improve local use of HTTPS. This feature is illustrated and discussed in Local HTTPS WICG/local-peer-to-peer#34 and has real-world demand from e.g. an established media player software vendor Feedback rcombs WICG/local-peer-to-peer#39

  • ℹ️ There is a question if a stricter CORS variant is warranted for local HTTPS sites Tracking issue

• This specification purposefully makes an effort to stay within established security concepts. It exposes less information, such as IP information, about the peers involved than WebRTC, see Security and Privacy self-review.

  • ℹ️ Security and privacy have been a major focus when designing this API. We're eager to hear about any concerns in this area so it can be addressed appropriately.

Implementation experiments

To help inform the API design, we are conducting a series of experiments to evaluate the feasibility of the design:

• go-lp2p: an experimental API implementation in Go.
• There is a WIP implementation of the Open Screen Protocol in Chromium. It is being upgraded to using QUICHE QUIC implementation. We intent to build a POC on top in the future.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

[torgo]

Hi @anssiko we are looking at this and we think it may be good to do a special session on it where you could join and present? This feels like a real major new feature. We're thinking one of our regular breakouts in the first week of May?

[simoneonofri]

Hello @anssiko, @ibelem, @backkem, and @wangw-1991,

The work looks very interesting to me, congratulations.

Regarding security and privacy, could you include a specific threat model for this issue? In addition to the typical cases already in the Open Screen Protocol (e.g., Passive Network Attackers, Active Network Attackers, DoS), it would be interesting to consider possible Abuse of Functionalities (so what a threat actor can implement with this technology) and reason about mitigations.
To give some examples:

• It could certainly be interesting as a P2P communication method during an attack, as it is currently used SMB for Protocol Tunneling
• Used the Discovery phase, and then for fingerprinting the devices present but also for doing user profiling (if you always have the same devices present), as mentioned in 12.2 Personally identifiable information
• Could have some similarities with UPnP

Thank you!

[anssiko]

@torgo @simoneonofri thanks for the initial feedback. We're happy to join your breakout with @backkem. Let us know when you have a date and time and we sync calendars.

@ibelem and @wangw-1991 are UTC+8 so it might be hard to find a slot that works for all -- I'll volunteer to bring their perspective and contributions into this breakout.

[matatk]

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)

/cc @martinthomson

[matatk]

Great, thanks @backkem, @anssiko, @wangw-1991, @simoneonofri. We will go with Breakout E (07:00 UTC, 12 June 2024) - we're looking forward to the discussion.

I'll figure out how to get you a calendar invite (I think we must have at least most of your contact details already; I'll confer with the rest of the group).

[anssiko]

@matatk please let us know if you need help setting up the invite. If you're missing some contact information you can ping me offline too.

[matatk]

@backkem, @anssiko, @wangw-1991, @simoneonofri: I sent out an invite last week, and I have replies from almost (if not) all of you for tomorrow's call (I got your email addresses from the 'W3C Groups' site).

If you didn't get the invite, or need any clarification, please let me know. If you need to reach me via email, you can find my address via the 'W3C Groups' site.

We are looking forward to learning more about this API tomorrow.

[matatk]

Hi all, and thank you again for the recent discussion. Our minutes, including minutes from our call, have been published - please let us know if you spot anything wrong, or missing. Our suggestions for further clarification/possible next steps in a number of areas, as we discussed, are noted there.

We also had a discussion in our plenary session the same week. We wanted to highlight one area where we have concerns: the security of the handshaking process (this came up in the call, but as it was also discussed in the plenary session, we wanted to point you to it).

Feel free to ping us via this thread as and when you have updates; thanks.

[autonome]

Hi @matatk! The plenary discussion link points to the call minutes link.

[matatk]

Hi @autonome, are you using the GitHub mobile app by any chance? It doesn't seem to jump to the correct parts of the document (both discussions are in one document) - if you are able to follow the links in a browser, you should be taken to the correct parts of the minutes.

[autonome]

User error: I see now that they are two separate parts of the same notes document, sorry!

[torgo]

Hi @anssiko just wondering if there has been any update after our discussion. Thanks!

[anssiko]

@torgo thanks for the ping. We'll have a discussion at TPAC at around 11 am on Friday 27 Sep w3c/secondscreen-wg#11 You're welcome to join us.

I will be there and I believe @martinthomson should be also there in person representing the TAG. @backkem will join remotely. We can use that session to discuss our path forward and continue translate valuable TAG breakout feedback into concrete issues.

[matatk]

We're discussing Local Peer-to-Peer API this week. For convenience, here's a direct link (from w3c/secondscreen-wg#11, linked above) to the slides from TPAC: https://docs.google.com/presentation/d/1080pCNqifmYn9u9FqZFSjst39rRJr8sSWzOzkCqgeeE/

[anssiko]

@matatk it looks like the link above is not working. Here are the working links to the slides from TPAC minutes:

• Local Peer-to-Peer API (also presented to WebRTC WG)
• Open Screen Protocol