NHS COVID-19接触追跡ベータ版が、iOS版とAndroid版の両方でオープンソース化され、ドキュメントも公開されました。「バックグラウンドで動き続ける」の記事の続報として、ソースコードを詳しく調べました。MITライセンスで公開されていることは嬉しい驚きで、NHSXが透明性と品質に取り組んでいることがうかがえます。
この2日間、複数のエンジニアがこのアプリを調べ、バックグラウンドで動作し続けられるのかどうか、そしてどのように実現しているのかを探ってきました。それを理解するには、関連するCoreBluetoothフレームワークについて、ほとんどの開発者が持っている以上に深い理解が必要でした。エンジニアが通常、深く掘り下げる必要のあるフレームワークではありません。
かなり早い段階で、Androidデバイスでの仕組みを突き止めて報告しました。今夜は、iOSで実際に何が起きているのかをお伝えします。順を追って見ていきましょう。
初回起動
初回起動時、アプリはhttps://api.svc-covid19.nhs.uk/api/devices/registrationsに対して、アクティベーションコード、プッシュ通知トークン、ユーザーが入力した郵便番号の前半部分を添えてPUTリクエストを送信します。これに対してサーバーはlinkingIdを返し、アプリの設定に保存されます。
アプリは、想定どおり、プッシュ通知とBluetoothの許可も求めます。位置情報の許可は求めないため、ユーザーの郵便番号の検証も行いません。必要なのは郵便番号の最初の数桁だけです。
Androidアプリが位置情報にアクセスしているという主張もありました。AndroidデバイスでBluetooth APIへのアクセスを求めるプロンプトが、位置情報の許可を求めているように見えるためです。しかし昨日、私たちはこれを否定しました。これは、AndroidがBluetoothの許可リクエストを管理する仕組みによるものです。
Androidでバックグラウンド動作を維持する方法
アプリがバックグラウンドでスリープしないようにすることは、Androidでは簡単です。標準のAPIがこの機能をサポートしており、エンジニアはBluetoothハードウェアに低レベルでアクセスできるからです。
しかしiOSでは、話はそれほど単純ではありません。iOSではアプリがバックグラウンドに回ると、機能が大幅に制限されます。これは、開発者にBluetoothへのアクセスを提供するAppleのフレームワークであるCoreBluetoothにも当てはまります。何らかの巧妙な回避策がない限り、バックグラウンドモードで動作しているiPhoneをアプリが検出することは、はるかに難しくなります。複数のiOSデバイスを数時間放置してテストしたところ、ポーリングの頻度は下がったものの、デバイス同士は夜通し通信を続けていることが確認できました。
Androidを使ってiPhoneを起こす
昨日は、バックグラウンドに回ったiOSアプリがBluetoothのアドバタイズを送信し続けること、ただしApple固有の別の方法で行われることも報告しました。NHSX／Pivotalのエンジニアがこれをリバースエンジニアリングし、Androidアプリにそのサポートを追加したと考えていましたが、実際にそのとおりであることを確認できました。その技術的な詳細はこちらで読めます。これが意味するのは、iOSデバイスがアプリをバックグラウンドに保てることに加えて、Androidデバイスが、バックグラウンドに回ってからどれだけ時間が経っていても、「眠っている」iOSデバイスを起こせるということです。
では、これは何を意味するのでしょうか。アプリが機能するためには、iPhoneがAndroidデバイスの通信圏内にかなりの頻度で入る必要があり、そうすることでキープアライブを受け取り、バックグラウンドに留まれるということです。それだけでは実用的な解決策にならないかもしれませんが、しかし……
iOSデバイスを使って、ほかのiOSデバイスを起こす
昨日の「バックグラウンドで動き続ける」の記事では、iOSアプリがバックグラウンド動作の制限を回避するために「キープアライブ」を使っていると思われると報告しました。iOSアプリのソースコードを調べた結果、実際にそのとおりであると結論づけました。では、それは具体的にどのように機能するのでしょうか。
簡単に言うと、この文脈でのキープアライブとは、アプリの開発者が考え出した仕組みです。アプリを実行している2台のiOSデバイスの間で送られる通知で、デバイス間の接続を維持します。興味深いのは、これによってアプリがはるかに長く起動し続けられる効果もあることです。デバイスがキープアライブを受け取ると、iOSはアプリが追加の処理を行うために起動したままでいることを許可するからです。
実用面では、これはアプリが、ほかのデバイスの近くにある限り、動作状態を維持できることを意味します。ある意味で、これがCOVID-19追跡プロジェクトの根拠でもあります。この技術的な工夫がなくても、公衆の安全で良い結果を得るには、追跡アプリを実行するユーザーが一定数以上必要になります。
それとは関係なく、アプリはバックグラウンドに回っても、すぐにスリープして一時停止状態になるわけではありません。そこで問題になるのは、ほとんどのユーザーが、こうした回避策を成り立たせるのに十分な数のiOSデバイスやAndroidデバイスの周りにいるかどうかです。私たちは、その可能性は高く、人口の多い場所に頻繁に出かけるユーザーほどそうだと見ています。Bluetoothの実効範囲はそれなりに広いのです。
一部の観察者は、アプリがサイレント通知を受信できることから、これらの機能を使って自らを遠隔で起こしていたのではないかと指摘しました。しかし、これらの機能は、COVID-19に感染した人の近くにいたかどうかをユーザーに知らせるために使われているにすぎません。アプリはまた、システムによってアプリが終了されたことを検出するローカル通知も使い、ユーザーにアプリを開き直すよう促します。ユーザーがBluetoothを無効にしたときにも、同様の通知が使われます。
ReincubateのCEO、Aidan Fitzpatrickは次のように述べています。
はい、iOS 13.5で登場するAppleの
ExposureNotificationフレームワークによって、こうしたキープアライブは不要になります。ただし、次の点には注意が必要です。
- iOS 13.5はまだリリースされておらず、数週間はリリースされない可能性がある
- 昨日までの最後のiOS 13.5ベータ版には重大なセキュリティ上の欠陥があり、Appleのエンジニアリングチームが大変な作業に追われていることがうかがえる
- リリースされたとしても、iOSユーザーの大半がインストールするまでには数か月かかる可能性が高い（珍しいことに、Androidでの同等の普及はもっと早く進むかもしれない）
- iPhone 6のような古いiOSデバイスはiOS 13を実行できず、Appleの方式を利用できない
- NHS COVID-19アプリが、将来、自動的にAppleのフレームワークの利用へ移行できない理由はありません。あるいは、両方の仕組みを並行して動かすことさえ可能です
このアプリは、使う人が増えるほど効果が高まっていき、その意味で、広く普及することの利点が好循環を生み出します。オーストラリアのCOVIDSafeアプリが苦戦したのは、AndroidデバイスからバックグラウンドのiOSデバイスを検出することに対応しておらず、また、この巧妙なiOS同士のキープアライブの仕組みも備えていなかったためです。
このような技術を使うのがどのような状況で適切なのかを考えることは重要です。接触追跡が人命を救うことに成功したなら、将来の感染症に適用するかどうかを、どのような基準で評価すべきでしょうか。ひとたび前例ができれば、この技術を既存の感染症への対策に使うべきだという議論も出てくるのでしょうか。社会によってトレードオフの評価が異なることは、十分に予想できます。
プライバシー保護の仕組み
プロトコルの背後にある数学の詳細な分析をまとめることは、この記事の範囲を少し超えますが、プライバシー保護の仕組みについては確認しました。アプリは、NCSCが公開した論文に厳密に従っているようです。ユーザーが症状を報告するまで、鍵データがユーザーのデバイスの外に出ることはなく、報告した場合にのみ、近距離にいたデバイスの匿名化された鍵がデバイスから送信されることを確認できました。ユーザーが入力した郵便番号の前半部分は、登録サービスの一環としてAPIに送信されます。
結局のところ、コードからは、ユーザーが症状を報告してNHSに連絡し検査を手配するときまでは、このアプリの利用に伴う技術的なプライバシーリスクはほとんどないことがうかがえます。その時点以降、検査結果はNHSによって管理されますが、これはアプリの有無にかかわらず変わりません。しかし、複数のユーザーが接触し、症状を報告し、さらにアプリが提供した識別子を使って検査を手配した場合、それらを中央で結びつけられるかどうかは分かりません。それはバックエンドの問題であり、NHSXがアプリのプライバシーレポートで述べているとおり、この点ではコードこそが真実です。
虚偽の報告への対策
システムのバックエンドはオープンソース化されていないため確認はできませんが、市民がCOVID-19の検査で陽性となるまで、ほかのデバイスにプッシュ通知は送信されないようです。ユーザーが症状を報告すると、検査の予約に使える参照コードが発行されます。（このコードは、登録のセクションで説明したlinkingIdと同じものです。）
