Service Worker support for WebBluetooth

[hardillb]

An issue to track the adding ServiceWorker support to WebBluetooth.

Things to think about:

• Could/Should this allow persistent connections to devices e.g. a User initiates connection to a device on phone/laptop, the bluetoothDevice object is passed to the ServiceWorker. The phone/laptop goes out of range, comes back later, can the ServiceWorker reconnect in the background?
  -Should it ask permission again every time or just once with option to allow again until revoked?

[beaufortfrancois]

@reillyeon @dougt for thoughts.

[PavelCibulka]

Hi that would be nice. We use website as store application and connect barcode scanners as keyboard right now.

We are experimenting with WebBluetooth on barcode scanner and weight scales (for parcels). Problem is that you have to reconnect device each page refresh / GET / POST.

Each employee has his tablet and scanner. I think service worker with persistent bluetooth connections would really help.

[reillyeon]

@PavelCibulka as an interim step Chrome is working on implementing support for retaining access to a device across navigations. That is still not quite as convenient as moving the connection management into a Service Worker but should help resolve the issue you are having. Follow along on issue 577953 for progress.

[thegecko]

Could they also look at implementing referringDevice to close the loop on eddystone beacons connecting a user to a web-based UI?

[gfwilliams]

Just to add my thoughts to this - I'm currently working on a hackable smartwatch - allowing users to keep a connection open in the background and communicate with their device would be a huge benefit.

[odejesush]

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.

[antonbasic]

I have a use case for being able to update my BT device over BT while it's not in active use. This would also be perfect to do in a service worker.

In terms of how this should be done. I think there are quite good practice to be found on phones already. You get an initial question of whether or not you want to give the permission. Then after a while you get a notification that says that the app has been using your BT/GPS/whatever behind the scenes and whether or not you want to keep allowing that. From that point on ( I guess with some time limit ) you won't be bugged with notifications.

[ggl-tommy-fritz]

We have a use case where the users device is used to open a door from a wall mounted reader via bluetooth. In this case, close proximity is required for background usage.

Perhaps close proximity is a reasonable security requirement for background usage, if that's even feasible?

[nuxodin]

It would be great, you could realize a (COVID-19) "contact tracing" app as a webapp.

[scheib]

Technically, it would be very interesting if we could do so given the API capabilities and other applications. There would be significant privacy concerns to work through first. This isn't a near term goal.

Practically, to address the pandemic, it is more appropriate to have operating systems offer this service in a power and privacy efficient way. There is work underway to do this: https://www.blog.google/inside-google/company-announcements/apple-and-google-partner-covid-19-contact-tracing-technology/

[eduardhasanaj]

Is there any progress in this feature?
We have a case where a background script of an extension requires a persistent Bluetooth connection for exchanging sensitive data locally.
I understand that there are many security concerns but cannot extension reviewers increase the review time(also costs) for such functionalities?

[mtom55]

So imagine the scenario, where delivery orders are sent in and you have to print order labels to a bluetooth thermal printer.

The situations I am considering are:

1. If the user has switched apps, being able to receive a packet either by fetch or some server push mechanism, then render an image (canvas toDataURL) convert that into the printers format and then send that via bluetooth

2. being able to start that process up in the background even if the OS has decided to suspend the app

(real scenario is a little bit more complex involving multiple devices, multiple receipt printers and a label printer)

[reillyeon]

Working within the current limitations I would recommend using the push notification to alert the user that they need to switch back to the application in order to print a new receipt. I recognize this isn't ideal.

[sleien]

We have another use case.

We only need to know which BT devices are near. No connection is needed. Our goal is to start macros if specific IDs are close by.

[mtom55]

I'd like to expand on the scenario above, as I think it's a good explanation about scenarios that Web-Bluetooth can't solve which native APIs can.

Scenario
In each shop we have a POS terminal (either an ipad or an Android tablet) with a POS software running as a PWA.

There are two (or more) printers:

1. A Label Printer
2. A Thermal Receipt Printer

Association
The ideal situation in the PWA is to setup and associate the PWA with each of the devices ONCE, and then have them continue to work. It becomes less ideal the more times the user has to go through the association process.

Printing
When an order is placed on the system, labels are printed using the label printer so they can be stuck on the box and a receipt is printed on the thermal printer. In this case the PWA is active and can just use web-bluetooth as normal as long as both devices are connected.

Online Order
Online orders are received through the server, while the application is running it's possible to open a web-socket connection to receive the online order and then immediately print both a label and a receipt when one is received. The issue is when the application is not active as the staff often need to switch to other apps.

The ideal solution would be to use PUSH API to wake a service worker, which can immediately connect to the bluetooth printers and print. This way if the device is idle or a user is using another application the printing process can continue uninterrupted.

Note that this entire process is possible within native apps, but is not possible on web-bluetooth. I realize there are possible privacy/security concerns, but I think a good general stance is if you can do it on native, you should be able to do it on the web. If the privacy/security risks are too big to be mitigated by any process then that functionality should also be removed from native.

[altjz]

I can't understand why Worker doesn't support WebBluetooth.

I saw Worker supports WebSerial.

WorkerNavigator.serial

I have a web app need to access my company's product.

The web app is able to access my device with WebSerial in worker, but it can't do the same thing with WebBle in worker. Wired!!

[reillyeon]

@altjz, I've filed #571 to track Worker support separately from Service Worker support.

[foxt]

It'd be nice to have a way to bypass the slowing/pausing of unfocused tab. If you have a bluetooth device that say, needs data read/written to every 100ms, there might be an issue if the user goes away to look at something else.

[KOLANICH]

