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

[backkem]

Breakout E would fit me best but I can make all of them.

[anssiko]

Breakout E works for me too.

[wangw-1991]

Breakout E works for me too.

[simoneonofri]

Breakout E works for me

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