電子署名の概念整理(当事者型対クラウド型(リモート署名・立会人型))

「電子署名」がいろいろいなタイプがあって、分かりにくいということなので、自分なりの考えをまとめてみます。

なお、厳密を期するために、公開鍵暗号技術をもちいて、ドキメュントについて真正性とインテグリティを確保する技術をデジタル署名ということにします。

信号が添付されたドキュメントがどこにあるのか、ということで、当事者型とクラウド型に分けることができます。当事者型のイメージは、こちらです。

 

 

 

 

 

 

 

 

デジタル署名の付されたドキュメントが当事者間で交換されて、それぞれ保管されるイメージです。90年代のデジタル署名のふされた契約書のイメージというとこんな感じだったような気がします。

しかしながら、いろいろなサービスが、クラウドで提供されるようになります。

このクラウドで提供されるサービスには、二つの型があります。

一つはリモート署名です。

 

 

 

 

 

 

 

 

これは、当事者A、当事者Bともに

(1)社会的に外形上表示されるA、Bと、社会通念上、同一であると識別される法的実体に対して付されるデジタル署名の権限を用いて、

(2)クラウド上のプラットフォームで、それぞれ意思表示がなされる形です。

(1)は、その法的実体が、Aであることは、認証局が、一定の基準に基づいて確認しますし、また、当事者Aのみが、クラウド上に、デジタル署名をなしうるような技術的基準に遵守した運用にもとづいてデジタル署名がなされます。

これによって、上記のドキュメントの真正性とインテグリティが確保されます。

Aさん、Bさんの腕が伸びて雲のなかで、署名をしているイメージです。

これに対して、立会人型という仕組みは、

 

 

 

 

 

 

 

 

このような図で示されます。当事者Aは、このサービスの求める事項の登録によってアカウントを作成します。電子メールアドレス(A@kaisyaA.com) kマシーンから、当事者Bの従業員とされる電子メールアドレス (B@kaisyB.com)宛に、アカウントの利用に関する連絡がいきます。

操作者がそれぞれの当事者の枠から、すこし離れているのは、そのメールアドレスの人が操作をなしたことからしか真正性が判断されないので、その人の権限やそのアドレスが、その会社に属することが保証されていないことを物語っています。

お互いのマシーンの操作者は、プラットフォーム上で、合意のドキュメントを成立させます。するとこのドキュメントに立会人が電子署名をなすので、この成立したドキュメントがその後改ざん・変更されないことについては、この立会人の電子署名の効力で明らかにすることができます。

上のリモート署名のスタイルと比較した場合に、操作者Aが、当事者Aに効果を帰属させることができるか、というのは、この仕組みでは、「技術的に」担保されてないことになります。

これが「技術的に」担保されていないからといって、この合意のドキュメントが証拠として無価値かというとそのようなことは一切ありません。

「リモート署名は電子署名である&クラウド型電子契約にお墨付き」 で触れたように、

電子署名法第三条の推定効が働かない場合であっても、個別の事情に照らして電磁的記 録の真正な成立を裁判所が認定することは可能である。

ということになります。リアルワールドで、すべての契約に印鑑証明書を添付するわけではないです。リアルワールドの裁判において、印鑑証明書が付されていない契約書だから、効力がありませんとは誰もいわないです。それと同じです。

直接、訪問して、知っている人が、その流れのなかで、きちんとドュキメントに応じた対応を取っていれば、そのドキュメントに署名したのが操作者A、Bであって、しかも、それそれれの会社を代表する権限を有していることは、いうまでもないということがいえるでしょう。

その限りでリスク評価をしているのです。それと同じです。継続的な関係のなかで、契約を締結するのであれば、上のようなリモート署名型までのサービスを利用するまでもないというのは、健全なリスク評価だと思います。

 

 

日経のハンコに関する社説は、一次情報にあたる必要がある

日経新聞で、「IT企業発の脱ハンコの波を全産業に」という記事が社説として出ています

