アプリを拡張できる様にする。【拡張機能】

[Takym]

かなり大きな変更を勇気を持って提案します。

その機能リクエストは何らかの問題に関連しますか

COCOAは多くの様々な人々に毎日利用されます。そのため目的も多種多様になるはずです。ある利用者によっては今のままでは機能が足りないのかもしれませんし、充分なのかもしれません。COCOAはカスタマイズして利用する様なアプリでは無いとは思いますが、しかし、現時点では接触確認アプリは一国一アプリとなっており、利用者はどうしても欲しい機能があればCOCOAへ要求するしかありません。そして、拡張機能を実装すれば新規機能は利用者の手で開発する事ができる様になると思います。現在でもオープンソース開発をしており新機能の要求はできますが、実装されるまでに時間が掛かる、ある利用者には不必要な機能が実装されストレージ容量が消費される、等の問題があります。

作られる拡張機能は下記の様なものがあると予想しています：

• 接触の確認情報の自動共有。
  • これは個人情報の問題がありそうですが、拡張機能のインストールは利用者の意思で行われますし、インストールしなければ共有されません。
• 要請情報の登録の下書き。
  • これは既に 検査日・発症日の事前入力 #101 にて機能要求されています。
• 東京五輪関連。

解決策についてお書きください

方法１）マークアップ言語で作成できる様にする

拡張機能はCOCOAにより規定されたマークアップ言語（またはXML、JSON等）で記述し、HTTPサーバーで公開します。拡張機能のデータはサーバー上に保存されるのでストレージ容量が殆ど使用されないという利点があります。アプリはインストールした拡張機能のURLと権限と設定を保存するだけで済みます。複雑なパーサーを必要とする点がこの方法の欠点です。他にもマークアップ言語ではなくWebアプリとして作成し、COCOAから起動した時にのみアプリの機能に接続する方法も考えられます。

方法２）C# で作成できる様にする

普通に C# で拡張機能を作成できる様にします。複雑なパーサーは持つ必要はありませんが、ストレージ容量は消費します。スマートフォンのOSの制約によりこの方法は不可能な気もしましたが、アセンブリファイルをユーザーデータディレクトリに保存して読み込めば可能な気もします。

この方法についてもう少し具体的に説明します。新規にプロジェクト「Covid19Radar.Extensibility」（以下、拡張ライブラリ）を作成します。拡張機能からは拡張ライブラリのみを参照して貰います。拡張ライブラリは必要最低限の抽象化されたアプリ機能を公開し、拡張機能はメタ情報と自由な処理を提供します。UIは拡張機能の情報を読み取りアプリ側で生成します。また、拡張ライブラリはアプリ本体やその他のライブラリに一切依存しない造りにします。

拡張機能の公開

拡張機能は一定条件（例えば、透明性を保つ為にオープンソースで開発し無料で公開する等）の基で認定されたもののみアプリ内で一般公開します。認定されないものはアプリ内では公開せず、利用者が自己責任でインストールする事にします。

もしくは、認定されない拡張機能のインストールは拒否し、公開場所は固定します。そして、一定条件に満たしているか、公開しても良いかは、例えばこのリポジトリの Issue でも判断できる様にします。このリポジトリではなく別のリポジトリを新設する事も考えられ、この場合、そのリポジトリで拡張機能を公開する事もできます。

方法２の場合は技術的な制約で後者になりそうです。（ダウンロード元は固定した方がコードを簡潔に書く事ができる等都合が良さそうです。）

セキュリティ・個人情報の保護について

Google Chrome 等の様に拡張機能のインストール時に権限の確認を行い、許可されない処理の実行を防げる様にすべきだと思います。方法１では簡単そうですが、方法２では少し難しそうですね。

方法２において、UIをアプリ側で生成し、拡張ライブラリがアプリ本体に依存しない造りにするのはセキュリティ保護の為です。加えてアプリ本体の公開クラス（public）の一部を内部クラス（internal）に変更する、若しくはアプリ本体を参照している拡張機能の読み込みを拒否する必要もありそうです。

あなたが考える代替案についてご説明ください

一国一アプリではなく複数のアプリを共存できる様にします。ただし、これはかなり大変ですので上記の拡張機能案の方が良いと思います。

その他

• 解決策の方法１と方法２は併用する事もできます。
• discussion ラベルを付与して頂ければ幸いです。
• もし拡張機能の実装が行われた場合、最新情報ページは拡張機能として開発し直し、MITライセンスで公開しようと思います。

---

Internal IDs:

• PBI 2915
• PBI 2916
• PBI 2917

[Takym]

拡張機能のメタ情報について

拡張機能は下記のメタ情報を持つ必要があります：

• 表示名 - 拡張機能の名前です。人間が読むため可読であり且つ多言語対応する必要があります。省略不可能です。
• 著作権 - 拡張機能の著作者情報です。省略不可能です。
• 開発者 - 拡張機能の開発者です。複数人指定できます。
• 説明 - 拡張機能の説明です。省略可能です。
• 利用規約 - 拡張機能の利用規約です。個人情報保護方針(プライバシーポリシー)とライセンスを含みます。省略不可能です。
• バージョン - 拡張機能のバージョン情報です。アセンブリから読み取ります。
• リポジトリ - 拡張機能のリポジトリへのリンクです。省略可能です。
• 権限 - 拡張機能が使うアプリ機能です。利用者により変更可能です。

メタ情報はアセンブリにクラスとして埋め込みます。また、メタ情報を保持するクラスは、アセンブリに属性を適用する事で指定します。

セキュリティ対策

セキュリティ保護の観点から、アセンブリからメタ情報を読み取りメタ情報ファイル(XML、JSONなど)として出力しておき、そのメタ情報ファイルを用いてアセンブリを検証できる様にします。アセンブリファイルとメタ情報ファイルに保存されているメタ情報が異なる場合は読み込みを拒否します。

[Takym]

#232 の様な機能も拡張機能として実装できれば良いですね。

[yozjp]

iOSアプリはApp Store Review Guidelineによってプラグイン的なものが厳しく制限されています。
https://developer.apple.com/jp/app-store/review/guidelines/
2.5.2、4.7あたりに抵触しそうです。
4.7では条件付きでHTML5/JavaScriptによるコード追加が認められているので、ご提案の方法1に近いやり方であれば可能性はあるかもしれません。

[Takym]

まだ不完全ですがサンプル実装を作成しました。

iOSアプリはApp Store Review Guidelineによってプラグイン的なものが厳しく制限されています。

ひとまずは Android 限定で実装するのも有りですね。

[b-wind]

正直拡張機能を要望するユーザーというのが全く想像出来ないのですが……
基本的にはブラウザ拡張と同じ問題を抱えているように思います。

拡張機能のインストールは利用者の意思で行われますし、インストールしなければ共有されません。

この理屈は少々厳しいかと。COCOA はあくまで厚生労働省の名義の元に配布されます。
いくら第３者が作ったものだと言っても、不具合や脆弱性があればそれはCOCOAが原因と見なされます。
COCOA の機能・不具合は国会などでも扱われる物です。相応の慎重さが求められると考えています。

拡張機能は一定条件（例えば、透明性を保つ為にオープンソースで開発し無料で公開する等）の基で認定されたもののみアプリ> 内で一般公開します。認定されないものはアプリ内では公開せず、利用者が自己責任でインストールする事にします。

認定は誰が行いますか？アプリ内で公開してしまうとそれは厚生労働省のお墨付きを与えることになりませんか？
認定に値しない物を取り込む利点は何でしょう？
各ブラウザの拡張でもそうですが、莫大なコスト（人的にも金額的にも）をかけて運営しています。

拡張機能で出来る事はなんですか？
各ブラウザの拡張では操作できるAPIをかなり限定しています。一例としてFirefoxの昔の拡張機能（XUL）ではほぼ何でも出来ましたが、本体の更新にコストが重くのしかかり不具合の原因にもなったのでWebExtension APIに切り替えました。
その結果、本体のメンテナンス性や拡張の安全性・安定性は大きく向上しました。
拡張機能が不具合の原因になることは有ってはならないし、拡張機能の実装にコストがかかる様なら本末転倒でしょう。

見た目が変わって問題になることは無いですか？
COCOA 画面は保健所やその他医療機関でも取り扱う可能性があります。最低限基本機能のページと操作方法を変えられてしまうと現場が混乱します。

一国一アプリではなく複数のアプリを共存できる様にします。ただし、これはかなり大変ですので上記の拡張機能案の方が良いと思います。

これは現状不可能です。技術的な面では無く Google/Apple 共に複数アプリを通さない判断をしています（EN API の利用をしていなくとも）
EN API を使わない。かつ野良アプリとしてならできなくは無い。

個人的にはどの程度のニーズが見込まれるのか、また認定と公開場所の運営負担は誰がするのだろうと言うあたりで難しいなと感じます。

さし当たりですが、気になる点を列挙しましたので @Takym さんの見解をお伺いしたく。

[b-wind]

１点だけ。このリポジトリでPRを作ったとしても取り込まれるかは分からないし、EN API を使う物は私達にはビルド出来ません。
仕方無いこととはいえ、何か上手い方法は無いかなと言うのは思うところが有ります。

[tmurakami]

ご存知かもしれませんが、Android に関しては
https://support.google.com/googleplay/android-developer/answer/9889712?hl=ja
あたりに目を通しておくと良いかもしれません。

[Takym]

@b-wind さん

この理屈は少々厳しいかと。COCOA はあくまで厚生労働省の名義の元に配布されます。
いくら第３者が作ったものだと言っても、不具合や脆弱性があればそれはCOCOAが原因と見なされます。
COCOA の機能・不具合は国会などでも扱われる物です。相応の慎重さが求められると考えています。

第三者である事を明記し、第三者が作成したプログラムをインストールする事に同意した利用者のみインストールする様にすれば、COCOA本体の原因だと見做す人は少ないと思います。
確かに、拡張機能の読み込みを行える仕様そのものの責任を問われる可能性もありますが。
実際に拡張機能の不具合・脆弱性などが原因でアプリ本体に責任が問われた事例はあるのでしょうか。

認定は誰が行いますか？アプリ内で公開してしまうとそれは厚生労働省のお墨付きを与えることになりませんか？
認定に値しない物を取り込む利点は何でしょう？
各ブラウザの拡張でもそうですが、莫大なコスト（人的にも金額的にも）をかけて運営しています。

アプリ内での公開の認定は「厚生労働省のお墨付きを与える」という意味で書きました。
その他にも、公開される場（例えば、GitHub など）で議論し、コミュニティにより認定された拡張機能も定義する事もできます。コミュニティにより認定したものはアプリ内では公開しません。
そして、認定されないものはアプリ内では公開せず、利用者の自己責任でインストールする様にすれば良いと思います。
認定に値しない拡張機能はアプリ内で公開はしません。

「もしくは、認定されない拡張機能のインストールは拒否し、公開場所は固定します。」というのは、拡張機能のインストールがOSにより制限（#215 (comment)）される可能性があるためです。
開発者限定にすれば、認定されない拡張機能でもインストールの許可はできると思います。

拡張機能の認定につきましては自分の中でも考えがまとまっていません。
アプリ外からのインストールを許可するのかどうか、コミュニティによる認定を可能にするのかどうか、に依ってどの様に運用するかは変わってくるでしょう。

拡張機能で出来る事はなんですか？
各ブラウザの拡張では操作できるAPIをかなり限定しています。

僕の想像としては以下の様なものがあります：

• 拡張機能専用ページ（１枚のみ）
  • ラベル、ボタン、テキストボックス、コンボボックス、チェックボックス、ラジオボタン等の基本的なコントロールのみを配置できます。
  • ボタンでできる事はウェブページの表示と、拡張機能が行える事に限ります。
    • ウェブページの表示も、利用者は拒否する事ができます。
• 利用者が許可した場合にのみ、ログ（動作情報）を出力します。
• 利用者が許可した場合にのみ、ログ（動作情報）を読み込めます。
• 利用者が許可した場合にのみ、接触情報を確認できます。
• その他のAPIも全て利用者が許可した場合にのみ実行できる様にします。

見た目が変わって問題になることは無いですか？
COCOA 画面は保健所やその他医療機関でも取り扱う可能性があります。最低限基本機能のページと操作方法を変えられてしまうと現場が混乱します。

既存のページの変更は一切許可しません。
上記でも述べた通り、拡張機能は専用ページを１枚のみ作成する事ができる様にします。

これはあくまでも拡張機能に関する一案でしかありません。
その他の方法でも実現する事はできるでしょう。

[Takym]

開発者限定にすれば、認定されない拡張機能でもインストールの許可はできると思います。

拡張機能の仕組みはありませんが、現在でも開発者のみが利用できる機能（デバッグページなど）は作る事ができていますね。
開発者のみが利用できれば良いのならばビルド構成毎の分岐（Release では取り込まず、Debug でのみ有効化させる）を作成するだけで済みますね。

[b-wind]

https://support.google.com/googleplay/android-developer/answer/9889712?hl=ja

Google の規約的にほぼ無理じゃ無いですか？

[b-wind]

アプリ内での公開の認定は「厚生労働省のお墨付きを与える」という意味で書きました。

その権限は誰にあるんでしょうか……？
コミュニティーが好き勝手に議論しても厚労省のお墨付きとは言えないし、開発チームが行うのでは今と大して変わらないように思えます。

個人的にはどの程度のニーズが見込まれるのか、また認定と公開場所の運営負担は誰がするのだろうと言うあたりで難しいなと感じます。

