Security restrictions on web<->device communication

Hi Web Bluetooth folks,

Some Google folks have been talking about the security risks of exposing
devices to the Web when those devices weren't designed to be secure in the
face of that access. We'd like your input in figuring out how best to
mitigate those risks, especially by answering the questions at the bottom
of this email.

An example vulnerable device comes from the FIDO specifications:
https://fidoalliance.org/specifications. In particular, a web application
that gets paired with a FIDO device can sign a challenge presented by a
different origin, breaking the FIDO security model. The UI needed to phish
a user in this way appears to be simple.

To mitigate this risk, I've put together a draft GATT service at
https://docs.google.com/document/d/1T6hLoLvOzNrcMrbtUxAO8yF8zskHiqKfEIPxJNYvfvg/edit
to let devices control their interactions with websites, in a way that
resembles both CORS <http://www.w3.org/TR/cors/> and postMessage's origin
attribution
<https://html.spec.whatwg.org/multipage/comms.html#security-postmsg>. Feel
free to comment on that document.

Once that service is standardized, if a device implements it, we're home
clear. The open question is what to do about devices that don't define the
new service.

We'd like to get some feedback from this list before deciding what to do.

   - Can the Bluetooth experts here think of other devices for which
   general web access would be a security problem? Can you put us in touch
   with any other Bluetooth security experts who would have good input?
   - If browsers were to require devices to expose a particular service
   before letting websites talk to the device, what proportion of existing
   devices would be able to accept a firmware update to expose that service?
   - If browsers were to require a device's PnP_ID
   <https://developer.bluetooth.org/gatt/characteristics/Pages/CharacteristicViewer.aspx?u=org.bluetooth.characteristic.pnp_id.xml>
   to appear on a whitelist before we'd grant access, do any of you have a
   feeling for how difficult that whitelist would be to maintain? I see about
   500 vendors granted IDs through the Bluetooth SIG, and we'd probably want
   each of them to provide a URL we could fetch to get their piece of the
   whitelist.
   - If browsers were to require a service's UUID to appear on a whitelist
   before we'd grant access, can you think of any safe way to include UUIDs
   that aren't standardized? In particular I'm worried about attackers
   whitelisting their victims' UUIDs. Is it safe enough to let any registered
   vendor whitelist any UUID?
   - If browsers allow access by default, and a device is found to be
   vulnerable to an attack, what's the best way to blacklist it? I hear that
   the Device Information service may not distinguish different devices using
   the same controller.


Thanks for any help,
Jeffrey