この最後には、

政府や国会は企業の取り組みを後押しするために、使い勝手が悪いとされる電子署名法の改正など法制面の整備も進めてほしい。

という意見があります。この記事は、ITリサーチ・アートのエントでふれた「「クラウド上の契約に法的リスク」という記事(エントリはこちら)をもとにするものかと思いますが、この記事自体が、規制改革推進会議の一次情報にあたっていないお粗末なものでした。

もし、本当に、「規制改革推進会議」の資料をあたっていれば、政府は、脱ハンコのために法的な障害は存在しないということを明確に認めているのだということがわかるはずです。この部分は、私は、「リモート署名は電子署名である&クラウド型電子契約にお墨付き」で書きました。

むしろ、規制改革推進会議での省庁の回答の内容を正確に、そして、(確かに専門的な分かりにくいところがあるのは認めるので)分かりやすく、経済人に伝えるこそが、日経新聞のミッションだろうと思います。

私のエントリや規制改革会議での各省庁の回答を読んでもらえばわかるように、「ハンコ」文化を支えているのは、

法律ではなく

法律がハードルになっているとして脱ハンコはハードルが高いのだという誤った認識を広めている側

にあるのだ、ということがいえるだろうと思います。

そのような誤った認識を広めているのが、単なる誤解なのかもしれませんし、新たな技術を受容したくないバイアスによるのかもしれません。もしくは、自分でリスク評価をしたくないという他人任せの性格なのかもしれません。

社説というのは、会社の顔であり、面目をかけて作成さているものと理解しています。しかしながら、日本有数の経済新聞が、俗説にそのまま乗っかっるのは、恥ずかしいことかと思います。もしくは、この会議を詳しく読んでみるという特集でも、月曜日のコーナーでやるべきレベルの話だろうと思います。

こういってもらえるうちが花だと思うべきでしょうね>日経新聞

最後に、e-Signature/電子署名/デジタル署名の概念整理の図をもう一度。

 

 

 

「トランプ大統領 ソーシャルメディア対象の大統領令に署名」と公表者の法理

「トランプ大統領 ソーシャルメディア対象の大統領令に署名」という報道がなされています。

メディア的には、自分のツイートに、ファクトチェックのコメントをつけられた大統領が、これを制限しようと、腹を立てて、大統領令を発令したみたいな流れですが、はたしてそうなのでしょうか。

まずは、原文にあたってみましょう。大統領令は、こちら

第1条は、言論の自由の重要性を強調しています。しかしながら、それらが、

近年のオンライン・プラットフォームの成長は、現代の通信技術に修正第一条の理想を適用することについて重要な疑問を投げかけている。

としています。

第2条は、「オンライン検閲に対する保護」です。

具体的には、(良きサマリア人の法理である)通信品位法(CDA)の第230条(c)項(第230条(c))によって創設された責任の免除が重要な役割を果たしていること、その一方で、その免責の範囲を明確にすべきであると考えていることが主張されています。

この法理は、

オンラインプラットフォームが他人が投稿した一部のコンテンツへのアクセスを制限した場合、名誉毀損などの不法行為の目的で、そのサイトに投稿されたすべてのコンテンツの「パブリッシャー(公表者)」になるとした初期の判例に対処するために考案されたものです

法の下で許される最大限の範囲で、この規定が歪められて、好ましくないコンテンツを削除するために「善意」で行動するのとは程遠い、代わりに(多くの場合、利用規約に反して)同意しない視点を抑圧するために偽善的または口実のある行動をとるオンラインプラットフォームに対する責任保護を提供するように歪められないようにすることが、米国の政策です。

(略)

