Google has been promoting the inclusion of peripheral connectivity using Bluetooth and USB on web browsers for several years. Yet, it's meeting heavy resistance from other browser vendors such as Apple and Mozilla.
While Chrome supports Web Bluetooth since 2016 and Web USB since 2017, no other vendor has concrete plans for supporting these technologies, putting the future of these Web APIs under question.
Adam Roach, a principal engineer at Mozilla and a core contributor to Firefox, gave an excellent explanation to Mozilla's stance on these API's:
"The basic answer is that the web platform has always had to do not just better than native apps, but much better, because of the way that users conceptualize 'installing apps' versus 'browsing the web.' To the extent that the majority of users understand security practices, it's pretty well-known that installing a malicious app can have arbitrarily catastrophic results. At the same time, it is our job to make sure that visiting malicious websites is as safe as we can reasonably make it, because browsing the web cannot become as inherently risky as constantly installing a series of potentially malicious apps from every site you visit."
To ensure a relatively secure browsing experience, browsers sandbox websites - providing only limited access to the rest of the computer and even other websites that are open on different tabs/windows.
What differentiates Web Bluetooth/USB APIs to other Web APIs such as the MediaStream or Geolocation that received wide adaptation from all browser vendors is the specificity which they offer.
When a user enters a website that uses the Geolocation API, the browser shows a pop-up requesting permission to access the current position.
While approving this request can pose a security risk, the user makes a conscious decision to provide his or her location to the website. At the same time, the browser exposes a set of specific API calls (such as getCurrentPosition) that does exactly that.
On the other hand, Bluetooth and USB communication work on a lower level, making it difficult to discern which actions are being performed by the website. For example, Web Bluetooth communicating with a device happens using the writeValue that accepts arbitrary data and can cause any number of actions on the target device.
This also means that browsers can't highlight the dangers that connecting to a Bluetooth device may present to the user. For example, asking the user approval for communicating with a Bluetooth keyboard doesn't just mean that the website could ready from the keyboard - it means it could also type commands, which are not only limited to the specific website and could result in a malicious attacker gaining much broader access to the computer that was ever intended.
The current disagreement between Google and the remaining browser vendors has dampened the adaptation of these APIs. Yet, the ever-growing reliance on JavaScript and web browsers means that a variation of these APIs is bound to gain wide adoption; the only question that remains is when.