Skip to content
This repository has been archived by the owner on Apr 12, 2023. It is now read-only.

「陽性者との接触確認 ○件」と表示されましたが、陽性者との接触から14日以上を経過しても元の画面に戻りません #121

Closed
kmuto opened this issue Apr 21, 2021 · 12 comments
Assignees
Labels
bug バグ。本来あるべき動作をしていないもの released リリースが完了したもの

Comments

@kmuto
Copy link

kmuto commented Apr 21, 2021

不具合の内容 / Describe the bug

  • 陽性者との接触を確認する画面で、「陽性者との接触確認 ○件」と表示されましたが、陽性者との接触から14日以上を経過しても元の画面に戻りません。

https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/kenkou_iryou/covid19_qa_kanrenkigyou_00009.html#Q4-5
「陽性者との接触から14日以上を経過しても元の画面に戻らない不具合が確認されています。プログラムを修正したアップデート版を配布するまでの間は、「陽性者との接触一覧」の画面で新たな接触が確認されていないかどうか、接触の日付をご確認ください。ご迷惑をおかけして申し訳ございません。」
とあり、これは「不具合」と明確に記載されているのですが、バージョン1.2.3においても現象が継続しています。

再現手順 / Steps to reproduce

  1. 14日間より前に接触記録がある
  2. 「陽性者との接触を確認する」
  3. 「過去14日間の接触」画面で「陽性者との接触確認」1件がある
  4. 「陽性者との接触一覧」
  5. 「過去14日間の接触一覧」に、14日間より前の接触記録が表示される

期待される挙動 / Expected behavior

  • 案A(ベター。FAQのとおり「元の(0接触の)画面に戻る」): 「過去14日間の接触」という画面において14日より前の接触件数はカウントしない。14日より過去の履歴を持たせる必要があるのであれば、「14日より前の履歴」みたいなボタンを押したらようやく出る程度にしてほしい。
  • 案B(適切ではないがUI上の混乱はない): 見出しを「過去の接触履歴」とし、14日間というのを諦める。FAQの変更やiOSとの整合性などがありそう。

スクリーンショット / Screenshots

Screenshot_20210421_133551_jp go mhlw covid19radar
Screenshot_20210421_133555_jp go mhlw covid19radar
Screenshot_20210421_133601_jp go mhlw covid19radar

動作環境 / Environments

  • デバイス:Huawei P20
  • OS:Android
  • バージョン:OSは10.0.0.180。アプリは1.2.3

その他 / Additional context

開発の継続ありがとうございます。


Internal Tracking ID: BUG 1796

@keiji keiji added the bug バグ。本来あるべき動作をしていないもの label Apr 21, 2021
@kvaluation
Copy link
Contributor

データを色々みているけれどコードはほぼ見ていない立場からの情報です。

接触確認アプリCOCOAの動作確認情報から得られるCocoa-logにて、

2021/04/24 11:00:00 | Info | Exposure count: 0 | OnClickExposures | /Users/runner/work/1/s/Covid19Radar/Covid19Radar/ViewModels/HomePage/HomePageViewModel.cs | 80

の Exposure count: {number}の数値と、(日時等はダミーです)

ExposureSummary.MatchedKeyCount: {number} が1以上のときに記録される
Save ExposureInformation. Count: {number}の数値が、濃厚接触件数に対応すると思われます。

このOSから来る数字(濃厚接触件数)が14日後にも残るということは、なにか日付範囲のパラメーターが不正常にOS側に渡っている可能性が考えられるのか、いずれにせよCocoa-logのMatchedKeyCountではない Exposure countの数字にご注目いただけたらと思います。

@i-maruyama
Copy link
Contributor

i-maruyama commented Apr 24, 2021

アプリ開発&git の練習として、fork してから数日コードを勉強しておりました初心者です。

アプリソースコード側で、内部データは変更せずに、ユーザーには表示しないように修正する案A1もありそうです。案A1については、設計思想不明な身でかつ、実機テストができない現状では、頓珍漢な修正をしそうでちょっと慎重になっております。

理想的案A2としては、以下のような Exposure Notification が用意する変数で、制御する案もありますが、OS依存性など調査するのも難しそうです。

それより安直な案A3として、

  • 現状 DaysSinceLastExposureScores = new[] { 1, 1, 1, 1, 1, 1, 1, 1 },
  • 案A3 DaysSinceLastExposureScores = new[] { 0, 1, 1, 1, 1, 1, 1, 1 },

と14日以上のリスク値をゼロにすべきと思いました。逆に言えば、そうなっていない(追記:のちに理解したことからいえば、この案A2, A3ではだめです。なぜならリスク評価はTEK DLと同時に行われるためです。念のため修正しておきます。)現状では、14 日以上経過した過去接触は、全員表示される気がします。(変数 DaysSinceLastExposureWeight なども 50 にはなっていますが、効いていないのでは?)
しかし、これまで案A3を採用されていないことから、何かそうしてはいけない理由もあるのだろうと考えています。

新参者ゆえの誤解があるでしょうから、ご容赦ください。
(案の記号が issue 本文と被るので変更しました)

@keiji
Copy link
Collaborator

keiji commented Apr 24, 2021

ありがとうございます。ぼくの方でも調べてみました。

EN APIを通じて確認された接触記録は、SecureStorageに永続化されています。永続化された記録を14日経過後に消去する仕組み。またはフィルタリングして表示する仕組みが、現在のCOCOAには実装されていません。

とりあえず対応としては、ExposureNotificationService.GetExposureInformationList()の実装で、永続化された接触記録を読み込んだ後、14日以内のデータに限定して(フィルタリングして)返すのが良いと考えます。抜本的な解決策としては定期的に(または起動直後などのタイミングで)、14日より前の接触記録を削除する対応が必要になります。

public List<UserExposureInfo> GetExposureInformationList()
{
loggerService.StartMethod();
List<UserExposureInfo> result = null;
var exposureInformationJson = secureStorageService.GetValue<string>(PreferenceKey.ExposureInformation);
if (!string.IsNullOrEmpty(exposureInformationJson))
{
result = JsonConvert.DeserializeObject<List<UserExposureInfo>>(exposureInformationJson);
}
loggerService.EndMethod();
return result;
}

変更イメージとしてはざっくりこんな感じです。
ぼくもまだちゃんと試したわけではないので、welcome-contoributionに指定します(週明けには開発チームにも共有します)。

        private const int EXPOSURE_EXPIRE_DAYS = 14;

        public List<UserExposureInfo> GetExposureInformationList()
        {
            loggerService.StartMethod();
            List<UserExposureInfo> result = null;
            var exposureInformationJson = secureStorageService.GetValue<string>(PreferenceKey.ExposureInformation);
            if (!string.IsNullOrEmpty(exposureInformationJson))
            {
                result = JsonConvert.DeserializeObject<List<UserExposureInfo>>(exposureInformationJson);

                var twoWeeksAgo = DateTime.UtcNow.AddDays(-EXPOSURE_EXPIRE_DAYS);
                static bool isExpired(DateTime timestamp, DateTime expireDate) => timestamp.CompareTo(expireDate) == -1;

                result.Where(exposureInfo => !isExpired(exposureInfo.Timestamp, twoWeeksAgo));
            }
            loggerService.EndMethod();
            return result;
        }

@keiji keiji added the welcome-contribution Pull Request の送信を強く望むもの label Apr 24, 2021
@i-maruyama
Copy link
Contributor

ありがとうございます。私には、このような修正が良さそうに見えます。

ただ私が読んだ範囲では、接触情報 secureStorageService は永続化したい設計思想(ユーザーは、自分の接触日付と回数は永続的に保持する)を感じました。(私もユーザーとしては理解できます。issue の案Bも追加機能で出来ますし。)

もしそうなら、修正された関数を GetTwoWeekExposureInformationList のような新しい関数名にしていただいて、下記2点の関数名を修正していただけば、ユーザーの見た目は変わると思います。

var exposureInformationList = GetExposureInformationList();

var exposureInformationList = exposureNotificationService.GetExposureInformationList();

一つ注意として前者は、 GetExposureCount を変更するため、下記ユニットテストも変えないと駄目かもしれません(ここは、あまり調べてません)。

各ページについては影響範囲を一応調べ( grep で名前検索していく方法)、以下のようになっています。

「過去14日間の接触」ページ (ContactedNotifyPage.xaml)

  • 件数は、ExposureCount を参照
  • 文字列 ExposureCount @ ContactedNotifyPageViewModel.cs は、本質的には exposureNotificationService.GetExposureCount() が定義
  • 関数 int GetExposureCount() @ ExposureNotificationService.cs は、 GetTwoWeekExposureInformationList().Count を返す。

トップページ

  • exposureNotificationService.GetExposureCount() が0かどうかでページを振り分ける(ContactedNotifyPage.xaml と NotContactedPage.xaml)
  • このGetExposureCount は、「過去14日間の接触」ページ、トップページの他に、ユニットテストで使われるだけです。

