[Idea] Local devices API (LAN services)

The local network is no longer a first class citizen of the web world. It’s easier to trust a faraway server than your NAS, TV or thermostat sitting right next to you. This is sad and could be different.

Before committing to writing a full spec I want to pitch the general idea. This due to the sheer amount of seemingly stalled efforts in this space (Network Service Discovery API, FlyWeb, raw-sockets, TCP and UDP sockets and numerous threads on this forum). My goal is to gather initial insight and discuss potential security implications before continuing towards a formal spec.

Security

To ensure strict security, this effort aims to treat the LAN in the same way as the web at large. We don’t trust any devices by default and all security efforts, such as CORS and CSP, should apply.

Trust

The biggest missing piece for connecting to local devices is handling trust and doing it in a user friendly way. One can host a service on a LAN with self-signed certificates and add those to their certificate store. However, this is far outside the capabilities of a regular user. ChromeCast and similar technologies show that this can be done in both a user friendly and secure way. The proposed API would allow a browser to initiate a connection to a device on the LAN. The API can narrow down the devices it wants to talk to. The exact identification or filtering system can be decided later. This instructs the user agent to scan the local network and give the user an overview of compatible devices. The user makes his choice from the list. This prompts the user agent to start a handshake procedure. The first time this handshake takes place the user has to manually confirm the authentication using a ‘PIN verification’ step as used in ChromeCast or Bluetooth authentication. This is done to avoid MITM attacks. From that point forward, trust has been established between the user agent and said local network service. In practice this likely means that a self signed TLS certificate is now trusted for this device or service. I see this ‘trust’ or security context between the user agent and a device/service on the local network as orthogonal to the protocols that use it. Below I specify two potential uses: message passing and local HTTPS.

Offline-first

To be truly useful for IOT use-case the entire setup should work without internet access. This means, no cloud and no certificate authorities, only what is available on LAN. No-one likes it when their vacuum stops working because it can’t phone home to the cloud.

Known services/devices

If I wanted to build a WPA that serves as a remote control for my TV it would be useless if I have to go through this consent flow every time. Therefore, the user agent can remember devices on two levels. First, when the user agent has a ‘trust relation’ with a service, it can re-establish the connection without the ‘PIN verification’ step. Secondly, the user agent can track access permissions per origin, just like is done for UserMedia. Finally, the user agent may choose to synchronize these settings across devices.

Protocol

Giving access to low level protocols opens up a lot of security concerns. This proposal explicitly avoids that by letting the browser manage the trust relation with a local service or device. However, this means a new tailored protocol must be introduced. Just like ChromeCast it would use existing protocols under the hood, E.g.: SSDP/UPnP for service discovery and TLS for the handshake. Bridges can be built for backwards compatibility until devices adopt the new standard.

Message passing

For use cases in IOT I suggest a simple message passing API that allows bidirectional message passing with the LAN device. As to not reinvent the wheel, this may be the WebTransport API that uses the security context provided by this proposal. Use-case include: Web based IOT hubs, remote controls, …

[Addendum] Local HTTPS

This approach would allow users to securely connect to services on their local network. Once trust is established with a local service, the resulting certificate can be used for a HTTPS connection. A variation of the above approach may open up an opportunity to combine HTTPS with mDNS. Potentially allowing you to directly navigate to an HTTPS mDNS URL, e.g.: https://device.local and letting the browser automatically trigger the verification and consent flow described above. Use-cases include: Finally being able to directly connect to a local NAS with a user friendly and secure context.

2 Likes

AFAIK, WebRTC can connect two devices over a LAN that can then communicate over a DataChannel. The main problem is the signalling, i.e. how to exchange the offer and answer between devices on the LAN. Commonly this is done over the Internet, e.g. a WebSocket connection to a signalling server. There are also some interesting approaches using things like QR codes to exchange data locally. However it would be useful if the LAN itself could act as a signalling service and use the actual local network to exchange the offer and answer and establish a local connection, without having to make the user manage some kind of manual exchange.

Perhaps it’s also the case that the most minimal and simple way to solve LAN networking with web technologies is a small API that solely serves as LAN signalling for WebRTC. Then apps can set up a DataChannel (and/or video/audio streams) and go from there.

This would be good for us for LAN-based multiplayer with offline web games. It could also simplify deployment as you could set up local multiplayer without having to also set up a signalling service, contact STUN/TURN servers, etc.

1 Like

Hi AshleyScirra,

Yes, WebRTC signaling would be a great application as well. I like the idea of reviving LAN games. I also imagined connecting to a doorbell video feed without requiring signaling via the cloud. It could be as seamless as casting video to your TV today.

In the router, DHCP reservations assign a unique MAC to a IP address. Using that along with a random port is a fairly good level of security. Also possible to pass a secret along too, e.g. in the URI string.

This isn’t a user-friendly process but IMO only because of paternalistic UX design. On my Telus router (Canadian telecom) for instance, DHCP options are hidden away, behind an ominous warning screen.

This would be huge! These are the use cases that excite me.

Signaling is the most insecure part of a WebRTC connection

You put a lot of faith in the remote server to not modify your offer/answer. If an attacker could intercept your message they can MITM you. If I am transferring a file to someone in my LAN why should I have to connect up to a remote server?

I don’t want my devices connecting to the internet

To echo what @backkem-gh said it is a shame that my NAS, TV, Security Camera etc… needs to give access to the world. I really would prefer that my phone be able to connect directly!

I want a vendor agnostic protocol for casting

I am frustrated that I can’t cast to my smart TV from my Linux laptop. I have tried some of the stuff out there, but it is frustrating. I want something that is standardized and I can easily send Pion/ffmpeg/GStreamer/$x to it.

I want P2P in air gapped networks


@AshleyScirra you can connect two WebRTC peers without signaling in a LAN! It requires pre-configuration and exploits some undefined behavior, but it works. Check out this repo pion/offline-browser-communication.

I also wrote webrtc-uri but not as excited about it after feedback from others. One interesting idea I heard is that instead of storing details in the URI you should broadcast them in mDNS. A WebRTC Agent could announce their ICE Details, and then we just need to have control of certificate the agent uses.

I don’t know where to take any of these ideas from here. I am interested and happy to make the changes happen in multiple WebRTC implementations.