第230条は、一握りの企業が、開かれた議論の場を促進するという名目で、国の言論の重要な手段を支配する大企業に成長し、その権力を使ってコンテンツを検閲したり、自分たちが嫌いな視点を黙らせたりする場合に、それらの巨大な企業を完全に免責することを許可することを意図したものではありません。 インタラクティブ・コンピュータ・サービス・プロバイダーがコンテンツの削除やアクセス制限を行い、その行為が(c)(2)(A)号の基準を満たしていない場合、そのプロバイダーは編集行為を行っていることになります。 このようなプロバイダは、(c)(2)(A)号に定められている責任限定の盾をに失うのが適切であり、オンライン・プロバイダではない従来の編集者や出版社と同様に責任を問われるべきであるというのが米国の方針です。

というのが、具体的な問題点の提起になります。

そして、具体的な解釈論として明示されるべき事項としては、どうか、というと

(i) 第230条(c)(1)項と(c)(2)項の相互関係、特に、(c)(2)項(A)で特に保護されていない方法でコンテンツへのアクセスを制限する対話型コンピュータサービスのプロバイダは、(c)(1)項の保護を主張できない場合があることを明確にし、決定すること。

(ii) 素材へのアクセスや利用可能性を制限する行為が、第230条(c)(2)(A)号の意味で「善意で行われた」とは言えない条件、特に、以下のような場合に「善意で行われた」と言えるかどうか。

(A) 偽装的、口実的、またはプロバイダの利用規約と矛盾している場合。

(B) 十分な通知、合理的な説明、または意見を聞く有意義な機会を提供しなかった後に取られたもの。

その他適切な場合

第3条は、「連邦納税者の表現の自由を制限するプラットフォームからの保護」です。

連邦政府が、オンラインプラットフォームに対して広告宣伝費として支払っているのを見直すように言っています。

第4条は、不公正もしくは欺瞞的な行為等の見直しです。第5条は、州による見直し、第6条は、立法の準備、第7条は、定義、8条は、一般的規定になります。


ここで、上の通信品位法による責任制限とパブリッシャーの法理との関係を見ていきます。

これらの点については、私の会社のITリサーチアートが総務省からの調査を受託してなした「諸外国におけるインターネット上の権利侵害情報対策に関する調査研究の請負-報告書-」の報告書で明らかになっています。

まずは、上で「「パブリッシャー(公表者)」になるとした初期の判例」というのをみていきます。

パブリッシャーの法理については、報告書123頁で触れています。まず、「公表」とは、意図的又は過失により、ある事項の第三者への伝達に関与し、又は、当該伝達を許可することをいいます。そして、「当該表現を行った者のみならず、当該表現の伝達に関与した者(編集者など)、それを許可した者(出版社)も行為者となる。」のです。

でもって、1990年代にこの法理がインターネットに適用されるか、というのが議論されることになりました。イギリスとアメリカは、別途の発展を遂げます。

アメリカでの判決の発展は、188頁です。Cubby v. CompuServe, 776 F. Supp.
135(S.D.N.Y,1991)、Stratton Oakmont v. Prodigy, No. 31063/94, 1995 WL 805178 (N.Y.Sup. Ct. Dec. 11,1995)があり、通信品位法が制定されました。そして、Zeran判決で、上の230 条(c)が広く適用される契機になりました。

イギリスでは、 Godfrey v Demon Internet Limited 事件 [2001] QB 201 で、プブリッシャーの法理が、ISPに適用されることが確認されています。なので、基本的には、ISPにも名誉毀損が成立するものとされていました。その後、2013年名誉毀損法の成立などがなされます(報告書131頁)

オーストラリアでは、1999年放送サービス法改正法によって、免責が認められて、英国のプブリッシャー法理を否定しました。


230条(c)については、報告書の187頁に記載されています。

問題のある情報を制限・排除する良きサマリア人の保護
(1)公表者としての取扱い
インタラクティブ・コンピュータ・サービスのいかなるプロバイダ又はユーザーも、他のコンテンツ提供者によって提供された情報について、パブリッシャーとして取り扱われてはならない
(2)民事責任
いかなるプロバイダも以下のことを理由として責任を負わされてはならない

