Roadmap for allowed devices

[fbender]

Something that came up a couple of times: Identifying resp. filtering devices by some form of ID to limit the amount of accessible devices and provide identifying information to users resp. user agents. Issue is that "true" serial port devices have no identifying information, only serial over USB/BT has, property of the underlying protocols. Plus, the identifying information may change depending on device mode.

Hence, there's a few options for the API:

1. Only allow connecting to "tunneled" serial ports with identifying information. The channel is tied to these information.
2. Same as 1, but allow a range of identifying information.
3. Same as 1, but do not tie a channel to identifying information.
4. Also allow "plain" serial port access with no identifying information.

All options have implications for the amount of information that can be displayed to users via user agents.

For the Web API proposed here, we could do a tiered approach. Specify the whole range of capabilities (as outlined above) including the data that can be used as identifying information(*), but make any UA compliant to the spec that satisfies option 1.

In a supporting document/wiki/blog post, we could propose a roadmap for implementers to enable more capabilities over time, e.g. start with option 1 or 2, leave 3 and 4 disabled, then enable option 3 after 2-3 releases, and let 4 be only enabled for installed web apps, etc.

WDYT?

(*) Cue privacy concerns … some may want to mangle the BT MAC, we should consider that. Or rather not expose any unique IDs via the API (only allow accepting values).

[reconbot]

We touched on this topic on #36. We have a lot of stories that require access to unidentifiable devices.

Are you suggesting a way of allowing sites access to previously approved devices?