接触通知を発生させるリスクスコアの閾値を変更しやすくする

[daisuke-nogami]

その機能リクエストは何らかの問題に関連しますか / Is your feature request related to a problem?

Exposure Notification v2では、接触通知を出すかどうかはアプリケーション側に処理が委ねられており、
基本的にはENが返すリスクスコアが一定の閾値を超えたときに接触通知を出す。

現在のCOCOA2では、ENの設定はサーバ側から配信しているが、閾値の設定だけはコードに埋め込まれている（はず）ため、アプリ再配信をせずに閾値を変更するには、設定値をサーバ側で設定できるようにする必要がある。

参考 :
#605 (comment)_

解決策についてお書きください / Describe the solution you'd like

scoreSumの閾値を、configuration.jsonないしそれに相当するファイルで設定する。

あなたが考える代替案についてご説明ください / Describe alternatives you've considered

アプリのソースコード内で定義してバージョンアップのたびに更新する。

その他 / Additional context

今後、Exposure Windowのデータを元にした閾値も増設しうるので、閾値設定ファイルの書式の拡張は視野に入れた方がよい？

• 想定しうる閾値の種類
  • リスクスコア (scoreSum)
  • WeightdDurationSum / (SecondsSinceLastScanの合計値) … かかったWeightの平均値
  • (SecondsSinceLastScanの合計値) … 純粋な接触時間の合計値
  • TypicalAttenuationDbの最大値・最小値 … 電波強度に閾値を設ける場合

ただし、これらを組み合わせすぎると判定条件が複雑になるので、初期リリースでは入れる必要はない。

[keiji]

configuration.jsonに入れようかとも思ったのですが、性質的には分けた方が良い気がするので、threashold.jsonのようなものを作りましょうか（実際にJSON形式を採用するかは要検討）。

こういうファイルを作るときに一番頭が痛いのは対応するオペレーションと数値の書式ですね。
今回は「以上、以下、等しい」くらいがあればいいかなと思いますが、なんにせよ設定ファイルの書式にバージョンの概念を持たせておくのが良さそうです。

[daisuke-nogami]

ありがとうございます。別の理由（後述）から、（閾値の種類は増やす必要はないですが）リスクスコアの範囲によって、通知で表示するメッセージを一部変更する必要が生じうるため、その点からも別ファイルに分けた方がよさそうです。

• リスクスコアの閾値
• プッシュ通知を出す要否
• 検査を促す理由を示す文字列

の組み合わせを複数設定し、閾値が大きいものから順に判定するようなイメージです。

後述：「濃厚接触者にあたる可能性」以外の理由で、行政検査を受けることをお願いするメッセージを出しうるため
詳細… #532 (reply in thread)

[daisuke-nogami]

リスクスコアとはなにか、が書いていなかったのを調べ直したのでpull-request本文の更新とともに
詳細をメモ。

• リスクスコア = scoreSum
  • infectioness, reportTypeも加味したスコアで判断する必要がある
  • weightedDurationSumはinfectioness, reportTypeによる重み付けを無視する（※要：挙動検証）
• ただし、将来的な「閾値を設定しうる対象」にはweightedDurationSumも含まれる
  • reportTypeによって挙動を変える可能性があるため

Android

https://developers.google.com/android/exposure-notifications/exposure-notifications-api#data-structures

maximumScore
Highest score of all ExposureWindow objects aggregated into this summary.
scoreSum
Sum of scores for all ExposureWindow objects aggregated into this summary.
weightedDurationSum
Sum of weighted durations for all ExposureWindow objects aggregated into this summary.

iOS

https://developer.apple.com/documentation/exposurenotification/enexposuresummaryitem/3644417-weighteddurationsum

weightedDurationSum ignores infectiousness and diagnosisReportType; therefore, it can be nonzero for encounters that have a infectiousness weight or diagnosis report type weight of 0.

[keiji]

すみません。このコメント今読んだのですが、
#646 (comment)

リスクスコアの閾値
プッシュ通知を出す要否
検査を促す理由を示す文字列

仕様としてToo bigなので2.0より後に対応しましょう。
IssueのDescriptionにある閾値だけなら外部ファイル化はしておいてもいいかなと思いますが、現時点ではちょっとやり過ぎ感あります。閾値だけ対応してもややこしいことになることは間違いないので「最新のCOCOAはよりよい接触通知ができるよ」としてアップデートを促す手段にする方が、当面は良いと思います。

[daisuke-nogami]

了解です。たしかにToo Bigですし、そこまでこまめに閾値を変更するような運用にはすぐにはならないでしょうから、v2.1以降での対応で了解です。

[keiji]

ひとまず当初想定していた「閾値を変更する」「比較のオペレーターと値をJSONファイルで設定できる」「比較する対象となる変数は決め打ち」という仕様で作っていたものをPull Request #672 として出しています。

こんな感じの設定ファイルです。