(A)下品、わいせつ、煽情的、卑猥、過剰に暴力的、嫌がらせその他問題があるとプロバイダが考える情報(略)に対するアクセス又は当該情報の利用を制限するために善意でとられた行動
(B)前段落所定の情報に対するアクセスを制限する技術的手段を実現するためにとられた行動(略)」

その一方で、インターネットのプレイヤーが、通信について伝達を主とするISPから、自ら、コンテンツを表示する情報コンテンツプロバイダーに変わってきたという事情がありました。

米国では、既に、通信品位法第 230 条(c)が、情報コンテンツプロバイダーかどうかが争われたという事案がありました。Jones v. Dirty world entertainment recordings llc.事件において、裁判所は、同項は、情報インタラクティブ・プロバイダが、問題のコンテンツの情報コンテント・プロバイダでない場合に限って認められるにすぎない、そして、ウェブサイト管理者が、コンテンツの創作若しくは発展(development)に、部分的に影響があれば、その点については、責任を負うべきであること、ただし、主張された違法性に主として貢献する(to materially contributing)」部分に限って判断されること、の判断をなしました。

その意味で、通信品位法第 230 条(c)の適用範囲については、あまり明確ではないのではないかとして議論されていたのだと思います。また、広範囲すぎるのではないか、という議論も出ているということも指摘されていました(報告書189頁)。

なので、大統領の一時的な私怨を晴らすための大統領令という見方は、正確ではないのではないか、というのが私の見方です。

「接触確認アプリ」の仕様書について (2)

仕様書 第1編を見た「接触確認アプリ」の仕様書について (1)のに続いて、第2編 仕様(要件定義)です。

第2編 仕様(要件定義)

要件定義は、機能要件と非機能要件に分かれています。

第1章 機能要件の定義

1. 機能に関する事項

これは、さらに基本機能(インストール)、認証機能、あと、アップル・グーグル枠組(Apple Google Frameworkですね、AGF)で実現する機能にわけて論じられています。アップル・グーグル枠組は、私のブログだと、既に見ているし、あと、本で、触れています。

インストールで興味深いところは、オプトインで、利用規約、ブルートゥース利用の案内、通知機能利用の確認がなされることが確認されているところです。また、同意の撤回についても、確認がなされています。

陽性利用者の接触履歴のアップロードが、「認証機能」という名称のもとで論じられています。これが、「認証機能」たるゆえんは、「いたずらの陽性者の通知を防止する」ための陽性者の端末の認証という趣旨ですね。

これは、世界でも共通の問題意識で、シンガポールは、保健所の職員がワンタイムパスワードでいれる仕組みですね。イギリスのNHSXは、自己申告の症状でもOKとしているので、ちょっと問題という記事を読みました。

この部分のフローと画面遷移の記載があります。

あと、近接接触した人数の総計の画面表示については、AGと調整中のようです。家族との間を近接接触といわれてもなんで、ホワイトリスト機能も要件になりますね。

利用中の機能は、AGFで提供なのでパス。

そのあと、フェーズ的には、近接接触者への通知ですね。AGF風には「ばく露通知」です。(ただ、理論的には、変動する近接識別子(Rolling Proximity Identifier@接触符号と訳されていますね)が送信されて、端末で、照合されるので、通知でもないでしょ、という人もいます。そのとおりです。正しく、理解することはとても大切です。) これは、図を貼っておきます(仕様書16頁より)。

この場合に、接触確認がなされると、接触確認フラグが、通知サーバーにいくのですが、保健所はスルーです。でもって、わが国だと、利用者が、保健所には、そのアプリでガイダンスを得て、「必要に応じて連絡」ということになっています。

なので、意図的にと思われますが、本来の「コンタクトトレーシング」という趣旨からは離れて、近接接触者の行動変容を促す、というのに重点がおかれた仕組みになっています。公式には、接触「確認」アプリといっています。

