Feature Request: Enhance Security by Sending Domain as Meta-data

[mduffy215]

I have a suggestion that would greatly enhance Web Bluetooth security.

A key use case for Web Bluetooth is to create a communication channel between a web application and a mobile application. By passing the domain from the web application as meta-data (preferably in an unhackable way) the mobile application will be able to provide programmatic confirmation that the user is on the right website ("www.chase.com" not "www.chaze.com"). The capability to securely send the domain would help a great deal in preventing phishing scams. This added security will be well worth the effort; and the effort should be fairly simple (the domain is already passed to the pairing screen).

This would need to be some sort of meta-data process call; simply calling a JavaScript method from the web page to sendDomain("Domain Name") would of course not be secure.

The first stated goal of the Web Bluetooth Community Group Charter is, "Allow websites to communicate with devices in a secure and privacy-preserving way." Sending the domain from the web application to the mobile application would enhance both security and privacy.

[jyasskin]

I'm not sure what you mean by "mobile application". In my mind, we have the web application running on a Bluetooth Central device, trying to communicate with (an application running on) a Bluetooth Peripheral device. It would definitely be nice to send the peripheral information about which web origin was trying to talk to it, but as far as I know, Bluetooth doesn't define a channel over which the browser could send that information. Do you know of one?

[reillyeon]

@jyasskin what about defining a GATT Characteristic in the Web Bluetooth specification that the user agent should attempt to write the origin of the script calling BluetoothRemoteGATTServer.connect()? This characteristic would be on the block list so that script cannot write its own value.

The problems with this are,

1. It doesn't prevent native applications from accessing the characteristic and writing any value they like, so this is not a completely trustworthy signal.
2. As with the discussion about similar a origin-locking feature for WebUSB, this allows for vendor lock-in as the device could refuse to communicate with any origin other than the manufacturer's.

[jyasskin]

I guess the vendor-lock-in argument from WebUSB gives the answer for WebBluetooth too. We should just demand that devices expect messages from websites other than their manufacturer.

[scheib]

Put another way, the responsibility to secure the communication between a domain and device from the same manufacturer is left at a higher level than Bluetooth, or Web Bluetooth. E.g. if a device manufacturer desires to have devices only accept signed firmware updates then they implement logic to validate this at a higher level. That would be agnostic to browsers and Web Bluetooth.

Nordic Device Firmware Update process is one example. I'm privately aware of another manufacturer who I believe used https://en.wikipedia.org/wiki/Advanced_Encryption_Standard for sensitive data writes.