こちらの返答もお願いします。

[keiji]

提案ありがとうございます。Descriptionの冒頭に「勇気を持って提案します」と書いてあるように、かなり勇気が必要だったのだろうなと思います。提案してくださったこと本当に感謝します。

現時点では拡張機能については、COCOAの計画に含める予定はありません。このことについては後ほど @heykuro 氏からもコメントがあると思います。
一方、拡張機能の必要性や仕様まで、とてもしっかり考えてくださっていることは本当にありがたいとぼくもCIO補佐官の方々も考えています。
返信案を練っているところでしたが、結果として @Takym さんを議論の中心に置くことになってしまったことをお詫びします。

@b-wind
議論の中で、自分の質問に対して「こちらについても返答をお願いします」と、逐一返答を求めるのは、第三者から見れば攻撃的に映ってしまい、ご自身の言葉の信頼性を低下させてしまうこともあります。その点、ご留意いただければと思います。

[Takym]

その権限は誰にあるんでしょうか……？
コミュニティーが好き勝手に議論しても厚労省のお墨付きとは言えないし、> 開発チームが行うのでは今と大して変わらないように思えます。

アプリ内での公開の認定とコミュニティでの認定は違う意味で使っていました。

個人的にはどの程度のニーズが見込まれるのか、また認定と公開場所の運営負担は誰がするのだろうと言うあたりで難しいなと感じます。

認定や運営負担については、#215 (comment) で既に答えた通りです。

拡張機能の認定につきましては自分の中でも考えがまとまっていません。
アプリ外からのインストールを許可するのかどうか、コミュニティによる認定を可能にするのかどうか、に依ってどの様に運用するかは変わってくるでしょう。

[b-wind]

認定や運営負担については、#215 (comment) で既に答えた通りです。

これは見落としていました。ありがとうございます。

細かい所をどのように考えてらっしゃるのかは掘り下げてうかがえましたし、私からは特に言う事はありません。

[b-wind]

@keiji

議論の中で、自分の質問に対して「こちらについても返答をお願いします」と、逐一返答を求めるのは、第三者から見れば攻撃> 的に映ってしまい、ご自身の言葉の信頼性を低下させてしまうこともあります。その点、ご留意いただければと思います。

攻撃的に過ぎたのは自覚がありますが、「言葉の信頼性を低下させる」というのは意味が分かりません。
聞くべきだと考えたことを聞いて信頼性が低下するのでしたら、粛々と受け入れるだけです。
そのような行為・表現を辞めた方がよいと思われたのでしたら、「そのような表現は辞めた方が良い」と言って貰ったほうが改善するにしてもしやすいですね。

[b-wind]

@heykuro さん。返答ありがとうございます。

こう言う機会も少ないのでどうしても指摘ばかりしてしまいますが、出来れば前向きな検討を行い各種やり取りをスムーズに行いたいと言う思いは持っております。
うまく行くようなアイデアが考えつけば、別途提案させていただきます。

[Takym]

また、広く多くの方が使うという観点からも、なるべくシンプルで分かりやすいものを安定的に動作させていくということがCOCOAの今の開発においては必要だと考えています。(もちろん、今後の開発方針が変わっていくこともあるかもしれませんし、こうしたご提案をいただくこと自体は非常にありがたいです！)

多くの人が使うため「拡張できる様にする」か「単純にして分かり易くする」かという考え方があり、僕と逆の発想で興味深いです。

[Takym]

拡張機能について将来また議論できる場所を残しておく為にこの Issue は開いたままにしておいて欲しいのですが、可能でしょうか？

[heykuro]

@Takym

僕と逆の発想で興味深いです。

たしかにそうですね笑。そういう意味でもここで皆さんと一緒にアプリを作っていく意味があるんだろうなと思っています。

拡張機能について将来また議論できる場所を残しておく為にこの Issue は開いたままにしておいて欲しいのですが、可能でしょうか？

わかりました。ただ、将来というのがいつになるかちょっと今時点だと何とも言えないため、そこだけご容赦ください。皆さまで議論を続けていただくこと自体は問題ありません。
(※closeしたとしても、過去の議論や経緯をきちんと残しておくという意味でIssue自体を消すということはありません)

@keiji 運用上、すぐに対応されないものであれば一旦closeしておきたいというのはあるでしょうか？

[b-wind]

目を通すべき場所が増えるので導入は慎重にした方が良いと思いますが、Issue も増えてきましたし議論を目的とする物・当面の実現性の低い物などはGitHub Discussionsを有効にしてそちらに移すという手はありますね。