通知サーバー統計機能が記載されています。これは、上の図でいうと、接触確認フラグから統計をとるということですね。(調整中だそうです)

2. ファイルに関する事項

これについては、については、特に注意する事項はありませんでした。

3. 外部インタフェースに関する事項

これについては、日次キーと時刻による診断キーが送出されて、それを各自が手元で照合する仕組みが記載されています。(ここは、DP-3TとAGFの違いになっていたのかな、ここも本の修正が必要なりそうです。すみません。)

第2章 非機能要件の定義

1. ユーザビリティ及びアクセシビリティに関する事項

同意事項が多いこと、直感的操作、適切なガイダンス、視覚的な理解、英語の準備、未成年のための代理登録が触れられています。

2. システム方式に関する事項

システム(中央サーバの仕組みだと思います)は、クラウドサービスを利用することがうたわれています。あとは、OSは、両方、AGF準拠と。

3. 規模に関する事項

スマートフォンの国民の個人保有率が64.7%(令和元年版情報通信白
書)であるので、最大で国民の6割以上が導入することを目指す想定で
基盤等の拡張性を確保する。

だそうです。100%のインストール率を目指しているのかもしれません。個人的には、オプトインは、「スマッジ」ですね。でも、日本人だと奇跡はありうるのかも。ノーベル経済学をもふっとばすアマビエの御札効果ですね。

14日分の接触データ、日次キーの提供でもって、4月6日週レベルで押さえ込むからねという見込みがでています。

4. 性能に関する事項

応答時間(3秒以内)、通信回線の輻輳防止等、ブルートゥースの較正ですね。ブルートゥースの較正は、他の国でも論点になっているという認識です。

5. 信頼性に関する事項

稼働率ですね。

6. 拡張性に関する事項

処理能力の拡張が可能性、モジュール設計、接触カウント機能等の拡張、相互運用性にも対応が触れられています。

国際的な相互互換性について留意すべきことが触れられています。本のなかでは、これも重要な原則の一つとしています。

7. 上位互換性に関する事項

APIによる接続を原則とすることです。

8. 中立性に関する事項

ベンダーロックインの解消等、オープンな標準的技術または製品を用いること、開発ドキュメントの透明性の確保への配慮です。

9. 継続性に関する事項

一時的な停止で大きな社会的混乱を引き起こすものではないこと、端末の機種変更時のデータ引き継ぎは考慮しないことです。

10. 個人情報保護に関すること/11. 情報セキュリティに関する事項

別途の留意事項によります。

12. 情報システム稼働環境に関する事項

国内リージョンのクラウドサービスであることが、明らかにされています。これは、プライバシーやセキュリティの評価の際に問題がでてきます。

13. テストに関する事項

ベータ版のテストも検討することだそうです。

14. 運用に関する事項

通知サーバーの運用の自動化、異常発生時の工夫、FAQの整備、ユーザーとのコミュニケーションなどが記載されています。

15. 保守に関する事項

信頼性、継続性に配慮、サーバーの停止時間ができるだけ短期になるよう配慮、とのことです。

16. 関連ドキュメントの整備

整備されるべきドキュメントとして、利用規約等、設計書及び関連ドキュメント(ソースコード、通知サーバーの運用マニ ュアル含む)、簡易説明およびFAQ があげられています。

ということで、仕様書の分析は、終了。基本的には、このようにオープンな形で検討できるのは、すごくいいですね。


でもって、「接触確認アプリに関する有識者検討会合」で定める個人情報保護・セキュリティに関する留意事項をみていくことになります。

が、この検討は、アマゾンKindle出版で販売されている「新型コロナウイルス対プライバシー-コンタクトトレーシングと法」を6月1日のアップデートを行うなかでしようと思います。

「接触確認アプリ」の仕様書について (1)

