Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Case: Provide web pages with access to local hardware capabilities #18

Open
benfrancis opened this issue Aug 22, 2022 · 0 comments
Open
Labels

Comments

@benfrancis
Copy link
Member

benfrancis commented Aug 22, 2022

As a web developer I want to access local hardware capabilities in client-side JavaScript, so that my web app can make full use of a user's device.

In addition to communicating with a connected device over a remote connection, what if the Web Thing Protocol could also be used by web pages to safely communicate with local hardware capabilities from JavaScript?

Example hardware capabilities:

  • Audio volume
  • Light sensor
  • Screen brightness

This could also offer an alternative to the proposed WebUSB, WebBluetooth, WebMIDI, WebNFC, WebSerial and WebGPIO client-side JavaScript APIs which all have similar security issues. Rather than prompting users for full access to a trusted low-level data bus using a client-side JavaScript API, WoT Thing Descriptions could be used to provide a higher level description of hardware capabilities which are easier for users to understand. Web pages could then request access to those capabilities and communicate with devices via the Web Thing Protocol, using the existing fetch and WebSocket JavaScript APIs.

Local WoT services could be discovered using DNS-SD, well-known localhost URIs or even DID documents.

Example devices:

  • MIDI keyboard
  • Bluetooth robot
  • Raspberry Pi HAT
  • USB nerf gun

The tricky part is the security model. How to authorise access to local web resources using something equivalent to OAuth. Capyloon have been experimenting with a decentralised approach to something like this using DID & UCAN. A less sophisticated solution might be to simply give those local services a FQDN using a secure tunnelling service and use OAuth2 and TLS. That might sound scary but could actually be safer than exposing low level data buses to arbitrary web pages behind an opaque permission prompt.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant