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]

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

[martinthomson]

Something to add here: the IETF has started a mailing list to look into the authentication problem for HTTPS. See https://mailarchive.ietf.org/arch/browse/settle/ That's not a complete overlap, but a lot of the problems this work is grappling with are being discussed there.

[martinthomson]

Hi @anssiko, the TAG discussed this in a breakout yesterday,

We see that there has been some discussion about a split between networking parts and the application pieces. It seems like this will result in some significant changes, including a potential move of large parts of the proposal to the IETF.

We are interpreting the material you have linked as an opportunity to give the folks working on the proposals some space to refine their proposals. To that end, we'll put this issue on hold.

If there is anything the TAG can do to help or if you think that the proposals have stabilized to the point that a review would be helpful, please let us know.

[anssiko]

@martinthomson & TAG team, thank you for revisiting this review request. The split of the Open Screen Protocol dependency has in fact already happened, and the new WDs have been published (and the all-in-one spec appropriately archived):

• Open Screen Application Protocol
• Open Screen Network Protocol

The group believes the Network Protocol part could possibly move to IETF Dispatch.

This split was in part motivated by feedback from the TAG and discussion with IETF experts.

Your suggestion to put this TAG review on hold for the time being as we gather feedback from the relevant IETF groups sounds good. Thank you for your directional guidance and pushing related efforts onwards at IETF too.

That said, feel free to share any related IETF developments in this issue, e.g. if the discussion re HTTPS on the settle list develops into new deliverables or changes relevant to this work.

[torgo]

Ok thanks @anssiko we're going to close this issue but we will re-open when new information becomes available.