5月17日に、第2回 接触確認アプリに関する有識者検討会合 が開催されて、そこで、「接触確認アプリ及び関連システム仕様書(案)[概要] 」と「「接触確認アプリ及び関連システム仕様書(案)」に対するプライバシー及びセキュリティ上の評価及びシステム運用上の留意事項(案)の概要 」が公表されています。

また、5月26日に、「接触確認アプリ及び関連システム仕様書」が公表されています。あと、「「接触確認アプリ及び関連システム仕様書」に対するプライバシー及びセキュリティ上の評価及びシステム運用上の留意事項 」も公表されています。

でもって、詳細なコメントが公開されています

まずは、仕様書からみます。

仕様書は、第1編 総論、第2編 仕様(要件定義)からなります。

第1編 総論
1. 目的

ここでは、接触が確認された者に対して通知をおこなうことが目的であることが記載されています。

2. 前提条件

前提条件として、陽性者との間で、1m以内で、15分以上の近接状態が続いたもの、確認できるのを14日間としています。

アップルとグーグルの枠組を利用すること、個人情報保護についての記載があり、また、仕様書中に調整中の事項があることが留意されています。

3. システムの基本的な考え方

これについては、AGFを利用して構築すること、識別子は周期的に変更されるものであり、個人や端末を特定できないこと、陽性者との接触の照合も各自の端末内で行うこと、 通知サーバーでは、本人同意のもと、陽性者の識別子のみが管理されること、 アプリと通知サーバーは、情報漏洩や侵入を防ぐために十分なセキュリティ上の措置を講じること、がうたわれています。

4. 概要

これは、関係者が「日本国内居住者・滞在者」であること、アプリの概要が記載されています。アプリの概要については、他の分散型の仕組みとだいたい同様です。陽性者の確認を処理番号の通知とその確認で行うのが特徴のように思えます。

5. アーキテクチャと本仕様の範囲/6. アプリケーション詳細

アーキテクチュアは、

 

あと、照合プロセスは、下の図ですね。

 

 

 

 

 

7. 本アプリで定義、使用する識別子、8. スケジュール、9. 体制、
10. 用語集 は、省略。

なるほどです。これらの図は、わかりやすい。こういう形で、情報が詳細にわかるのは、非常にいいことですね。


アマゾン・キンドル出版で、「新型コロナウイルス対プライバシー-コンタクトトレーシングと法」を発売しています。

接触確認アプリのソースコード公開について

5月19日にコード・フォー・ジャパンの開発してきた接触確認アプリのソースコードがオープンソースになっています。プレスリリースは、こちらです

Githubは、管理パネル、api、アンドロイド、iOSの四つのディレクトリから出来ています。

管理パネルをみていきますが、READMEで、データフローをみることができます。概観の大きなファイルは、こちら。

とか、データフローは、こちら(大きくはこっち)。

データの流れは、わかりますね。

この図で、近接接触者に流れる「陽性者交換用デバイスID」を個人情報だろうといっている人がいるのですが、どうなのでしょうね。この接触者が、受信した段階で、あとは、接触者からしか、扱わないですし、その人は、そのデバイスIDしか受信しないので、陽性ユーザが、このIDの人とは、識別できないですよね。

ある人にとって「個人情報」だったら、誰がいつ取り扱おうが、みんな「個人情報」という解釈に毒されているのでしょうか。よくわからないです。

ロゴとかもあります。

細かいところは、json読みきれないので、パスします。ごめんなさい。

今後は、厚生労働省さんが引き継ぐということで、仕様書とかもでています。

基本的な設計で、コンタクトトレーシングのデジタル化というところから、離れてしまったのは、個人的には、反対なのですが、リソースをかけて、きちんと対応しようとしているということで、更に注目していきたいと思います。

 

 

発信者情報開示のデザインの誤りはどこにあるのか?

木村花さんの死亡に関して、ネットワークの匿名性についての見直しがやっと議論になってきています。

総務大臣のコメントは、NHK「ネット上のひぼうや中傷 投稿者特定の仕組み見直しへ 総務相」です。

