[iOS] 接触チェックに表示される「一致したキーの数」が積算される事象を調査する #961
Comments
LastProcessTekTimestampでフィルタリングに異常が起きている可能性COCOA起因でこの事象が発生する可能性としては、そのまま「同じ診断キーファイルを何度も接触確認している」というものがある。 最初の接触確認の時に診断キーファイルA, B, Cがあったとして、次の接触確認の時にB, C, D, E（Aは削除）という状態であった場合を考える。 仮に2回目の接触確認でB, C, D, Eを処理すると、Androidの接触通知APIは処理済みのB, Cについては内部で除外した状態で処理するが、iOSの接触通知APIは、指定した処理済みのファイルについても再度接触確認をする仕様になっている。 そのためCOCOAは、内部で この機能が正常に動作していなければ、iOS版のCOCOAで同じ診断キーファイルを何度も接触確認を実行して「一致したキーの数」が減らないという現象が起こりえる。 検証この可能性を検証するために、v2.0.0のiOS版をインストールして接触確認が実行されるのを待ち動作ログを取得した。 1回目の接触確認初回のインストールでは、その時点でサーバーにあるすべての診断キーファイルをダウンロードする。 初回の接触確認"2022/04/07 13:40:30","Info","URL https://covid19radar-jpn-prod.azureedge.net/c19r/440/8762.zip have been downloaded.","InternalExposureDetectionAsync","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/AbsExposureDetectionBackgroundService.cs","143","iOS","14.7.1","iPhone8,4","Physical","2.0.0","1648613456" また、初回起動なのでLastProcessTekTimestampの値は0となっている。 接触確認が完了したタイミングでLastProcessTekTimestampには 2回目の接触確認続いて14:03頃に、これはCOCOAを起動したことに起因する接触確認が実行されている。 3回目の接触確認次に接触確認が実行されるのが17:40頃で、ここでもLastProcessTekTimestampの値は このタイミングでは新しい診断キーがあるので、 ダウンロードした診断キー"2022/04/07 17:40:56","Info","URL https://covid19radar-jpn-prod.azureedge.net/c19r/440/9179.zip have been downloaded.","InternalExposureDetectionAsync","/Users/runner/work/1/s/Covid19Radar/Covid19Radar/Services/AbsExposureDetectionBackgroundService.cs","143","iOS","14.7.1","iPhone8,4","Physical","2.0.0","1648613456" すでに接触確認済みのファイルはダウンロードされていないことがわかる。 結論以上のことから、LastProcessTekTimestampによるフィルタリングは正常に行われているものと考える。 |
ファイルシステムに過去にダウンロードした診断キーファイルが残っている可能性LastProcessTekTimestampによるフィルタリングが正常でも、過去にダウンロードした診断キーファイルが残っていることで重複して接触確認が行われている可能性を考える。 COCOAの接触確認はダウンロードした診断キーファイルのみ行うので、仮に診断キーファイルが削除できていなくても、次の接触確認に与えられることはないと考える。 また、接触チェックの記録を書き出して見ても、 ExposureChecks-2022-04-07.json.txt 接触確認を行ったキーファイル情報
以上のことから、過去にダウンロードした診断キーファイルが残っていることで一度処理した診断キーを重複して処理している可能性は除外できるものと考える。 |
keiji
changed the title
検証Chino.Prismを使ってiOSで「一致したキーの数が積算されるか」検証した。 Chino.PrismについてChino.PrismはCOCOA2で使用しているライブラリ「Cappuccino」を使ってPrismアプリケーションを実装するために作成した習作のアプリで、接触通知（EN）APIの有効化、TemporaryExposureKey（TEK）の取得、実験用サーバーにTEKをアップロード、実験用サーバーから診断キーをダウンロード、ダウンロードした診断キーで接触確認といったENの実装に必要な基本的な機能をCOCOAを使わずに実行する。
Chino.Prismとen-calibration-serverのソースコードは次のリンクから確認できる。
使用した端末について検証には、実験用に用意しているiOS端末（以後、「端末A」という）とAndroid端末（以後、「端末G」という）を使用した。 16:27 一致するキーの数が0件であることを確認する端末Aで、端末に保管されている診断キー（正確にはTEK）を実験用サーバーにアップロードした。 次に実験用サーバー側で診断キーを生成したものを端末Aからダウンロード、接触確認を行ったところ「一致するキーの数」は0となった。 これは自身の生成したTemporaryExposureKeyは接触と見なされないため、期待した動作となる。
アプリの内部ストレージをクリアするため、端末BからChino.Prismをアンインストール、再インストールした（少しの間であればインストールしてもENが保管しているデータは消えない）。 16:34 一致するキーの数が1件以上の状態になることを確認する端末Gで、端末に保管されていTEKを実験用サーバーにアップロードした。 実験用サーバー側で診断キーを生成した後、端末Aでダウンロードして再び接触確認を行ったところ「一致したキーの数」が
アプリの内部ストレージをクリアするため、端末BからChino.Prismをアンインストール、再インストールした。 16:36 一致していないキーで接触確認して一致するキーの数の変化を確認する実験用サーバーから端末Gの診断キーファイル（ 次に、端末Aで診断キーをダウンロード、接触確認を行ったところ「一致するキーの数」は9となった。
結論以上のことから、iOSで表示される「一致したキーの数」は、詳細に示される接触確認（接触チェック）についての値ではなく、これまで行った接触チェックで一致したキーの積算で表示されていると考える。 |
|
様々なご検証をありがとうございます。 ExposureNotification API 2, ExposureWindow mode, EN2 いままでのEN1では、同一の端末との例えば40分の接触でも、提供キーの数は1だった可能性があり（日次キー単位）、 それとは別に、累計していく振る舞いは、EN2では複数の接触の時間を合計するので、例えば接触日が10日について、Aさんとの接触が12日に配信され、Bさんとの接触が14日に配信されると、14日の照合で12日の接触分も合計して1つの接触時間にするかと思います。提供キー数もそれにつられて累積していくのかなと想像しました。 あまり、解析できてなくてすみません。たとえば10分間の接触と、20分間の接触の比較や、同一接触日の複数端末について別日の陽性登録・配信などのテストが考えられるでしょうか。 |
ENv1もENv2も、日時キーの有効期間は24時間なので、接触時間にかかわらず「一致するキーの数」は1となると理解しています。 基本的には一致しないことが確定している診断キーでも接触確認しても結果が9となったので、積算という事象はほぼ確定で、それがENv2の仕様によるものかは（個人的には仕様の蓋然性が高いと考えていますが）、現時点では確定していないという状態ですね。 |
|
一致したキーが積算されていくと言う推測は間違いなさそうと言う事ですね。 本件課題からは少しズレるかも知れませんが、積算される期間が決まっているのか（あるいは無いのか）は気になる所です。
ざっくり思いつくのはこの３つぐらいですが、どれも特に根拠の無い推測です。 |
|
手元のiPhoneでは、一致したキーの個数が一度でたら、基本的に数日間は出続ける（例のhash一覧サイトから推定される接触日から10日間たつまで出続ける）ので、「過去も含めた、当日に接触通知をだすべきキーの個数」だと思っていました。 |
|
最初のカウントアップ（2022-03-30 15:38）から2週間たった時点（2022-04-14 04:58）でも減少しないようです＞一致したキーの数。
|
|
私の手元でのカウント件数推移記録を掘りおこしてみましたが、カウントされたのが20日ぐらい出続けている記録もありました。クローズドβ版で接触日が見える端末での挙動で、接触日から26日間出続けていました。内部的なキャッシュかなにかなのかな… |
|
直感的には15日前の記録は消えていて欲しいですよね。
こちらは現在も記録更新中でしょうか。「26日出続けたけど消えた」のか「今も出ているのか」を知りたいなと。 |
|
26日目で消えました。（正確には、最初の接触日とは別の接触があったため、カウントが減りましたが、別の接触もふくめて30日後には0件まで戻りました） |
|
突然の減少。昨日の午後に1，今朝は0になりました。
|
|
こちらiOSでは積算になるという結果を頂いていること。また、COCOA v2.0.1で接触情報の保存機能が追加されて代替機能が用意されたことからCloseします。 何かあればreopenするのでコメントください。 |
内容 / Describe
オープンβ中のDiscussionより、
#921 (reply in thread)
本来であれば「一致したキーの数」は、そのとき実行された接触確認処理（detectExposure）で一致したキーの数を表す。実際、COCOA v1.4.1ではそのように表示されていた。
しかし、COCOA v2.0.0にした後は、一致したキーの数が減らず、積算して表示されているように見える。
再現手順 / Steps to reproduce
期待される挙動 / Expected behavior
一致するキーがない接触チェックでは「一致したキーの数」は0件で表示される。
スクリーンショット / Screenshots
動作環境 / Environments
その他 / Additional context
このIssueでは、COCOA v2.0.0の動作に問題があるのか。ないのかを明確にする（調査する）目的に限定する。
本来であれば接触チェックの画面はCOCOAの分掌外。たとえばJSONにMatchCountが含まれないのもCOCOAがそう設定したわけではない。
「一致したキーの数」が積算されるのも仕様であるならどうしようもない（MatchCountについて代替案を検討中 #928 ）。
The text was updated successfully, but these errors were encountered: