接触情報の保存先をSecureStorageServiceから移管することを検討

keiji commented 3 years ago

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

現在、接触情報（UserExposureInfo）をSecureStorageServiceを通じて暗号化した状態で保存している。接触確認APIが出力するデータに関して理解が進むと、暗号化した状態で保存すべき理由に乏しいと考えるようになった。

Loggerでほぼ同じ情報を平文で出力している点も考慮すると、接触情報をSecureStorageServiceを通じて取り扱う理由は、少なくとも現時点では存在しないのではないか。

接触情報の保存先をSecureStorageからローカルファイルに移管する。

接触情報の保存先をSecureStorageからPreferenceServiceに移管する。ただし、接触情報はそれなりに大きなデータになる場合があるので、単体のローカルファイルとして保存するのがやはり良いと思う。

開発チームに確認する。

Internal IDs:

b-wind commented 3 years ago

念の為確認したいのですが、SecureStorageService に保存したデータは Google Account へのアプリデータバックアップ、iCloud バックアップ（アプリケーションのデータを含む）の対象に含まれますか？

どちらもそれぞれベンダーでも容易に閲覧出来る物では無いと思われますが、他のデータや脆弱性との組みあわせで全く触れられない訳でも無いと言う認識です。

なお、Logger の出力は明示的にこれらのバックアップ対象から除外されていることを確認しています。（内容的にこちらは平文で良いのかと言う疑問が無くは無いですが）

keiji commented 3 years ago

はい。僕が知る限りバックアップ対象に含まれています。

「脆弱性との組み合わせで全く触れられない訳でもない」は、端末内データやクラウドバックアップまで、どんな場合でも成り立ってしまうので、具体的にどのような脆弱性を想定しているかで対応は分かれると思います。

個人的には、そもそも最初からすべてのデータについてバックアップ対象にしないという選択肢もあると考えているので、それは別Issueで管理してもいいかもしれませんね。

b-wind commented 3 years ago

具体的にどのような脆弱性を想定しているかで対応は分かれると思います。

これはおっしゃる通りだと思います。その上で各保存領域でどの程度のリスクまでは想定して居るかある程度ハッキリさせて置いた方が良い様に思います（急ぎという認識は無いです）

併せて現状保存している各データのリスク評価も行えばどのような形で保存すべきか、自ずと答えが出てくるかなと。

そもそも最初からすべてのデータについてバックアップ対象にしない

こちらも対応としてあり得る物と思います。ただし、現状とはユーザから見える情報に差が出てしまうので十分な説明は必要そうに思います。