Googleは数年前から、BluetoothおよびUSBを使用した周辺機器接続をWebブラウザに導入しようとしているが、AppleやMozillaなど、他のブラウザベンダからの強い抵抗にあっている。
ChromeはWeb Bluetoothを2016年から、Web USBを2017年から、それぞれサポートしているが、他のベンダはこれらのテクノロジをサポートする明確なプランを持っておらず、これらWeb APIの将来性に疑問を投げかける結果となっている。
Mozillaのエンジニアで、Firefoxの中心的コントリビュータであるAdam Roach氏が、これらのAPIに対するMozillaのスタンスを明確に説明している。
"基本的な答として、ユーザが‘アプリのインストール’と‘Webのブラウズ’とを対比的に概念化している以上、Webプラットフォームは常に、ネイティブアプリ‘よりもよい(just better)’だけではなく、‘はるかに優れている(much better)’ものでなければなりません。ユーザの大多数がセキュリティプラクティスを理解している限りにおいて、悪意のあるアプリをインストールすることが、いつでも最悪の結果をもたらし得るものであるということは、広く知られている事実です。それと同時に、悪意のあるWebサイトへのアクセスを、合理的に可能な限り安全なものにするのは私たちの仕事です。ブラウズする全サイトから、悪意を持っているかも知れないアプリを絶えずインストールすることほど、Webブラウズを本質的に危険な行為にするものは他にないからです。"
比較的安全なブラウジングエクスペリエンスを確保するため、ブラウザはWebサイトをサンドボックス化、すなわちコンピュータの他の部分へのアクセスや、さらにはタブやウィンドウを新たに開く他のWebサイトへのアクセスを制限している。
すべてのブラウザベンダに広く支持されているMediaStreamやGeolocationといった他のWeb APIとWeb Bluetooth/USB APIが違うのは、それらが提供するものの特異性にある。
Geolocation APIを使用しているWebサイトにユーザが入ると、ブラウザは、現在の位置情報へのアクセス許可を要求するポップアップを表示する。
要求の承認にはセキュリティリスクが伴うので、自身のロケーションをWebサイトに提供するかどうかはユーザが意識的に判断する。同時にブラウザは、それを正確に行う具体的なAPIコール(getCurrentPositionなど)のセットを公開する。
これに対してBluetoothやUSB通信は、より低レベルで動作するため、Webサイトがどのようなアクションを実行するのかを識別することが難しくなる。例えばデバイスと通信するWeb Bluetoothは、任意のデータを指定可能な"writeValue"を使うことで、ターゲットデバイスにあらゆるアクションを起こさせることが可能である。
これは同時に、Bluetoothデバイスに接続することによってユーザが受ける可能性のある危険性を、ブラウザからは特定できない、ということでもあるのだ。例えば、Bluetoothキーボードとの通信のユーザ通信を求めるということは、Webサイトがキーボードから受信可能になるという意味には留まらない — つまり、コマンド入力も可能になるのだ。これによって、悪意を持った攻撃者は、特定のWebサイトに限定されることなく、ユーザが意図したよりもはるかに広い範囲でコンピュータにアクセスできるようになる。
Googleと他のブラウザベンダとの意見が対立しているため、これらのAPIの採用は足止め状態にある。そうではあっても、JavaScriptとWebブラウザへの依存がかつてないほど高まっていることから、最終的にはこれらAPIのバリエーションが広く採用されると思われる。残る問題は、それがいつになるのか、ということだ。