Chrome最新版でWeb Bluetooth APIが使えるようになり、実際に動かしてみました。コードを書いたり関連したドキュメントを読むにあたって、気になった箇所をまとめておきます。
なぜWeb Bluetooth APIを作ったのか
Until now, the ability to interact with bluetooth devices has been possible only for native apps. The Web Bluetooth API aims to change this and brings it to web browsers as well.
Interact with Bluetooth devices on the Web By François Beaufort
BLEに限らず、端末の各種ハードウェアを動かすにはネイティブアプリからでないと無理だった。Webアプリでもネイティブアプリがやっていることを実現できるようにしようとするのがこのAPIの目的です。WebGLやWeb Audioの流れと、これからUSBやシリアル通信を実装しようとしている未来を考えれば、まあ実装するよねという感じがします。ブラウザがOSになろうとしていた時期の計画と野望を、着々と進めているんだなという印象です。
なぜ動作に制限が多いのか
コードを動作させるにあたって、(いま私が認識しているだけで)下記の制限があります。
- HTTPでは動作しない(localhostを除く)。HTTPSやfile://では動作する。
- クリック等のユーザーからのアクションがないと開始できない。onloadなどで自動的に開始するのは不可。
- 一部接続しないサービスが定義されている
HTTPでは動作しない
localhostを除き、HTTP接続ではnavigator.bluetooth.requestDevice()を実行してもerrorとなります。HTTPでも許可されるのはlocalhostのみで、プライベートIPアドレスでもHTTPならerrorです。
これは、Web Bluetoothに限った話ではありません。ブラウザの強力な機能を使う際には、少なくともそのサーバの出処がはっきりしているものだけに制限しておきましょうというもので、"Secure Origins"と呼ばれています。
ユーザーからのアクションがないと開始できない
確実にユーザーの意思によって動作させる必要があります。ページ読み込みと同時にバックグラウンドで勝手に動かすのは不可です。たとえば、もしユーザーがBLEで座標を飛ばせるGPS受信機(こういうものはLocation and Navigation Serviceを使って飛ばしていると考えられます)を使っていたら、バックグラウンドでユーザーがどこにいるのかが結構な精度で取得されることも考えられます。
一部接続しないサービスが定義されている
キーボードやDFU等の特に扱いが敏感なサービスについては、そもそもAPIからブロックされています。ブロックリストはこちら。ちょっとした理由も含めて記載されています。
どのような場面で使うのがよいのか
スマホアプリの代用とした使い方がいいのかなと思います。ちょっとした機能としてのみ使うときに、わざわざ専用アプリをストアからインストールしてもらう必要がなくなります。特定の施設内に対応したビーコンを使うためとか、Amazon Dash Buttonのようなデバイスの接続設定を書き込むためとか、そのくらいの用途のためにわざわざアプリをインストールするとなると、面倒くさいからいいわとなるのを防げそうとは考えられます。
一方で、この「専用アプリをストアからインストールしない」が、そのまま脆弱性につながるように思います。どのサービス・キャラクタリスティックに接続しているかは、Webページが何もしなければ特に明示されません。ユーザーにきちんと明示しておくようと記載されています。
参考文献