「過去14日間の接触一覧」ページ (ExposuresPage.xaml)

  • 日付は ExposureDate, 件数は、ExposureCount を参照
  • ExposureDate, ExposureCount @ ExposuresPageViewModel.cs は、 a=exposureNotificationService.GetTwoWeekExposureInformationList() を以下のように処理した表示用コレクションから定義される。
 foreach (var en in a.GroupBy(eni => eni.Timestamp)) // 日付でグループ化し、 日付毎リスト en から取り出す
 { ...
   ens.ExposureDate = en.Key.ToLocalTime().ToString("D", CultureInfo.CurrentCulture);
   ens.ExposureCount = en.Count().ToString();
   _exposures.Add(ens);// 表示用コレクションに追加
 }  

ちなみに GetExposureInformationList は、接触情報 secureStorageServiceを追加する ExposureDetectedAsync でも呼ばれているため、別名(GetTwoWeekExposureInformationList)を作った方が良かろうと考えました。

以上です。

@kmuto
Copy link
Author

kmuto commented Apr 28, 2021

アプリのプライバシーポリシーをつらつら見ていたところ、4.同意の撤回と記録の削除 にて「アプリ導入端末に記録された動作情報は、生成から14日の経過後に、自動的に削除されます。」とありました。

利用規約のほうは「第4条四 アプリ導入端末に記録された他のアプリ利用者の接触符号は、記録から14日が経過した後に自動的に無効となること。」となっており、"データは永続的に残っちゃってるが無効(無害)なものです"と言えなくはないのですが、規約と同時に適用されるプライバシーポリシーで"端末側の記録から削除"と書いてあるからにはやはり自動で定期的に消さないとポリシー違反でまずいのではないか、と思います。

@keiji
Copy link
Collaborator

keiji commented Apr 29, 2021

ありがとうございます。利用規約とプライバシーポリシーについては詳細を確認します。

利用規約とプライバシーポリシーで使われている用語について確認しておきたいのですが、プライバシーポリシーで触れられている「動作情報」とは、端末内に蓄積されているログを指していると理解しています。また、接触符号についてはRPI(Rolling Proximity Identifier)を指しているとぼくは理解しています(TEKも含まれるかも。こちらは削除ではなく無効と言う表現ですね)

開発チームとしては、COCOAの利用者はCOCOAに多くの情報を保存しておく必要性は感じていない(保存して欲しくない。不要になったら削除して欲しいと思っている)と認識しています。

現在の予定では、14日経過しても陽性者との接触情報が表示され続ける現象については対応が決まっています。
対応は2段階で進める予定で、次のバージョンv1.2.4でひとまずフィルタリングする方法で表示を消し、その後、どこかのタイミングで自動削除の機構を入れようという話になっています。

状態が変わったらラベルやプロジェクトボード、コメント等でお知らせします。

@kvaluation
Copy link
Contributor

本件その他の修正の意味について、ご提案があります。

趣旨:COCOAの証明書機能の強化

COCOAを、接触確認していることの証明書とすることができれば、感染拡大を抑止する有効策になります。

飲食店やイベント会場で、COCOAの画面を提示することで、

  • 過去14日間、
  • A.接触確認(電源およびbluetooth)をONとして(スマホとともに行動し)、
  • B.診断キーTEKとの照合をしており、かつ、
  • C.濃厚接触をしていない証明書として利用いただくことで、

発症前や無症状だけれど感染力のある方からの感染が抑止されます。

システム側の条件

  • A. [使用開始]利用規約やプライバシーポリシーをオンとして、接触符号RPIを受信可能となってからの日数(最大14日)。(持ち歩いたか、bluetoothがオンだったかは簡単には把握できない)
  • B. [照合]診断キーTEKを通知サーバーから受信しており、照合している。
  • C. [接触]濃厚接触していない。正式には、マスクなしで1m以内15分以上であるが、COCOAではマスク有無は判定しないため、現状の濃厚接触の判定結果で良い。
  • D. [過去14日間の情報に限定]過去15日より前の濃厚接触の記録を店舗やイベント会場の方に知らせない。

今回、この #121 の14日以前の接触日情報のフィルタリングにより、D.が満たされることになりますので、より積極的にCOCOAの「証明書」的な使い方を推奨していくことができるようになると考えます。

