As you might expect, there are security risks here. When deciding whether to ship the new API, we should look at several kinds of attackers and defenders:
- An abusive software developer, trying to do embarrassing or privacy-insensitive things that don’t go outside devices’ security models.
- A malicious software developer, trying to exploit users using nearby Bluetooth devices.
- A malicious hardware manufacturer, trying to exploit users or websites who connect to their devices.
- A malicious manufacturer/developer, who can push cooperating hardware and software.
- Weakly-written device firmware, which doesn’t intend to hurt its users, but might be vulnerable to malicious connections.
- Weakly-written kernels, which might be vulnerable to either malicious userland software or malicious connections.
The ultimate decision about whether to ship Web Bluetooth should also take the competitiveness of the web into account, but this article only analyzes the security tradeoffs.
Abusive software developers
Abusive websites might try to do embarrassing things like configure a Bluetooth speaker to play porn sounds. Web Bluetooth defends against this in several ways:
- The chooser grants a website access to only the specific devices a user selects, which helps the user associate misbehavior with specific sites and prevents those sites from messing with extra devices.
- On desktop platforms we show a tab indicator while a site is connected to a device, which also helps associate the site with the misbehaving device. This isn’t perfect, since the site might configure a device to only misbehave later, long after the site has disconnected to stop showing the tab indicator.
- If users notice misbehavior and revoke a site’s access to a device, we’re looking into ways to aggregate that in a privacy-preserving way and use it to protect other users from that site, either by automatically denying the chooser or by adding an extra warning that the site might be abusive.
For more detail: The Web Bluetooth Security Model