WICG / local-peer-to-peer

↔️ Proposal for local communication between browsers without the aid of a server.
https://wicg.github.io/local-peer-to-peer/
Other
62 stars 6 forks source link

Local HTTPS #34

Open backkem opened 5 months ago

backkem commented 5 months ago

I wanted to discuss potential of this spec to contribute to local use of HTTPS.

As an illustrative example, let's explore the following use-case: connecting to your NAS console. Today this looks as follows: image A user is instantly faced with a security warning for connecting to their own device. The conventional workarounds include self-signed certificates or a cloud proxy service. The former is quite involved and the latter relies on a remote cloud service. Neither of these solutions are in-line with the premise of this spec. This applies to any local web service: Home Assistent, Plex, BitWarden, NextCloud, Proxmox, ... . It largely makes these accessible to tinkerer only, sidelining average users or pushing maintainers to write companion apps instead.

The following is an early exploration of how we may be able to improve the situation:

Certificates The LP2P API provides a means of establishing a certificate pair without reliance on a central authority. If we can define a means to determine the local peer when connecting to a local web page (likely during the TLS handshake). The user agent could kick-off the LP2P consent & authentication flow and use the resulting certificates to connect to the web server over HTTPS.

Discovery Secondly, the LP2P API provides a means of discovering local peers. This could be used to provide an additional level of ergonomics over having to manually enter the IP or hostname of a local web page. This is kind of UX fidelity that users have come to expect from modern apps like Sonos, ChromeCast, Apple Home, ... . This may be possible to accomplish by allowing the (authenticated) local peers to advertise a web page. The user agent can display it to the user appropriately.

anssiko commented 5 months ago

We should highlight this proposed feature in the upcoming W3C TAG early design review request and prepare to provide answers to questions akin to https://www.w3.org/TR/security-privacy-questionnaire/#remote-device

I think the TAG as a group is well positioned to provide guidance on this type of architectural design issue. The use cases this enables are compelling, no questions there.

For historical perspective re security-related UI:

Web specs by design haven't prescribed UI guidelines for browsers. That is, it is OK to provide informative content to outline UI concepts, but we cannot require a specific UI style, even for security-related UI components. That said, there has been attempts to define UI guidelines and requirements in a more abstract fashion e.g. https://www.w3.org/TR/wsc-ui/ I don't remember the full history of that work, but it is no longer actively worked on and shouldn't be cited. Still it can be read and learned from. Maybe someone lurking on this repo remembers better.

backkem commented 5 months ago

Yes, I agree. I think a full first Self-Review is likely in order for the early design review request as well.

Regarding this feature:

backkem commented 1 month ago

Reminder: explore Martin Thomson's prior work (document) as mentioned by @enygren in w3c/openscreenprotocol#275.

backkem commented 1 month ago

Reminder: explore Martin Thomson's prior work (document) as mentioned by @enygren in w3c/openscreenprotocol#275.

Reading through this again, our approach may actually be novel while fitting quite nicely onto the requirements laid out in the document. The idea is that LP2P provides a (possibly just-in-time, optionally persisted) method to establish a trust anchor between two local peers. This serves as a new root for a local-first key infrastructure. It securely connects to a unique peer (or device) and doesn't require altering the hostnames. And it could potentially be compatible with other local-first trust relations such a Matter fabric.