アカウント名:
パスワード:
問題の箇所は ExposureNotificationHandler.cs で定義されている暴露リスクの評価テーブルです。https://github.com/cocoa-mhlw/cocoa/commit/868e291cd05cf50e7e61e6eb499... [github.com]https://github.com/cocoa-mhlw/cocoa/commit/20f3e8c570175f1ad693ccbf90e... [github.com]
修正前
- TransmissionRiskScores = new int[] { 1, 2, 3, 4, 5, 6, 7, 8 },- AttenuationScores = new[] { 1, 2, 3, 4, 5, 6, 7, 8 },- DurationScores = new[] { 1, 2, 3, 4, 5, 6, 7, 8 },- DaysSinceLastExposureScores = new[] { 1, 2, 3, 4, 5, 6, 7, 8 },
修正後
+ TransmissionRiskScores = new int[] { 7, 7, 7, 7, 7, 7, 7, 7 },+ AttenuationScores = new[] { 0, 0, 0, 0, 1, 1, 1, 1 },+ DurationScores = new[] { 0, 0, 0, 0, 1, 1, 1, 1 },+ DaysSinceLastExposureScores = new[] { 1, 1, 1, 1, 1, 1, 1, 1 },
このテーブルを利用して「X[days]前に電波強度Y[dBm]以上でZ[min]以上の接触を濃厚接触とみなす」といった判定をしています。修正前のコードは見るからにサンプル値です。通常は厚労省のサーバから送られてくる最新の値が優先されるので問題にならないのですが、何らかの事情でサーバ値を取得できなかった場合にはデフォルトでアプリ内のサンプル値が使われてしまい、どれだけ軽微な接触でも濃厚接触扱いになるということのようです。「オンラインで陽性登録者のIDは取得できるがテーブルの値が取得できない」という微妙なケースを想定し切れていなかったんでしょうね。
8月4日の時点でおかしいと気付いたYoshiyuki Nakamura氏が詳細な解説を行っています。https://twitter.com/nakayoshix/status/1290608592949620736 [twitter.com]https://twitter.com/nakayoshix/status/1303296656121589760 [twitter.com]https://twitter.com/nakayoshix/status/1305784863320993793 [twitter.com]
＞ このため、厳密に設定して検出されない事態を避けるため、検出範囲を広げすぎていたのが理由であったようだ。
というのはnagazou君の妄想、真っ赤なデマです。
サンプル値そのまま……実際に動いてしまうサンプル値を入れたコードを公開した結果起きた失敗事例がまた一つ。
こんなのどうすれば。リリースビルドでサンプル値のままだとエラーになるようにするしかない？
# BTデバイスとか [security.srad.jp]
Risk levelって国ごとに社会情勢ごとに設定すべきもので 作り始めで決められるものではないですね
それを.csファイルにハードコーディングしている段階でおかしいんですよね。settings.jsonに切り出しておけば誰かが早期に気付いた可能性も。その上で設定値が空のsettings.jsonとサンプルのsettings.json.exampleを用意するのが正道。
何らかのエラーがあったときのためのデフォルト値なんだから読めない可能性がある外部ファイルに依存するのはむしろ問題では?
cocoa/Covid19Radar/Covid19Radar/settings.json [github.com] って読めない可能性がある外部ファイルなんですか？いや、まあ、デフォルト値を設定してもいいですけど、何万人もの行動に影響する値をハードコーディングする勇気はちょっと私にはないですね……。
ファイルなんて読めない可能性があるもの。もっともそいつだと読めないならアプリ動かすなって代物でもあるが。
それと#3895293をよく読めよ。サーバから値取得して使うんだけど、それが取得できない場合の値だよ。ファイルにしたところでハードコードする部分は残る。なので取得できなくとも動作させるのか、させないかでしかない。
配列自体を空にしといてサーバから読んだ値を格納すること無く参照したらエラーでコケるようにしとけばハードコードは要らない。まぁこれは取得できない場合に動作させない選択をした場合限定の方法だが。前回最後に取得成功したときの値を覚えておくって手もある。
「オンラインで陽性登録者のIDは取得できるがテーブルの値が取得できない」という微妙なケースを想定し切れていなかったんでしょうね。
某MNポイント申込APIが想像以上にエラー返しているのを見ると国のサービスなんてあてにしちゃだめだよね、という感想もある
ちゃんと公開レポジトリー更新されてるんだね
公開されても誰も気づかないモノか
サンプル値っていう表現に違和感がある。普通、サンプリングした値のことをサンプル値って呼ぶ気がする。初期値、デフォルト値ならわかるんだけど。元にしたサンプルコードの値そのままっていうような意味で使ってるのかしら。
はい、書いた当人もそう思います。ここでは例示値という意味で使いました。初期値・デフォルト値と言い換えることも考えましたが、修正後のコードもある意味では初期値・デフォルト値であり、区別が難しくなるのでやめました。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
nagazou君のデマを払拭するための解説 (スコア:5, 参考になる)
問題の箇所は ExposureNotificationHandler.cs で定義されている暴露リスクの評価テーブルです。
https://github.com/cocoa-mhlw/cocoa/commit/868e291cd05cf50e7e61e6eb499... [github.com]
https://github.com/cocoa-mhlw/cocoa/commit/20f3e8c570175f1ad693ccbf90e... [github.com]
修正前
修正後
このテーブルを利用して「X[days]前に電波強度Y[dBm]以上でZ[min]以上の接触を濃厚接触とみなす」といった判定をしています。修正前のコードは見るからにサンプル値です。通常は厚労省のサーバから送られてくる最新の値が優先されるので問題にならないのですが、何らかの事情でサーバ値を取得できなかった場合にはデフォルトでアプリ内のサンプル値が使われてしまい、どれだけ軽微な接触でも濃厚接触扱いになるということのようです。「オンラインで陽性登録者のIDは取得できるがテーブルの値が取得できない」という微妙なケースを想定し切れていなかったんでしょうね。
8月4日の時点でおかしいと気付いたYoshiyuki Nakamura氏が詳細な解説を行っています。
https://twitter.com/nakayoshix/status/1290608592949620736 [twitter.com]
https://twitter.com/nakayoshix/status/1303296656121589760 [twitter.com]
https://twitter.com/nakayoshix/status/1305784863320993793 [twitter.com]
＞ このため、厳密に設定して検出されない事態を避けるため、検出範囲を広げすぎていたのが理由であったようだ。
というのはnagazou君の妄想、真っ赤なデマです。
Re:nagazou君のデマを払拭するための解説 (スコア:1)
サンプル値そのまま……
実際に動いてしまうサンプル値を入れたコードを公開した結果起きた失敗事例がまた一つ。
こんなのどうすれば。
リリースビルドでサンプル値のままだとエラーになるようにするしかない？
# BTデバイスとか [security.srad.jp]
Re: (スコア:0)
Risk levelって国ごとに社会情勢ごとに設定すべきもので 作り始めで決められるものではないですね
Re: (スコア:0)
それを.csファイルにハードコーディングしている段階でおかしいんですよね。
settings.jsonに切り出しておけば誰かが早期に気付いた可能性も。
その上で設定値が空のsettings.jsonとサンプルのsettings.json.exampleを用意するのが正道。
Re: (スコア:0)
何らかのエラーがあったときのためのデフォルト値なんだから読めない可能性がある外部ファイルに依存するのはむしろ問題では?
Re: (スコア:0)
cocoa/Covid19Radar/Covid19Radar/settings.json [github.com] って読めない可能性がある外部ファイルなんですか？
いや、まあ、デフォルト値を設定してもいいですけど、何万人もの行動に影響する値をハードコーディングする勇気はちょっと私にはないですね……。
Re: (スコア:0)
ファイルなんて読めない可能性があるもの。
もっともそいつだと読めないならアプリ動かすなって代物でもあるが。
それと#3895293をよく読めよ。
サーバから値取得して使うんだけど、それが取得できない場合の値だよ。
ファイルにしたところでハードコードする部分は残る。
なので取得できなくとも動作させるのか、させないかでしかない。
Re: (スコア:0)
配列自体を空にしといてサーバから読んだ値を格納すること無く参照したらエラーでコケるようにしとけばハードコードは要らない。
まぁこれは取得できない場合に動作させない選択をした場合限定の方法だが。
前回最後に取得成功したときの値を覚えておくって手もある。
Re: (スコア:0)
某MNポイント申込APIが想像以上にエラー返しているのを見ると国のサービスなんてあてにしちゃだめだよね、という感想もある
Re: (スコア:0)
ちゃんと公開レポジトリー更新されてるんだね
Re:nagazou君のデマを払拭するための解説 (スコア:1)
公開されても誰も気づかないモノか
Re: (スコア:0)
サンプル値っていう表現に違和感がある。普通、サンプリングした値のことをサンプル値って呼ぶ気がする。
初期値、デフォルト値ならわかるんだけど。
元にしたサンプルコードの値そのままっていうような意味で使ってるのかしら。
Re: (スコア:0)
はい、書いた当人もそう思います。ここでは例示値という意味で使いました。
初期値・デフォルト値と言い換えることも考えましたが、修正後のコードもある意味では初期値・デフォルト値であり、区別が難しくなるのでやめました。