[Takym]

わかりました。ただ、将来というのがいつになるかちょっと今時点だと何とも言えないため、そこだけご容赦ください。皆さまで議論を続けていただくこと自体は問題ありません。
(※closeしたとしても、過去の議論や経緯をきちんと残しておくという意味でIssue自体を消すということはありません)

分かりました。話は逸れますが、@b-wind さんもおっしゃっている様に Discussions を有効化して頂ければ助かります。他にも質問を行いたい時等に適切な場所があれば助かります。

[heykuro]

ありがとうございます。GitHub Discussionsの利用検討しますね(以前内部でも議論があったのですが、実際にどうするかというところで止まっていたので再度検討進めます)。

[keiji]

運用上、すぐに対応されないものであれば一旦closeしておきたいというのはあるでしょうか？

もともとが複雑な話ですし、目的は明確です。
考えてくださっている人が居るわけですからCloseをする必要はないと思います。

GitHub Discussionsの利用検討

GitHub Discussionsについては、ぼくは以前は推進派として内部議論に参加していたのですが、現在は慎重な立場になっています。

理由としては単純にモデレートのコストが大きくなり、通常のIssueやPull Requestの管理が追いつかなくなる可能性が高いこと。さらに参加者間のやりとりが増える分、個人間での衝突が起こる可能性を危惧しています。

まず、今回のIssueについても早急にコメントを出せるように対応をしていました。しかし、それでも「早めにコメントをしてくれれば」と言う意見が出ているのを見てしまうと、その状態でDiscussionsを始めても、モデレートのリソースは確保できないと考えます。

次に、GitHub Discussionsは確かに便利な機能ですが、参加する側にもある程度の成熟が求められると考えています。今回、攻撃的な内容とも取れる言葉が向けられたと言う出来事は、GitHub Discussionsがあれば防げたというものではありませんし、Discussionsでは参加者間のやりとりが増える分、エスカレートしていた可能性があるとも思っています。

以上の理由から、ぼくはGitHub Discussionsの導入には慎重な立場です。

[b-wind]

理由としては単純にモデレートのコストが大きくなり、通常のIssueやPull Requestの管理が追いつかなくなる可能性が高いこと。さらに参加者間のやりとりが増える分、個人間での衝突が起こる可能性を危惧しています。

こちらについて同感です。
ただし、私が考えているのはモデレートよりもトリアージのニュアンスの方が近いですが。

[b-wind]

望まれない会話を防ぎたければ、（Issue での）会話をロックすると言う方法も有るようですね。
https://docs.github.com/ja/communities/moderating-comments-and-conversations/locking-conversations

回答にはどうしても時間がかかるようですから、こう言った物を利用するのも手かも知れません。

[b-wind]

Discussionsでは参加者間のやりとりが増える分、エスカレートしていた可能性があるとも思っています。

私はともかくとして、他の参加者の方も基本信用しないスタンスなんでしょうか。興味深いですね。

[Takym]

今は拡張機能の仕組みを作らないとしても、将来実装する時の役立つ筈ですので意見を書いていきます。

拡張機能は、上級者モード（「拡張機能の有効化」という名前でも良いです）を用意して設定から変更できる様にしておき、上級者モードを有効にしてからインストールできる様にすれば良いと思いました。
しかし、「単純にして分かり易くする」事を達成したとしても、アプリの公開ガイドラインに違反する可能性も残っています。

解決策の一つとして、拡張機能とは異なりますが追加機能として機能を追加できる様にします。
利用者によるアプリの拡張は行えませんが、機能の追加は行えます。

[heykuro]

拡張機能の話ではありませんが、昨日ご提案いただいたGitHub Discussionsについてです。
内部でも検討しまして、結論としては今後利用していきたいと思います。

一方で、モデレートのリソースが限られていることや直近の優先度という観点で、まずは技術的なテーマに絞って議論していくこととできればと思います。また、運用に際しては私たちも模索しながらになると思いますので、ぜひ皆さんと一緒に議論しながら建設的に進めていければと思います。

取り急ぎ、昨日の議論について検討結果のお知らせまで。開始時にはまたお知らせしますね。

[Takym]

追加機能について

（上記の説明では分り難いと思いますので書き直します。）
利用者は #39、#101、#232 などの機能を任意に有効化・無効化できる様にします。
無効化された機能に関するプログラムとデータは削除しストレージ容量を節約します。
再度有効化した場合にはプログラムとデータをダウンロードします。

[Takym]

この Issue も Discussion へ移行して頂けませんでしょうか。

[Takym]

@keiji さん、ありがとうございます。