backkem / local-devices-api Goto Github PK

The first way this can happen is by the user agent. Just like other user-agent state, the thrusted device list can be synchronized across devices.

Aside from this, one may wonder if an origin can sync the thrusted devices it has access to. The security model around this needs to be explored further.

Investigate if there is need to rotate certificates.

• Is this needed if we use mDNS?

The goal of this project is to introduce new building blocks for the web in a LAN context. The current spec ties together service discovery and connecting quite heavily. We way want to rewrite this so the service discovery becomes optional. E.g.: if you know the address of what you connect to, you can try to connect directly.

Migrate over the initial draft from this document.

This ticket explores means of pairing automatically without user interaction. These techniques are meant to be additive to the core pairing logic to enable user-friendliness improvements. Therefore, they don't have to be adhere to the LAN-only prerequisites that the main spec but they cannot compromise security.
Potential approaches include:

• Pre-shared keys
• External signaling, E.g. using a cloud service.

• Enforce contributor attribution.
• Generate TOC.
• Push to go-pages branch.

Having a generic list of local devices leads to some problems:

• Applications are only able to list all devices since there is no obvious way to filter them. This doesn’t provide a very user friendly device overview.
• Users don’t have much control to limit the access of an origin to specific device types. E.g.: a game should only get access to peers or controllers. A remote control app should only have access to TVs. Neither should have access to tour NAS or a doorbell. This filter should be clear in the user consent dialog.

→ We need to introduce some form of ‘device type’ to amend this.