v2.0.0-openbeta01について気づいたことがあれば

[keiji]

v2.0.0-openbeta01（オープンベータ）に関するDiscussionです。
iOS版、Android版ともに配信開始済。

オープンベータには次のURLから参加できます。

• Android版 : https://play.google.com/apps/testing/jp.go.mhlw.covid19radar
• iOS版 : https://testflight.apple.com/join/2tBJvty4

詳細（既知の不具合含む）は次のドキュメントを参照してください。
https://cocoa-mhlw.github.io/cocoa/docs/contribution/open_beta_version/

[b-wind]

β版ユーザーがオープンβ版から既存リリース版・将来的なリリース版への移行する際の手順、データの引き継ぎがあるか等は明示した方が良いのかなと。
（技術的には出来てしまうけれど、やらないで欲しい事等も）

個人的には移行をサポートするコスト・リスクは高いので原則非対応。アプリ消去しての再インストールのみ想定という所でしょうか。

[keiji]

はい。基本的にアプリ消去から再インストールと言う流れを想定しています。
とはいえ、書いておいた方がいいのは確かですね。あとでIssue化します。ありがとうございます。

ちなみに、アプリを消去してすぐにインストールすればENの情報を引き継げるらしいことを確認していますが、何分までならOKとかはまだ分かっていないですね……

[okumuralab]

ExposureChecks-*.json から MatchCount がなくなっているみたいですが，これでいいんでしたっけ？

{
  "Build" : "19E241",
  "ExportVersion" : 2,
  "ExposureChecks" : [
    {
      "Timestamp" : "2022-03-19 03:25:46 +0900",
      "Files" : [
        {
          "Hash" : "B50B03128A719CF24B218A10573FF770D2AE1FFA08CEE424E7A9382E4E33865B",
          "KeyCount" : 3,
          "AppBundleIdentifier" : "jp.go.mhlw.covid19radar",
          "Timestamp" : "2022-03-19 03:25:46 +0900"
        },

[keiji]

@okumuralab
ありがとうございます。減少しない点については少し気になりますね……可能であれば動作ログをいただけないでしょうか。

積分表示になった。iOSの仕様ということなら問題はないのですが、1つの可能性としてはCOCOAの機能不全が考えられるので、場合によってはIssueにしておこうと思います。

ある診断キーファイル（zip）があるとき、Androidでは一度接触確認をしたことのある診断キーを与えても反応しませんが、iOSでは確認済みかどうかは判断せず、何度でも接触確認ができます。
それを防ぐために接触確認済みの診断キーのタイムスタンプを保存しておき(LastProcessTekTimestamp)、新しい診断キーだけ接触確認をするようにしています。

この仕組みがうまく働いていないと、接触確認の度に公開されているすべての診断キーの接触確認を行うことになるので、お知らせ頂いたような現象が起きる可能性があります。

動作ログに「No New diagnosis-key found on」という行があるかどうかでは、フィルターが働いているか、いないか確認可能です。
いまぼくの手元で試した限りでは、LastProcessTekTimestampは正常に保存されていて、フィルタリングも行われているのですが…

[okumuralab]

動作ログです：

cocoa_log_6eec3453-39d0-4cd5-b1cc-04e643724015.zip

[keiji]

ありがとうございます。
フィルタリングは問題なく動作していますね。となると本当に積分になっているのかな……

v2.0.0のリリースに当たっては、このあたりの挙動を注視しておきます。万が一LastProcessTekTimestampでのフィルタリングが働かない瞬間があるとすれば、v2.0.0への置き換わりに比例してCDNの負荷が上がるはずです。

また個人的には #928 の対応を入れて、利用者が自分の接触データを自由に確認できるようにするという方向でも調整したいですね。

[b-wind]

今の所想定通りに動いてはいるようなので優先度的には低いかもですが、OS側ログの出力内容自体はAppleに問い合わせるなり
テスト環境が用意できるのであればある程度検証可能なのかなとは思います。

[keiji]

ひとまずCOCOAの動作不具合を疑って調査するIssueを立てました。 #961

あとは実際に接触状態を作ってMatchCountが積算になるか確認します。

[b-wind]

openbeta に限らず、の話になりますが。
ENS v2 への移行により、 iOS の対応バージョンが 13.7 以降になると認識しています。

これは急ぎでは無い物の記載しておいた方が良い内容かと思います。
流石にβユーザーに該当者は居なさそう。

[keiji]

COCOA2のリリース時にバージョンが変わることは明示した方がいいですね。
ありがとうございます。確認しておきます。

[okkun-zzz]

Bluetoothをオフにしていると1日1回のキーのダウンロードが行われないようです。
オフの状態ではアマビエさんのスプラッシュスクリーンが表示された後、「確認をして利用する」をタップしてもダウンロードは行われませんでした。
Bluetoothをオンにすれば前回のキーの取得後からその時点での最新のキーまでダウンロードしてきます。
デバイス: Essential Phone PH-1 (Android 10)

v1.4.1 (デバイス: Pixel 3 (Android 12))ではBluetoothがオフの状態でもキーのダウンロードが行われ接触の有無の確認が実行されていました。

[keiji]

#934 にIssue作りました！

[keiji]

ダウンロードの頻度が高くなると、サーバー負荷やユーザーの負担する通信料が少し気になる所ではあります。

ありがとうございます。もともとユーザー数の多いiOSが約４時間間隔を目安に設計されていること。日本だと定額通信が一般的なので、ユーザー側の負担が極端に増えることはないだろうと考えていますが、GitHubやストアのレビューを注視していきます。

サーバーの負荷については、スケールできるとは言え直接費用に影響があるので結構シビアですね。
診断キーとlist.jsonのダウンロードの状況を見ながら、場合によっては以前から提案を頂いているetagの導入も視野に入ってくるかと思います。

[b-wind]

βの話題からはだいぶズレてしまうのですが。

日本だと定額通信が一般的なので、ユーザー側の負担が極端に増えることはないだろうと考えていますが

スマホが対象なので、段階式定額制と捉えていますが、あくまで線形の増加であって激増することは考えにくいですね。
特に契約する通信量を使い切った、所謂「ギガが足りない」人に取ってCOCOAアプリの処理時間は長くなると捉えています。

以前から提案を頂いているetagの導入も視野に入ってくるかと思います。

サーバー側の情報更新頻度を上げることも考えると、list.json の圧縮転送を考慮された方が効果が大きいと思います。
（Etag は更新頻度が低いときに有用な手段なので）
#199 (comment) に散発的に書いたので別 Issue に纏めた方が良いかな……

[keiji]

list.jsonの圧縮いいですね。Issueは分けた方が良さそうですが、クライアント側の実装はぼくの方で試すことができます。
加えて、サーバーとクライアントの間にいるCDNがどういう挙動をするか分かってないので、サーバーチームにも聞いてみます。

[b-wind]

圧縮転送の提案に付いては #938 に簡潔ですが纏めておきました。

[b-wind]

COCOA v2.0.0-openbeta から「設定」項目にオープンソースライセンスという項目が増えていますね。（クローズドβ版は見てないです）
「COCOA はオープンソースソフトウェアです。Mozilla Public License 2.0 の条項下で提供されています」
との記述はありますが、MPL v2 ライセンス条項の表示やリンク等が無いのでどのような条項があるのか分かりづらい状況になっています。
即ダメという訳では無いかもですが、あまり嬉しくは無い表記かなと。

また、「ライセンス表記」というボタンを押すとCOCOAとは一見関係無いソフトウェアの表示が並びます。
こちらもボタン名を適切な名前にする必要性を感じます。

[keiji]

そうですね。ご指摘の「ライセンス表記」は本来的には「オープンソースライセンス」と書いた方がいいと思います（それでも一般利用者には何のことか分からない人が居ると思いますが）。

一方、「オープンソースライセンス」にすると横に長くなるので収まりが悪く、これまでの表記を維持しています。アプリ開発者からすると、上部バーメニュー内に「オープンソースライセンス」の名称で置きたいのですが、アクセシビリティ的には上部バーのメニューは使わない方針なので、どのように取り扱うかは結構悩ましいところです。
最近、使い方がメニューからドロワー内に移動したり、GitHubのリンクを開く操作が「https://...」から始まるリンクテキストでなく、ボタンとして独立しているのも同様の理由です。

"3.1 Distribution of Source Form"はソース形式で配布する場合ですね。COCOAのアプリ（実行形式）としての配布は "3.2 Distribution of Executable Form" が適用されて、ソースコードの入手方法が案内されているという条件をクリアすることを念頭に今の形にしています。
こちらもわかりにくいよってのは理解できるので、もっと良い形を模索していきたいと考えているので、アイデアをもらえるとありがたいです。

[b-wind]

個人的にはCOCOA自体のライセンスの説明と利用しているライブラリ等のライセンスの表示が混ざっているのが分かりにくいかなと。
たたき台としては以下の感じではどうでしょうか。

COCOAライセンス

COCOA はオープンソースソフトウェアです。
Mozilla Public License 2.0 の条項下で提供されています
COOCA のソースコードは以下のURLから入手出来ます。

https://github.com/cocoa-mhlw/cocoa/

Mozilla Public License 2.0 の条項は以下のURLから確認出来ます。

https://www.mozilla.org/en-US/MPL/2.0/

• 「ソースコードを入手」ボタン
• 「ライセンスを確認」ボタン

オープンソースライセンス

• 「ライセンスを確認」ボタン

[b-wind]

MPL 原文はアプリ内で持って、直接表示する方が良いですね。リンク先でもほぼ変わることは無いとは思いますが。

[keiji]

ありがとうございます。COCOA自体のライセンスとオープンソースライセンスを分けるというのは良いアイデアだと思います。
#941 でIssue化しました！