I'm absolutely against of Service Workers (which means malware persistence and background activation), and I'm especially against of allowing Service Workers to access Bluetooth, USB, MIDI and so on. Without proper explicit user-vetting of every action with such dangerous APIs they can hecome a privacy and security threat. User-vetting of every action by a service worker (and of every event sent to the service worker by browser!) defeats the purpose of Service Workers. And don't tell me that modern users won't install malware if they are told "install malware or go away from my website" by a powerful and essential website.

[PavelCibulka]

I'm absolutely against of Service Workers

You have to considere, that websites are replacing most of the classical EXE applications. So web browset need service workers for manage label printers, barcode scanners, scales etc.

[foxt]

@KOLANICH I feel like service worker access is definately tricky. I feel like dedicated Worker access, which runs in the "background" but belongs to a specific document.

slightly OT but, the entire browser security model is tricky, vendors try their best to lock off functionality (mostly for security, sometimes not), but you end up in a weird situation where sometimes users can't upload files from their cloud drive, but you can download ransomware with two clicks.

[KOLANICH]

offtop

@foxt I think the most of the problems with browsers is that

1. they expose too dangerous APIs to be exposed at all. Examples are WASM, WebGL, WebGPU, WebUSB, WebBluetooth, Service Workers, and so on
2. they often without proper user-vetting. An example is getBoundingClientRect and API to get and measure time.
3. they try to expose generic APIs that can be easily and efficiently repurposed for malicious purposes instead of presenting narrow domain-specific APIs efficient and easy-to-use for solving a certain task without using any 3rd party libs at all and maybe even without JS, but unusable for anything else. For example instead of generic WebGPU there should be 4 distinct APIs: a) 3D rendering API (including raytracing, but without any custom shaders) b) physics engine API c) machine learning model inference API d) Proof-of-Work API. This way it is possible to cover almost all the needs of users of GPU, but without allowing low-level attacks like GLitch. Of course it means that browser vendors would have to design a set of APIs for them the way allowing to plug any existing 3rd party lib (game engine, physics engine, machine learning inference framework like onnxruntime, impls of PoW) under such API, but the benefits outweight. Not needing to force devs to bring themselves a lot of inefficient JS and WASM code, having a single engine with single API, built-in into browser, compiled into optimized native code reusing existihg shared libs in system (this way lowering memory consumption), are not bugs, but important features. If a new important use case emerges, there will be native libs for it that could be wrapped into new sets of APIs.

So I think that it may be optimal for WebBluetooth not to provide a generic API but concentrate on certain widespread use cases that cannot be abused, and leave everything else to native apps.

@PavelCibulka

websites are replacing most of the classical EXE applications

It is impossible to do it fully and it is inefficient to do it in the most of cases. In fact the trend is AOT-compilation of code that used to be JIT-compiled (.Net, JVM, WASM, ONNX, QML). I expect eventually people will choose the more efficient solution, and HTML + JS is damn inefficient for the purposes of GUI, for example syntax highlighting using HTML eats damn a lot of memory and it is unfixable in principle, the only alternative to it is to bring an own text rendering. There is no reason to reinvent a wheel, other than the desire to bring that into browser. IMHO it'd make more sense to make an HTML element adding a native source code editor area (maybe with some control on syntax highlighting via loadable specifications of syntax and some IDE-like features with LSP (with same-origin policy) ) into browsers and not to try repurpose HTML for that. And some thjngs shouldn't be done in browser at all, like rendering rich text documents like doc, docx and odf. PDF - it has already become a part of a browser, but the main feature of pdf.js is that it is written in a memory-safe language. Impls in Java, .Net or Rust should do the job of rendering pdf better.

[PavelCibulka]

@KOLANICH
It is working well for us. HTML + JS fine for priting label on label printer or scanening barcode from goods. There is no need for efficiency.

What is important is maintenance. It is more efficient to mantain single website than update software on 1000+ devices. Also website development is much faster than EXE development.

[KOLANICH]

offtop

EXE development
update software on 1000+ devices

Windows is a pretty uniform platform. For software distribution one can use https://learn.microsoft.com/en-us/windows/package-manager/ .
For other systems there are also package managers and software should be distributed through repos for them.

I admit that using browsers is an easy way for onboarding new users because one can put a link to the webapp into a webpage. But for anything more serious than just a demo standalone apps are more optimal.

[foxt]

OT

@KOLANICH If Windows was such a unified platform with easy software distribution (would you like my laughter in .msi, NSIS, InnoSetup, WiX .exe, Squirrel, bespoke .exe installer, AppX, AppV, MSIX, XAP, MSStore, ClickOnce, .cab file, or portable .zip format) there'd be no need for an entire industry of products that exist soely to take the applications you have and run them on the infrastructure you have.

Making a web app for certain devices IMHO, the future and how everything should be. It's so much easier to just send a link to a webpage that updates every time you refresh. Plus, web pages are much more isolated, (i.e. a badly made installer cant munge the registry), and there's no residual files when you uninstall an app.

Also, if it works in a web browser, it works on Windows, Mac, Android, ChromeOS, etc. You don't have to haul an old PC out of storage because the manufacturer only shipped an EXE that only works on Windows 7.

Everyone else on the email thread can accept my sincere apologies.

[reillyeon]

Please stay on topic. To answer the original question:

It'd be nice to have a way to bypass the slowing/pausing of unfocused tab. If you have a bluetooth device that say, needs data read/written to every 100ms, there might be an issue if the user goes away to look at something else.

Not throttling pages with active Bluetooth connections is tracked in a Chromium issue and is relatively straightforward to implement, as we recently made a similar change for active serial connections.