From 24f81e978933d9dcea5d313ae29514255f7c6508 Mon Sep 17 00:00:00 2001 From: Michiel De Backker Date: Thu, 25 Jan 2024 20:47:02 +0100 Subject: [PATCH] TAG review prep --- EXPLAINER.md | 285 ++++++++++++++++++------------ security-privacy-questionnaire.md | 56 ++++++ tag_review_request.md | 47 +++++ 3 files changed, 271 insertions(+), 117 deletions(-) create mode 100644 security-privacy-questionnaire.md create mode 100644 tag_review_request.md diff --git a/EXPLAINER.md b/EXPLAINER.md index e3d500c..e9bd20e 100644 --- a/EXPLAINER.md +++ b/EXPLAINER.md @@ -1,14 +1,12 @@ # Local Peer-to-Peer API Explained -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 such as the Local Area Network. +The Local Peer-to-Peer API enables browsers to connect securely over the Local Area Network, without the aid of a server in the middle. -The API aims to strike a balance between creating a powerful new building block for developers and providing a seamless, secure and privacy preserving experience for the user. As an example: while the API doesn’t provide raw socket access, it does aim to give developers the flexibility to innovate on top by providing a persistent, two-way communication channel with little overhead. +The API provides a powerful new building block for developers while ensuring a seamless, secure and privacy preserving experience for the user. By putting the user-agent in control during discovery and authentication, bare minimal network topology information is exposed to an origin. -See also: +Please refer to the [specification](https://WICG.github.io/local-peer-to-peer/) for the the formal draft spec. -- [Specification](https://WICG.github.io/local-peer-to-peer/), the formal draft spec. - -## Motivation +### Motivation As a blast from the past: @@ -16,27 +14,141 @@ As a blast from the past: This proposal sets to make a part of this Tim's vision a reality while adhering to the modern security and privacy requirements expected of modern web capabilities. -## Problem Description +### Goals -When a user wants to connect between two devices on the same network, for example to another device nearby—be it another device the user owns or that of a friend—the user has multiple ways to accomplish this task: +Build a generic Local Peer-to-Peer API and provide an arbitrary bidirectional channel on the web for devices under short-range communication environment, including: -1. _A cloud service_. The web has many ways of connections to a third-party cloud service: HTTP, WebSocket or WebTransport. However, all of these methods require a round trip through the internet. This is inherently dependant on external resources, it consumes network bandwidth and can be slow or costly and has privacy implications in all but the strongest E2E encryption schemes. +- Methods to discover, request, and connect to peers on the local network +- Listeners to notify if these method calls succeed or fail +- Listeners to notify if the connection is received or its status is updated +- Means to send and receive data after connection to a peer device has been established +- Means to enable secure HTTPS connections on the local network -2. _A local server_. Many modern Web security measures rely on the presence of naming, signaling and certificate authorities. Local use-cases where these authorities are not readily available have started lagging behind in user experience or are not supported altogether. A local solution involves knowing IPs, ports and accepting/ignoring a plethora of "Not secure" warnings to get going. This falls short of the user-friendliness that one can expect of—nowadays ubiquitous—cloud services. +As a commitment to an open standards-based implementation path, this specification describes how the API can be implemented on top of the [Open Screen Protocol](https://w3c.github.io/openscreenprotocol/). While not described here, the API is expected to be implementable on top of other transports when technically feasible. -3. _A WebRTC connection_. While WebRTC is a P2P protocol, it still requires a setup step usually referred to as 'signaling'. There is no good way to perform this step without relying on an existing connection between peers, commonly a cloud service is used. +### Non-goals -None of these solutions to this seemingly common task provide a compelling user experience. When the devices are physically nearby the user's expectation is the connection process should be as seamless as any physical interaction. With close-range communication technologies widely supported on today's devices we believe this user experience can be vastly improved. +- Providing direct access to TCP/UDP sockets. +- Compromising Cross-Origin Resource Sharing (CORS) in any way. -We need an optimized network path to use a local network connected by the devices for web applications. +## Use Cases -![problem](./images/problem.svg) +### UC1: Offline collaboration + +- Collaboration tools that work during an internet outage or emergency situations +- Ephemeral groups support: Share files to a group with a single “push” vs. sending to each friend one at a time + +![G](./images/n2.svg) + +Figure 1: Collaborate from nearby devices in Google Doc + +### UC2: Disaster relief + +- The ability to for Web-based tools to work on ad-hoc networks in the absence of internet infrastructure. +- An app that allows humanitarian field workers in remote areas with no connectivity to gather, synchronize, review, and edit data offline for several days, the data can then be synchronized with the central server when internet connection becomes available +- A non-profit educational organization is concerned about the large file download size required for on-device speech recognition in the browser. This is problematic in low bandwidth, high latency environments such as classrooms, particularly in emerging countries. Their goal is for one student to download the file first and then easily share/distribute it with classmates without low speed internet connections any more to save time and cost + +### UC3: Cross-device workflows + +- Send and receive files instantly, including photos or videos, between mobile phone, tablet, and personal computer without using mobile data or internet connection +- Add the "Import file nearby" and “Export to nearby” buttons in web version of Figma on desktop to access images from mobile devices" +- Open files in "Nearby" tab in "Open a file" dialog of Google doc +- Video editing web app that allows users to ingest footage directly from their phone. +- Seamlessly sync private keys and other identity credentials across personal devices, securely transfer one-time pads to encrypt and decrypt messages + +![Web Drop](./images/drop.svg) + +Figure 2: Web Drop, an In-App Sharing feature based on Local Peer-to-Peer API compare with cloud-client solution + +### UC4: Home Services & IoT + +- Seamlessly connecting to your NAS or your home security system. Avoiding the need for workarounds including self-signed certificates or a cloud proxy services. +- Allow web apps to connect to your robot mower, vacuum or robotic assistant folding the laundry. +- Avoiding the need for companion native apps for services running in the home environment, e.g.: Home Assistant, Plex, BitWarden, NextCloud, ... + +### UC5: Local multi-player + +- In-App Sharing, quickly share group photos or videos with friends without relying on cloud services +- Run a game in web app on the smart TV, use mobile phone as the game controller via this local peer-to-peer API to send control messages + +- Run a 2 players web game on two mobile phones, synching messages between two players instantly + +![Game 1](./images/n3.svg) + +Figure 3: Play web game cross smart TV and mobile phone + +### Requirements + +The following are the high-level requirements derived from the use cases: + +- R1: Discover nearby device(s) +- R2: Advertise yourself to nearby device(s) +- R3: Establish a bi-directional communication channel between two nearby devices +- R4: Allow secure connection to locally hosted web pages. +- R5: User consent and delegation per web origin. + +### Prerequisites + +What is a prerequisite for all these use cases is that the participating devices are physically nearby to each other and as such able to establish a direct connection using either a wireless connectivity technology such as Wi-Fi Direct, Wi-Fi via access point, or a wired computer networking technology such as Ethernet. This connection technology and its details are abstracted out by both the Web API exposed to web developers as well as the UI/UX visible to the user. + +In summary, the following are the prerequisites: + +- The participating devices are physically nearby (the definition of "nearby" is an implementation detail) +- The participating devices are able to establish a direct connection using some connection technology (the supported technologies may vary depending on hardware and OS capabilities and remain an implementation detail) + +### References + +- https://github.com/WICG/proposals/issues/103 +- https://github.com/WICG/private-network-access/issues/23 +- https://github.com/WICG/local-peer-to-peer/issues/19 +- https://github.com/ipfs/local-offline-collab +- https://offlinefirst.org/ +- https://github.com/pion/offline-browser-communication + +## Solution Approach + +The Local Peer-to-Peer API uses the to mutual authentication provided by the Open Screen Protocol to establish mutual TLS certificates between peers. These certificates serve as a trust anchor for secure communication. The Local Peer-to-Peer specification defines two uses of this new trust anchor: + +1. Enabling HTTPS on the local network. +2. Enabling data communication on the local network using the `DataChannel` and `WebTransport` APIs. + +### API Design + +Peer-to-Peer communication starts with service discovery. For this purpose, the LP2PReceiver API allows an origin to advertise itself. The LP2PRequest API allows discovery of a peer on the network. The design if these APIs is inspired by the work of the Presentation API's PresentationRequest & PresentationReceiver. Data exchange itself is provided by two APIs: `LP2PDataChannel` & `LP2PQuicTransport`. The [LP2PDataChannel API](https://wicg.github.io/local-peer-to-peer/#lp2p-data-channel) is inspired by the RTCDataChannel API. This API caters to simple message passing use-cases and developer familiar with WebRTC. The API design augments that of the WebRTC RTCDataChannel API. The [LP2PQuicTransport API](<](https://wicg.github.io/local-peer-to-peer/#lp2p-quic-transport)>) design is inspired by the WebTransport API. This API is designed for use-cases where more direct control over the underlying transport is preferred. + +## Shorthand APIs + +The specification provides shorthand APIs for the most common use cases. More granular APIs are discussed below. + +```js +// Peer A +const listener = lp2p.makeDiscoverable(options); + +for await (const transport of listener.incomingTransports) { + await transport.ready; +} +``` + +```js +// Peer B +const transport = lp2p.connect(options); + +await transport.ready; +``` + +_Note_: the shorthand APIs are a work in progress. They are illustrative and will change, see [#35](https://github.com/WICG/local-peer-to-peer/issues/35). + +## Local HTTPS + +The Local Peer-to-Peer API's authentication process establishes mutual TLS certificates between peers on the local network. These certificates can serve as a trust anchor to validate certificates used by HTTPS servers on the local network. -Figure 1: Proposed Web Local Peer-to-Peer along with other existing options +Please refer to [Local HTTPS](https://wicg.github.io/local-peer-to-peer/#local-https) in the specification for more details. -## Usage example +_Note_: Local HTTPS is a work in progress, see [#34](https://github.com/WICG/local-peer-to-peer/issues/34). -### Establishing a connection +## Peer discovery + +Before any connection can be established, two peers on the local network must find each other. This is done using the `LP2PReceiver` and `LP2PRequest` interfaces: ```js // Peer A @@ -50,6 +162,8 @@ receiver.onconnection = (e) => { }; ``` +Please refer to the [LP2PReceiver Interface](https://wicg.github.io/local-peer-to-peer/#lp2p-receiver) in the specification for more details. + ```js // Peer B const request = new LP2PRequest({ @@ -60,7 +174,13 @@ const conn = await request.start(); console.log("Requester: Got a connection!"); ``` -### Basic message exchange +Please refer to the [LP2PRequest Interface](https://wicg.github.io/local-peer-to-peer/#lp2p-request) in the specification for more details. + +_Note_: The exact attributes used for peer discovery and filtering are still being discussed, see [#15](https://github.com/WICG/local-peer-to-peer/issues/15) + +## Simple message exchange + +Once two peers have found each other, they can establish a connection. The `LP2PDataChannel` interfaces allow sending and receiving messages over the connection: ```js // Peer A @@ -80,17 +200,14 @@ channel.onmessage = (e) => { }; ``` -### Dedicated WebTransport +Please refer to the [LP2PDataChannel Interface](https://wicg.github.io/local-peer-to-peer/#lp2p-data-channel) in the specification for more details. -```js -// Peer A -const transport = new LP2PQuicTransport(request); +## Advanced data exchange -await transport.ready; -``` +The `LP2PQuicTransportListener` and `LP2PQuicTransport` interfaces allow opening a [WebTransport](https://www.w3.org/TR/webtransport) connection between two peers. ```js -// Peer B +// Peer A const listener = new LP2PQuicTransportListener(receiver); for await (const transport of listener.incomingTransports) { @@ -98,74 +215,14 @@ for await (const transport of listener.incomingTransports) { } ``` -Refer to the [WebTransport examples](https://www.w3.org/TR/webtransport/#examples) for usage of a WebTransport object. - -## Use Cases - -### UC1: Single User Multiple Devices - -- Collaboration tools that work during an internet outage or emergency situations -- Seamlessly connecting to your NAS, your home security system, your robotic assistant doing the dishes. -- Send and receive files instantly, including photos or videos, between mobile phone, tablet, and personal computer without using mobile data or internet connection -- Add the "Import file nearby" and “Export to nearby” buttons in web version of Figma on desktop to access images from mobile devices" -- Run a game in web app on the smart TV, use mobile phone as the game controller via this local peer-to-peer API to send control messages -- Open files in "Nearby" tab in "Open a file" dialog of Google doc -- Video editing web app that allows users to ingest footage directly from their phone. -- Seamlessly sync private keys and other identity credentials across personal devices, securely transfer one-time pads to encrypt and decrypt messages - -![Web Drop](./images/drop.svg) - -Figure 2: Web Drop, an In-App Sharing feature based on Local Peer-to-Peer API compare with cloud-client solution - -![F](./images/n1.svg) - -Figure 3: Import file from nearby devices in web based Figma app - -![G](./images/n2.svg) - -Figure 4: Open a file from nearby devices in Google Doc - -![Game 1](./images/n3.svg) - -Figure 5: Play web game cross smart TV and mobile phone - -### UC2: Multiple Users and Devices - -- In-App Sharing, quickly share group photos or videos with friends without relying on cloud services -- Run a 2 players web game on two mobile phones, synching messages between two players instantly -- Ephemeral groups support: Share files to a group with a single “push” vs. sending to each friend one at a time -- An app that allows humanitarian field workers in remote areas with no connectivity to gather, synchronize, review, and edit data offline for several days, the data can then be synchronized with the central server when internet connection becomes available -- A non-profit educational organization is concerned about the large file download size required for on-device speech recognition in the browser. This is problematic in low bandwidth, high latency environments such as classrooms, particularly in emerging countries. Their goal is for one student to download the file first and then easily share/distribute it with classmates without low speed internet connections any more to save time and cost - -![Game 2](./images/n4.svg) - -Figure 6: Play a web game across two nearby devices with 2 players - -### Requirements - -The following are the high-level requirements derived from the use cases: - -- R1: Discover nearby device(s) -- R2: Advertise yourself to nearby device(s) -- R3: Establish a bi-directional communication channel between two nearby devices -- R4: User consent and delegation per web origin. - -### Prerequisites - -What is a prerequisite for all these use cases is that the participating devices are physically nearby to each other and as such able to establish a direct connection using either a wireless connectivity technology such as Wi-Fi Direct, Wi-Fi via access point, or a wired computer networking technology such as Ethernet. This connection technology and its details are abstracted out by both the Web API exposed to web developers as well as the UI/UX visible to the user. - -In summary, the following are the prerequisites: - -- The participating devices are physically nearby (the definition of "nearby" is an implementation detail) -- The participating devices are able to establish a direct connection using some connection technology (the supported technologies may vary depending on hardware and OS capabilities and remain an implementation detail) - -## User Interface Considerations - -ℹ️ This section is informative. +```js +// Peer B +const transport = new LP2PQuicTransport(request); -This section presents examples of user interface concepts. Implementers are expected to come up with their own shapes and forms for the user interface elements that fit the conventions of the underlying platform, form factor and the browser. +await transport.ready; +``` -![Shapes](./images/shape.svg) +Please refer to the [LP2PQuicTransport Interface](https://wicg.github.io/local-peer-to-peer/#lp2p-quic-transport) in the specification for more details. ## User Interaction Considerations @@ -175,47 +232,41 @@ This section represents concepts of how a user could discover, connect and share ![User flow](./images/userflow.svg) -## Goals +## Security and Privacy -Build a generic local peer-to-peer API and provide an arbitrary bidirectional channel on the web for devices under short-range communication environment. +The Local Peer-to-Peer API has been designed specifically with security and privacy in mind. Please refer to the [Security and Privacy Self-Review](./security-privacy-questionnaire.md) for more details. -The API will abstract over peer-to-peer technology and provide a high-level interface for two instances of a web app running on peer devices to discover and connect to each other. +## Considered Alternatives -The Local Peer-to-Peer API will cover the following main parts: +When a user wants to connect between two devices on the same network, for example to another device nearby—be it another device the user owns or that of a friend—the user has multiple ways to accomplish this task: -- Methods to discover, request, and connect to peers -- Listeners to notify if these method calls succeed or fail -- Listeners to notify if the connection is received or its status is updated -- Means to send and receive data after connection to a peer device has been established +1. _A cloud service_. The web has many ways of connections to a third-party cloud service: HTTP, WebSocket or WebTransport. However, all of these methods require a round trip through the internet. This is inherently dependant on external resources, it consumes network bandwidth and can be slow or costly and has privacy implications in all but the strongest E2E encryption schemes. + +2. _A local server_. Many modern Web security measures rely on the presence of naming, signaling and certificate authorities. Local use-cases where these authorities are not readily available have started lagging behind in user experience or are not supported altogether. A local solution involves knowing IPs, ports and accepting/ignoring a plethora of "Not secure" warnings to get going. This falls short of the user-friendliness that one can expect of—nowadays ubiquitous—cloud services. -The API is designed to be backed by an authenticated, streams-based transport. As a commitment to an open standards-based implementation path, this specification describes how the API can be implemented on top of the [Open Screen Protocol](https://w3c.github.io/openscreenprotocol/). While not described here, the API is expected to be implementable on top of other transports when technically feasible. +3. _A WebRTC connection_. While WebRTC is a P2P protocol, it still requires a setup step usually referred to as 'signaling'. There is no good way to perform this step without relying on an existing connection between peers, commonly a cloud service is used. -## Non-goals +None of these solutions to this seemingly common task provide a compelling user experience. When the devices are physically nearby the user's expectation is the connection process should be as seamless as any physical interaction. With close-range communication technologies widely supported on today's devices we believe this user experience can be vastly improved. -- Providing direct access to TCP/UDP sockets. +We need an optimized network path to use a local network connected by the devices for web applications. -## Security and Privacy +![problem](./images/problem.svg) -The Local Peer-to-Peer API can minimize security and privacy risks associated with cloud services. Web app users can choose to limit the use to offline mode only (completely disconnect the Internet) which improves the security further and avoids the information leak to cloud. +Figure 5: Proposed Web Local Peer-to-Peer along with other existing options -Restrictions will be evaluated in accordance with security models. Among others, restrictions may include: +4. The _Web Share and Web Share Target_ provide a minimal API to share text and files to a user-selected share target, including to another website, utilizing the sharing mechanism of the underlying operating system. -- Web browser restricted access -- [Secure context](https://w3c.github.io/webappsec-secure-contexts/) required -- Least privilege principle, permission granted one device to one site -- Pairing individual device requires at least a user action -- User informed when the device is connected -- Disconnect automatically after a period of inactivity (implementation-defined e.g. 10 minutes) with an extension opportunity with a user's consent -- Authorization on a per-session basis: Colleagues, friends, family members or the user themselves can authorize the “content pull request” on the device that can allow pulls for one session (e.g. 10 minutes) -- We are investigating whether this API should be restricted to PWA only +While the Web Share API partially satisfies the requirement R2 set forth above, the Web Share API by its design defines a minimal API surface that is likely not amenable to extensions required to support additional use cases and requirements outlined in this explainer. Notably, the Web Share API is a "push-based" API where content is pushed from one device to another device while the Local Peer-to-Peer API is catering to both the "push-based" as well as "pull-based" use cases as illustrated by "drop files here and share" and "import file nearby" concepts respectively. From the UX perspective, The Local Peer-to-Peer API allows for a more seamless in-web app experience in use cases where a system-provided share facility would disrupt the user flow. -## Considered Alternatives +Certain use cases can benefit from an internet-based P2P fallback if local communications is not available. To minimize conceptual weight for web developers, this API attempts to align with the established conventions and API semantics of other communication APIs such as WebTransport API, WebRTC, Fetch, and Presentation API, where applicable. -The Web Share and Web Share Target provide a minimal API to share text and files to a user-selected share target, including to another website, utilizing the sharing mechanism of the underlying operating system. +### Previous work -While the Web Share API partially satisfies the requirement R2 set forth above, the Web Share API by its design defines a minimal API surface that is likely not amenable to extensions required to support additional use cases and requirements outlined in this explainer. Notably, the Web Share API is a "push-based" API where content is pushed from one device to another device while the Local Peer-to-Peer API is catering to both the "push-based" as well as "pull-based" use cases as illustrated by "drop files here and share" (Figure 2) and "import file nearby" (Figure 3) concepts respectively. From the UX perspective, The Local Peer-to-Peer API allows for a more seamless in-web app experience in use cases where a system-provided share facility would disrupt the user flow. +A number of efforts exist in this area including the [TCP and UDP Socket API](https://www.w3.org/TR/tcp-udp-sockets/), [Discovery API](https://www.w3.org/TR/discovery-api/) and [FlyWeb](https://flyweb.github.io/). -Certain use cases can benefit from an internet-based P2P fallback if local communications is not available. To minimize conceptual weight for web developers, this API attempts to align with the established conventions and API semantics of other communication APIs such as WebTransport API, WebRTC, Fetch, and Presentation API, where applicable. +The Local Peer-to-Peer approach differs from previous work by putting the user-agent in control during device discovery and mutual authentication. This approach allows exposing bare minimal information about the device to an origin. The list of discovered devices is never shared with the origin and individual peer descriptors such as nickname are only shared with the origin after authentication and user consent. No network information such as IP addresses is ever shared with an origin. + +The following works are seen as precedent and guide the design of the Local Peer-to-Peer API: [Open Screen Protocol](https://www.w3.org/TR/openscreenprotocol/), [Presentation API](https://www.w3.org/TR/presentation-api/), [Remote Playback API](https://www.w3.org/TR/remote-playback/) [WebRTC](https://www.w3.org/TR/webrtc/), [ORTC (draft)](https://draft.ortc.org/), [WebTransport](https://www.w3.org/TR/webtransport/), [P2P WebTransport (draft)](https://w3c.github.io/p2p-webtransport/). ## References & Acknowledgements diff --git a/security-privacy-questionnaire.md b/security-privacy-questionnaire.md new file mode 100644 index 0000000..c595f84 --- /dev/null +++ b/security-privacy-questionnaire.md @@ -0,0 +1,56 @@ +# [Self-Review Questionnaire: Security and Privacy](https://w3ctag.github.io/security-questionnaire/) + +1. What information does this feature expose, + and for what purposes? + - A: [Addressed in spec doc](https://wicg.github.io/local-peer-to-peer/#security-pii) +2. Do features in your specification expose the minimum amount of information + necessary to implement the intended functionality? + - A: The proposed design puts the User Agent in control of peer management. This approach was designed specifically to limit exposing information as much as possible. +3. Do the features in your specification expose personal information, + personally-identifiable information (PII), or information derived from + either? + - A: [Addressed in spec doc](https://wicg.github.io/local-peer-to-peer/#security-pii) +4. How do the features in your specification deal with sensitive information? + - A: [Addressed in spec doc](https://wicg.github.io/local-peer-to-peer/#security-pii) +5. Do the features in your specification introduce state + that persists across browsing sessions? + - A: [Addressed in spec doc](https://wicg.github.io/local-peer-to-peer/#security-persistent-state) +6. Do the features in your specification expose information about the + underlying platform to origins? + - A: By design no such information should be exposed. +7. Does this specification allow an origin to send data to the underlying + platform? + - A: The specification is meant to be implementable using the Open Screen Protocol, a cross platform protocol. +8. Do features in this specification enable access to device sensors? + - A: The specification doesn't allow direct access to device sensors. +9. Do features in this specification enable new script execution/loading + mechanisms? + - A: No +10. Do features in this specification allow an origin to access other devices? + - A: [Addressed in spec doc](https://wicg.github.io/local-peer-to-peer/#security-device-access) +11. Do features in this specification allow an origin some measure of control over + a user agent's native UI? + - A: [Addressed in spec doc](https://wicg.github.io/local-peer-to-peer/#security-ui) +12. What temporary identifiers do the features in this specification create or + expose to the web? + - A: [Addressed in spec doc](https://wicg.github.io/local-peer-to-peer/#security-pii) +13. How does this specification distinguish between behavior in first-party and + third-party contexts? + - A: A [Permission Policy Integration](https://wicg.github.io/local-peer-to-peer/#permission-policy-integration) has been defined. +14. How do the features in this specification work in the context of a browser’s + Private Browsing or Incognito mode? + - A: The [specification](https://www.w3.org/TR/openscreenprotocol/#private-browsing-mode) of the OpenScreen protocol are to be followed in this area. +15. Does this specification have both "Security Considerations" and "Privacy + Considerations" sections? + - A: Both Security and Privacy concerns have been considered. +16. Do features in your specification enable origins to downgrade default + security protections? + - A: [Addressed in spec doc](https://wicg.github.io/local-peer-to-peer/#security-same-origin) +17. What happens when a document that uses your feature is kept alive in BFCache + (instead of getting destroyed) after navigation, and potentially gets reused + on future navigations back to the document? + - A: This is an open point. It will be addressed by studying president set by specs such as [WebRTC](https://www.w3.org/TR/webrtc/) and [WebTransport](https://www.w3.org/TR/webtransport/). +18. What happens when a document that uses your feature gets disconnected? + - A: This is handled by the appropriate teardown logic & events. +19. What should this questionnaire have asked? + - A: No further comments. 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. diff --git a/tag_review_request.md b/tag_review_request.md new file mode 100644 index 0000000..e3d9c27 --- /dev/null +++ b/tag_review_request.md @@ -0,0 +1,47 @@ +## Review Request + +I'm requesting a TAG review of the Local Peer-to-Peer API. + +- Explainer¹ (minimally containing user needs and example code): [url](https://github.com/WICG/local-peer-to-peer/blob/main/EXPLAINER.md) +- User research: [url](https://github.com/WICG/local-peer-to-peer/blob/main/EXPLAINER.md#use-cases). +- Security and Privacy self-review²: [url](https://github.com/WICG/local-peer-to-peer/blob/main/security-privacy-questionnaire.md) +- GitHub repo (if you prefer feedback filed there): [url](https://github.com/WICG/local-peer-to-peer) +- Primary contacts (and their relationship to the specification): + + - Anssi Kostiainen (@anssiko), [Intel Corporation](https://www.intel.com/) + - Belem Zhang (@ibelem), [Intel Corporation](https://www.intel.com/) + - Michiel De Backker (@backkem), [Twintag](https://twintag.com/) + - Wei Wang (@wangw-1991), [Intel Corporation](https://www.intel.com/) + +- Organization/project driving the design: [] +- External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): + +Further details: + +- [x] I have reviewed the TAG's [Web Platform Design Principles](https://www.w3.org/TR/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): WICG +- Existing major pieces of multi-stakeholder review or discussion of this design: N/A +- Major unresolved issues with or opposition to this design: See Open Work below. +- This work is being funded by: N/A + +You should also know that... + +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** + +**Open points** + +- 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. +- 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). +- There is a question if a stricter CORS variant is warranted for local HTTPS sites [Tracking issue](https://github.com/WICG/local-peer-to-peer/issues/34) +- DataChannel vs WebTransport: should we keep both? [Tracking issue](https://github.com/WICG/local-peer-to-peer/issues/29) +- Adding the appropriate teardown/shutdown logic & events is pending. This will be addressed by studying president set by specs such as [WebRTC](https://www.w3.org/TR/webrtc/) and [WebTransport](https://www.w3.org/TR/webtransport/). + +**Implementation experiments** + +To help inform the API design, we are conducting a series of experiments to evaluate the feasibility of the design: + +- [go-lp2p](https://github.com/backkem/go-lp2p): an experimental API implementation in Go. +- There is a WIP implementation of the Open Screen Protocol in [Chromium](https://chromium.googlesource.com/openscreen/). It is being upgraded to using [QUICHE](https://github.com/google/quiche) QUIC implementation. We intent to build a POC on top in the future.