A.(使用開始)とゼロリセット

 使用開始の証明に関して、はトップ画面の「YYYY年MM月DD日から#日間使用中」の表記が、ゼロリセットされる不具合の解消により満たされますが、1.2.2で完全に解消したというデータは入手できておりません(発生データも未入手です)。

 トップ画面の使用開始日から、長期間スマホを起動していないと、TEKを受信しないため、照合しなかった期間を含みます。(AndroidにおいてはCOCOAを起動しないとTEKを自動受信していなかったため、照合しなかった期間が頻繁に発生していましたが、この点は解消したと見込まれます)。

 証明書としては、トップ画面の使用開始日は不安定で、いままでの経緯もあり、信頼されない比率が高そうに感じます。

 また「過去14日間の接触」ページ (ContactedNotifyPage.xaml)
https://github.com/cocoa-mhlw/cocoa/blob/872cc86eea3d081f48a63805a6ac1f53c3293184/Covid19Radar/Covid19Radar/Resources/AppResources.ja.resx#L302」
 で使用開始直後から「過去14日間の接触」という固定的表現は本来正確ではなく、使用開始日からの経過日数を表示すべきですが、すくなくとも「過去14日間以内の接触」でしょうか。

 #128 接触確認を行った最新の日時をホーム画面に表示する 機能は、Bの照合していることの証明になりますが、AのCOCOAを利用開始してからの経過日数(RPI, 接触符号を記録し始めてからの経過日数)の証明にはならず、別途の日付情報があると、COCOAの証明書機能強化に有用です。

B.(照合)は直近のみで良い

 現在、接触日で16日前までのTEKを受信するので、証明したい日か前日に正常にTEKを受信していれば、過去14日分のTEKを受信し、照合したとして良いです。
 具体例をこちらにいれました。
https://docs.google.com/spreadsheets/d/1-Ano3L0t30o7mCoMj_mZqNkjimSrdNLHF4WI72QREuk/edit?usp=sharing

 毎日照合していることを証明しなくても、当日又は前日の照合(接触確認を行った最新の日時)を証明できれば、感染に影響する14日間の接触はA(使用開始)にてRPIが記録されていれば、証明できます。

 たとえば3日前に照合していれば濃厚接触が表示されたものの、今日照合したから濃厚接触が通知されないのは、14日より前の濃厚接触なので、14日間の接触を証明する必要性からは、3日前に照合しないことは問題にならないです。

 A(使用開始)に戻りますが、このため、「過去14日間の接触」ページの14日間は、利用規約等の合意日から当日までの日数と、14日間のどちらか大きい方を表示できれば、証明書としてわかりやすいと思われます。
 
 色々な機能改善、ありがとうございます。

 機能改善が進み、COCOAの証明書機能を強化し、アナウンスしていくことができる時期が近づいてきていると感じております。(陽性登録率を高めるために、運用ではなくシステム面でのなにかできないかの検討は別途あると良いかと思います)。

 

@keiji keiji removed the welcome-contribution Pull Request の送信を強く望むもの label May 10, 2021
@keiji keiji added the ready-for-release マージが済み、リリース準備が完了しているもの label May 17, 2021
@kmuto
Copy link
Author

kmuto commented Jun 7, 2021

1.2.4にて接触確認なしの表示になりました、ありがとうございます。

@keiji keiji added released リリースが完了したもの and removed ready-for-release マージが済み、リリース準備が完了しているもの labels Jun 7, 2021
@i-maruyama
Copy link
Contributor

v1.2.4 のコードも拝見しました。良いと思います。Close し、今後の secure storage の削除は別 issue にすると、プロジェクトボードが見やすいと思います。

@kvaluation
Copy link
Contributor

ありがとうございます。感謝申し上げます。

対応コード、このへんでしょうか。その記録だけしておいて、Closeに賛成です。

1.2.4でフィルター型導入

public List<UserExposureInfo> GetExposureInformationListToDisplay()
{
loggerService.StartMethod();
var list = GetExposureInformationList()?
.Where(x => x.Timestamp.CompareTo(DateTimeUtility.Instance.UtcNow.AddDays(AppConstants.DaysOfExposureInformationToDisplay)) >= 0)
.ToList();
loggerService.EndMethod();
return list;
}

DaysOfExposureInformationToDisplay = -15

public const int DaysOfExposureInformationToDisplay = -15;

@i-maruyama
Copy link
Contributor

おっしゃる通りと思います。念のため、コード側にもコメントしておきました。

https://github.com/cocoa-mhlw/cocoa/pull/210/files#diff-32f25231936b36b94628424258c02ede8afc4d9bdc9b6361aef4cc9825a2998fR28

@keiji
Copy link
Collaborator

keiji commented Jun 10, 2021

削除のIssue立てたので本IssueをCloseします!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug バグ。本来あるべき動作をしていないもの released リリースが完了したもの
Projects
None yet
Development

No branches or pull requests

5 participants