また、「ソーシャルメディア利用環境整備機構」が、声明をだしました。声明自体は、こちらです

木村さんを追い込んだのがネットワークの匿名性によるわけで、それを見直しましょう、ということになりつつあるかと思います。

ここでいう「匿名性」は、あるかないか、という話ではなくて、「インターネットと匿名性」という論考で定義したのですが「行為者を特定しようとするコストが、社会通念上、合理的なレベルを超えた状態」という状態と定義しています(82ページ以降)。

「行為者を特定しようとする」コストというのは、発信者情報開示制度を用いて、特定するためのコスト(お金だけではなくて手間暇全体の概念です)です。これが非常にかかってしまう、弁護士としても、これを依頼されても、なかなか大変ですよ、でもって、これだけは、費用がかかってしまいますよ、しかも、プロバイダがログをちゃんと保存しているか微妙ですからね、ということになってしまいます。

ただ、遡って考えると、そもそも、ログというのは、もともとは、プロバイダの情報なので、それを開示してね、といって、開示するかどうかは、プロバイダの判断に本当に委ねられる仕組みだったはずです。それを一定のルールを作ったのが、プロバイダ責任制限法4条の発信者情報開示の仕組みなわけです。

この発信者情報開示に関する情報が、整理されているページはこちらです。

プロハイダ責任制限法の解釈に関するもっとも信頼のおける解説・総務省「特定電気通信役務提供者の損害賠償責任の制限及び発信者情報の開示に関する法律-解説-」はこちらになります

ここで注意すべき表現があります。

発信者情報は、発信者のプライバシー及び匿名表現の自由、場合によっては通信の秘密として保護されるべき情報であるから、正当な理由もないのに発信者の意に反して情報の開示がなされることがあってはならないことは当然である。

という表現ですね(31頁)。ログの記載が、それ自体として「プライバシー」の利益で保護されることをうたっていますね、アメリカ法だとプライバシーに関する合理的な期待となって、第三者のもとに保管されている場合については、それ自体、その期待は、合理的なものとはいえないとされることが多いのですが、そのような理論とは関係なしな点が留意点です。

そして、注ⅵですが、

 ただ、プロバイダ等が任意に開示した場合、要件判断を誤ったときには、通信の秘密侵害罪を構成する場合があるほか、発信者からの責任追及を受けることにもなるので、裁判所の判断に基づく場合以外に開示を行うケースは例外的であろう。

という表現ですね。結局、開示を求められても、自発的に開示しないで、裁判所までいってくださいね、というのがデフォルトになって、斯くして、インターネットの「匿名表現の自由」というのが”守られた”という仕組みになっています。

この仕組みについて、プロバイダに早期に開示させるインセンティブの設計がありません。それか、現状を導いているということができるでしょう。

個人的には、早急に開示に対応しない場合は、同法3条1項の解釈論として自ら、「公表者」として責任をおう(公表を幇助している)ことがありうるというのが確認されるべきでしょう。

私の解釈からいうと、発信者情報についての発信者のプライバシーの保護は、その第三者のもとで開示されないという「合理的な期待」がある限りで保護されているにすぎません。しかも、これは、「他人の秘密」として電気通信事業法4条2項で保護されているにすぎません。(1項2項分離論です)

そうでなくても、「合理的な期待」があるのにないと思ったというのは、事実の錯誤になるので故意がなくなるので、(仮に1項で保護されていたとしても)犯罪はもともと成立しませんね(2項に刑事罰がないのはさて置くとしても)。

では、「匿名表現の自由」との関係は、どうなるのかという問題がでてきます。仮名を使って表現するのと、リンクできなくするというのは、全く別なわけです。仮名による表現を匿名表現の自由と読んでしまったところ(McINTYPE vs. OHIO ELECTIONS COMMISSION 115 S.Ct. 1551,1516(1995))に、罪があるわけです。こんなスライド参照

