オルタナティブ・ブログ > 路の上で >

日頃考えていることをぽちぽち書きます。

続き: AppleとGoogleのPrivacy-Preserving Contact Tracingの気になる点

»

先週の続きです。

まず、先週に疑問に思った「感染した人が正しく入れる保証はない」について。以下ITmedia記事に答えがありました。これも佐藤由紀子さんの記事ですね。
AppleとGoogleの「新型コロナ感染者と接触したかも」通知がフェイク申告を防ぐ方法は?
気づかなかったのが愚かでしたが、AndroidやiOSの問題ではなく、当局のアプリ側の問題でした。ここでは例として、当局が医師に配布するQRコードを読ませて虚偽申告できないようにする、ことが書かれています。

さて、これらAPI以前に、日本でもアプリ開発が進んでいるそうです。
コンタクト・トレーシング・アプリの開発に関して

元になっているのはシンガポールのTraceTogether
Bluetoothで近接情報を残し、感染者が発生した場合に、その人の近傍にいた履歴を持つ人に連絡することになっています。ところが、最初のビデオを見ても、どう連絡するのかはわかりません。電話番号は取得されることになっているので、電話連絡するとは想像できますが。

そこで、White Paperを読んだところ、以下の仕組みでした。

  • ユーザーは登録時に端末の電話番号を当局に渡す
  • 当局は電話番号に対してユーザーIDを生成する
  • 当局は、User IDを含み共通鍵で暗号化したTempIDを生成
  • ユーザーのスマホにTempIDを複数ダウンロードし、アプリが適宜切り替えて使用(TempIDをBluetoothで告知、相手はそれを記録)
  • 感染がわかった場合、スマホから受信したTempIDをアップロード

なるほど、TempIDにユーザーIDを含み、ユーザーIDから電話番号を求められます。つまり、ほとんどすべての処理をスマホ側で実行するApple-Googleの仕組みと違い、当局にかなりの情報が渡ります。

ところで、iOSのTraceTogetherアプリは、iOSの仕組み上、常に表に出しておく必要があるようです。そのため、評価が二分されてます。確かにそれでは現実的に使い物にならず、僕も使わないことは間違いありません。5月に出るAPIでは、アプリが通信を担う必要はなくなるので、このような問題はなくなるはずです。

Comment(0)

コメント

コメントを投稿する