{
  "format_version": 1,
  "DailySummary_DaySummary_ScoreSum": {
    "op": ">=",
    "value": 2000.0
  },
  "DailySummary_DaySummary_WeightedDurationAverage": {
    "op": "NOP",
    "value": 0.0
  },
  "ExposureWindow_ScanInstance_SecondsSinceLastScanSum": {
    "op": "NOP",
    "value": 0.0
  },
  "ExposureWindow_ScanInstance_TypicalAttenuationDb_Max": {
    "op": "NOP",
    "value": 0.0
  },
  "ExposureWindow_ScanInstance_TypicalAttenuationDb_Min": {
    "op": "NOP",
    "value": 0.0
  }
}

[daisuke-nogami]

ENv2に更新したときに、不適切な設定値を設定してしまってアプリを更新せねばならない、という事態を
防ぐために、必要最低限に絞って実装するのがよいと考えました。

今回調整せねばならないのはScoreSumですので、

{
  "format_version": 1,
  "DailySummary_DaySummary_ScoreSum": {
    "op": ">=",
    "value": 2000.0
  }
}

この部分だけあると、リリース後の万が一に備えられてありがたいですし、
他の事項は、接触通知を多様化するときに必要なもので、アプリの更新をしないと使えないものですので、
初期リリースでは入れなくてよいと考えます。

[keiji]

他の項目はNOP（なにもしない）に設定しておけばいいので。
文字リソースとか通知の出し分けは今回は入れないということで。

[kazuhiro4949]

@daisuke-nogami @keiji
DLしてきたデータのパラメータに関してですが、それぞれ値の範囲って想定可能でしょうか？
第３者によってユーザーのconfigが差し替えられることも想定して、異常な値が排除できればと思っています。(必ず0以上になるなど)

オーバーフローさせるなど具体的できるかを考えてみましたが特に思いつかなかったので、明らかに異常な値で想定外の挙動が発生しない範囲で大丈夫だと思っています。

[daisuke-nogami]

値の範囲、以下の5項目なら0以上の正の値で上限なし、ですね。

"DailySummary_DaySummary_ScoreSum"
"DailySummary_DaySummary_WeightedDurationAverage"
"ExposureWindow_ScanInstance_SecondsSinceLastScanSum"
"ExposureWindow_ScanInstance_TypicalAttenuationDb_Max"
"ExposureWindow_ScanInstance_TypicalAttenuationDb_Min"

想定される問題行為としては、閾値を下げて通知を余分に出す／閾値を上げて通知を出ないようにする、という根本的なものはありますが、それを防ぐための設定値を考えるには、configuration.jsonの設定値から計算とかをしないといけないのでなかなか難しそうですね…

[kazuhiro4949]

想定される問題行為としては、閾値を下げて通知を余分に出す／閾値を上げて通知を出ないようにする、という根本的なものはありますが、それを防ぐための設定値を考えるには、configuration.jsonの設定値から計算とかをしないといけないのでなかなか難しそうですね…

そういった問題であれば現状のcocoaの他の通信も潜在的に持っている課題なのでこの対応の中であえて対策する必要なさそうです。
ご確認ありがとうございます。

[keiji]

#696 でもらった内容を設定ファイルの初期値として設定しましょうか。

現在は設定ファイルがダウンロードできないとすべての条件がNOP扱いになり、ハイリスクな接触がないものとして扱われます。

[daisuke-nogami]

はい、それがよいと思います。
出ないのは非常に問題なので…
（現在の設定値、もし問題があるとしても「機種によっては1.5mくらいでも反応する」という感じにはなると思うので、初期値としても適切だと思います）

[keiji]

@daisuke-nogami @kazuhiro4949

ぼく複数の基準値がある場合の評価をORで作ってますが、これ必要なのは絞り込みANDですね。

cocoa/Covid19Radar/Covid19Radar/Services/ExposureRiskCalculationService.cs

Lines 68 to 87 in adfc256

	if (configuration.DailySummary_DaySummary_ScoreSum.Cond(dailySummary.DaySummary.ScoreSum))
	{
	return RiskLevel.High;
	}
	if (configuration.DailySummary_WeightedDurationAverage.Cond(weightedDurationAverage))
	{
	return RiskLevel.High;
	}
	if (configuration.ExposureWindow_ScanInstance_SecondsSinceLastScanSum.Cond(secondsSinceLastScanSum))
	{
	return RiskLevel.High;
	}
	if (configuration.ExposureWindow_ScanInstance_TypicalAttenuationDb_Max.Cond(typicalAttenuationDbMax))
	{
	return RiskLevel.High;
	}
	if (configuration.ExposureWindow_ScanInstance_TypicalAttenuationDb_Min.Cond(typicalAttenuationDbMin))
	{
	return RiskLevel.High;
	}

例えば次の課題に対応するために、ExposureWindow_ScanInstance_SecondsSinceLastScanSumに 900 を設定するとケースを考えています。

#673 (comment)

ANDに変えようと思いますが、いかがでしょうか？
（全部NOPの時はfalseを返すようにします）。

[daisuke-nogami]

はい、そうしましょう（接触通知を出す基準が1m以内・15分以上に絞られている現状では、ANDで絞り込むニーズの方がある）

[keiji]

こちらExposureRiskCalculationServiceがその役割を担っているので達成したという認識です。
Closeするので、何かあればreopenをお願いします。