Re: [web-bluetooth] Service Worker support for WebBluetooth (#422)

**TL;DR: Web Bluetooth support in service workers is complicated and has many questions that need to be answered before it can be considered. Discussion on these questions is welcome to generate ideas for how to address them.**

There are some questions that need to be answered before Web Bluetooth support is able to be considered in service workers. These are just some that that pop into my head at the moment:
1. How should permissions look for Web Bluetooth in service workers?
2. Should all Bluetooth devices be allowed in a service worker context?
3. How should users be notified when a Bluetooth device is being accessed in the background?
4. Does having a connection to a GATT server count as not being idle, or only when I/O operations are occurring?

I do have some ideas to address or partially address some of these questions. It would be great to hear any thoughts on these or other ideas or questions that should be asked.

1. Allowing site to be able to access hardware in the background without the user's knowledge has some security and privacy concerns. A malicious site can either flash a device at any time, track a user's location by detecting whether paired devices are in range or not, or just read sensitive information, such as heart rate data in the background. There are two ideas that I have to address some of these concerns. The first is to gate background access behind a permission to allow background access that is in addition to the permission to connect to a device. This would be a signal from the user that they trust the site to communicate with the device. The second is to only allow background access in installed PWAs, as the user has to explicitly install the PWA themselves. It can even be combined with the first idea and only allow background access after the user as explicitly granted background access permission. This would provide two gates, so a user is less likely to be tricked by a malicious site.

2. There are devices where it doesn't make sense for background access to be given, such as piloting a drone. The question is, how can we detect whether a device should be allowed or not, or is it OK to allow all and let the user decide which devices can be accessed in the background via the permission prompts.

3. Users can be notified with a notification pop up when a device is being connected, but that could potentially become spammy and annoying to users if it occurs very frequently. A more subtle approach can be taken, such as a taskbar indicator or an indicator on the browser window, but then this can be easy to miss.

4. It makes sense to keep the service worker active when a device is actively connected. A malicious site could take advantage of this and open up a connection to do unrelated work in the background forever, like bitcoin mining for example. Even if there is a timeout implemented, sites could use the timeout period to perform unrelated computations. It also makes sense to keep the service worker active when I/O operations are being performed, but a malicious site can still perform dummy operations to do other work in the background.

Again, these are just some ideas that I have to address some of these concerns, and I welcome any other thoughts on them. Most of these questions also apply to WebUSB, Web Serial, and WebHID support in service workers.

-- 
GitHub Notification of comment by odejesush
Please view or discuss this issue at https://github.com/WebBluetoothCG/web-bluetooth/issues/422#issuecomment-555638774 using your GitHub account

Received on Tuesday, 19 November 2019 18:18:39 UTC