すくなくても、プライバシーは、人権のカタログのなかで最優越的な地位をしめるものではなくて、他の利益と同じ程度のものとして設計されるべきだと思います。そうだとすると、書面で濫用がなされていないか検証ができる形態であれば、開示されてもいいかと思っています。

4条2項におとしこむ解釈論がとれれば、これは、事業者の内部の義務での保護が問題となるので、むしろ、内部の行為規範を作成して、それの遵守を検証する仕組み、これは、消費者行政課が権限を持てることになります。

私が総務大臣だったら、まず、注ⅵを削除させますね。その上で、

発信者情報は、発信者の第三者のもとにおけるプライバシー保護に対する合理的な期待、場合によっては、法に定める他人の秘密として保護されるべき情報であるから、正当な理由もないのに発信者の意に反して情報の開示がなされることがあってはならないことは当然である

と書き換えさせましょう。そうだとすると、「合理的な期待」がない場合には、自発的に開示したとしても問題がなくなりますね。それを行為規範で担保するのがいいのではないか、と思っています。

そして、この解説について12頁をインセンティブの観点から見直すことを推奨するかと思います。丸7の部分ですが、これについては、通知によって、プロバイダに、権利侵害の認識を知らしめてもいいわけなので、その旨を記載しましょう。そして、もし、通知を受けても、意味なく開示しない場合には、侵害の幇助をしていると同様であるという評価をくわえることができそうです。私にいわせれば、上の注ⅵよりは、上品な解釈だと思いますね。

プロバイダが、責任を負うことになるって?その場合には、権利侵害保険を作って、対応その措置をどれだけまじめにやるかで保険料に差をつけるというのがイギリスの昔の制度だったと思います。結局、社会全体で制度設計をしていかなくてはならないのだろうと思います。

法制度の設計は、総合アートですね。内部の文書の修正だけで、この問題に対する解決のメドがたつかと思います。いかがでしょうか。

NHSのCOVID-19 App

恐縮ですが、本エントリは、アマゾン社キンドル出版による「新型コロナ出版対プライバシー」出版のために、撤回させていただきます。

出版された際には、是非とも、購入をお願いいたします。

第1回 接触確認アプリに関する有識者検討会合など

「第1回 接触確認アプリに関する有識者検討会合 開催」が、先週の5月9日に開催されて、その資料が、公表されています

また、この有識者会合については、「第3回 新型コロナウイルス感染症対策 テックチーム Anti-Covid-19 Tech Team 開催」にいて、正式にテックチームの下に設置が求められたもののようです。(資料 の 8ページ)

有識者会合で提供されている資料で確認しておきしたいのは、以下のとおりです。。

資料4:接触確認アプリの導入に向けた取組について
資料5:接触確認アプリの導入に係る各国の動向について
資料6:接触確認アプリの詳細について(非公開)
資料7:新型コロナウイルス感染症対策としてコンタクトトレーシング
アプリを活用するための個人情報保護委員会の考え方

うち、資料4は、テックチーム資料1-1と同じですね。資料5は、同1-2と同じです。資料7は、個人情報保護委員会の資料です。

資料4をみていきます。


恐縮ですが、本エントリは、アマゾン社キンドル出版による「新型コロナ出版対プライバシー」出版のために、撤回させていただきます。

出版された際には、是非とも、購入をお願いいたします。

 

「コンタクト・トレーシングと法」のスライド

コンタクトトレーシング・アプリケーションについて、欧州・英国・オーストラリアの動向についての注目すべきリンクをまとめて報告した際のスライドをスライドシェアにあげました。

「コンタクトトレーシングとは何か-法律問題と議論」のリンクはこちらです。

なと、スライドでも、書いていますが、現在の予定では、ブログについては整理して、kindle出版等をする予定ですので、コンタクトトレーシング関係の部分については、ブログから近いうちに撤回いたします。

ご了承ください。