<前の日記(2019年03月19日) 次の日記(2019年05月19日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 908   昨日: 2734

2019年05月12日

アクセス警告方式(「アクセス抑止方策に係る検討の論点」)に対するパブコメ提出意見

総務省総合通信基盤局電気通信事業部消費者行政第二課から「アクセス抑止方策に係る検討の論点」に対する意見募集が始まっている(締切は5月14日17時)。ブロッキングの身代わりに提案されていた「アクセス警告方式」の是非を問うものである。

アクセス警告方式については、提案が出た直後から身を削って批判してきたところ*1であるが、先月の「インターネット上の海賊版サイトへのアクセス抑止方策に関する検討会(第1回)」を傍聴したところ、構成員からも反対の声は多い様子だったので、力を入れて批判するまでもないかと安堵していたが、このパブコメの募集の様子からして、国民からの意見として反対の声を必要としているように見えたので、改めて意見書を作成した。油断せず皆で意見を出しておいた方がよいように思う。

意見募集の対象となるのはこの文書「アクセス抑止方策に係る検討の論点」である。


「アクセス抑止方策に係る検討の論点」に対する意見

意見1(論点2:あるべきネットワークの姿は何か)

アクセス警告方式やブロッキングの導入の可否の検討に際して「インターネットの特徴」を考慮するのであれば、記載されている「自律分散協調」云々よりも、ネットワーク中立性の論点の一つともなっている「エンドツーエンド原則」(end-to-end principle)に着目すべきである。

エンドツーエンド原則(あるいは主義)は、コンピュータネットワーク設計の基本方針の一つであり、アプリケーションの機能はネットワーク終端のホストで実装するのが適切とするもので、この方針の下では、ネットワーク内の中間ノードは余計な介入をしない「ダム・ネットワーク」であるべきとされる。インターネットの基本プロトコルであるTCP/IPは、この方針に基づいて設計されて広く普及したものであり、WebにおいてもHTTPプロトコルのトランスポートとして用いられている。

エンドツーエンド原則を前提としたWebにおいて、ネットワーク内の中間ノードで「余計な介入」を挟まれると、設計の前提が崩れてアプリケーションに不測の不具合が生じかねない。具体例を二つ挙げると、第1に、日本でも2010年に問題視された「DPI広告」(deep packet inspectionを用いたターゲティング広告、「利用者視点を踏まえたICTサービスに係る諸問題に関する研究会」第二次提言を参照)は、インターネット接続サービス事業者のルータ上でHTTPレスポンスを改ざんしてcookieを挿入するものであった(https://togetter.com/li/27198)ことから、想定していないWebサイトに不具合が生じた事例があるほか、第2に、携帯電話会社が「通信の最適化」と称して、画像ファイルをダウンロードするHTTP通信のTCPペイロードをモバイルネットワーク上で改ざんした結果、スマホ用のゲームアプリが動作しなくなる不具合が生じる事故が国内で発生した事例(https://togetter.com/li/839917)がある。

「検討の前提について」で示されているアクセス警告方式は、警告の表示とその後の「本当にアクセスしますか」に「はい」と答えた場合の処理においてネットワーク内の中間ノードで「余計な介入」を挟む必要があることから、エンドツーエンド原則に反してアプリケーションに不測の不具合を生じさせかねないものと認識するべきであり、エンドツーエンド原則を壊してまで日本のインターネット接続サービスに広く普及させることがはたして我が国の将来にとって相応しいものなのかという観点から検討するべきである。

意見2(論点7:アクセス警告方式実施の前提としての法的整理)

法的整理として「通信の秘密の規定との関係が問題となる」と記載されているが、検閲の禁止(電気通信事業法第3条)との関係を問題としなければならない。

通信の秘密について、「ISPが各ユーザの同意を得た上で実施すれば、通信の秘密の問題をクリアすることが可能」「通常のユーザであれば同意することが想定し得る」場合には「包括同意で足りると認められる」などと記載されているが、検閲の禁止は、common carrierたるインターネット接続サービスの社会的信頼を保護するための規定であるから、ユーザ各個人の都合による同意(真の意味を理解していないユーザによる同意)があるからといって、そのような信頼を害する検閲が許されることにはならない。

検閲の禁止がユーザの同意によって解除されると言うには、common carrierたるインターネット接続サービスの社会的信頼が害されない程度に、どのような場合に遮断がなされるのかが公正に決定されるものでなければならず、その明確な基準が事前にユーザに理解されていることを要する。

検閲は必然的に通信の秘密を侵して行われるものであるから、検閲の禁止義務違反は同時に通信の秘密侵害に当たるのであり、通信の秘密が解除されると言うには、検閲の禁止が解除されるための要件である上記の点を検討しなければならない。

それにもかかわらず、「既存の類似の施策に係る法的整理」を含むこれまでの検討においては、通信の秘密をあたかもユーザのプライバシーの問題に過ぎないかのように矮小化して検討してきたことから、セキュリティ対策であれば通常のユーザば同意することが想定し得るなどといった杜撰な基準で、通信の秘密が放棄されるかのような誤った結論を導いていた。

実際、既に実施されている「電気通信事業者におけるサイバー攻撃等への対処と通信の秘密に関するガイドライン」に基づく「マルウェア不正通信ブロックサービス」では、何を遮断するものであるかが「C&Cサーバーへの通信」などという曖昧な記述でしか説明されておらず、遮断対象が公正に決定されるための明確な基準が存在しないまま、約款改定による包括同意で強制的に行われている実態があり、これがプライバシーの観点からは認められ得るものであり得ても、検閲の禁止というcommon carrierの社会的信頼の保護の観点からは、正当な通信が遮断されかねない点でその信頼を害するものとなっており、問題がある。

例えば、coinhive.comへの接続は、外形的にまさにC&Cサーバへの接続と見做すこともできるものであり、現にこれをマルウェア通信として検知対象としているアンチウイルスベンダーも存在している一方で、正当なユーザも存在するサービスであった。こうしたケースがインターネット接続サービスの検閲対象とならないことが保障される客観的な基準が存在していなければならない。

同様に、海賊版サイト対策として遮断を実施する際にも、遮断対象を明確に画定する基準を要するところ、例えば「著作権を侵害する自動公衆送信」を行うサイトといった基準(平成31年に国会への提出が見送られたダウンロード違法化拡大及びリーチサイト規制の著作権法改正法案ではこの基準が示された)では、過剰な検閲となるのは明らかであるから、より限定的な客観基準が必須である。その結論を導くには、検閲の禁止の観点からの検討が必要であり、通信の秘密を単にプライバシーの問題と捉える誤った検討の方向性は改められなければならない。

意見3(論点4:民間部門において主体的・主導的に進めるべきか)

論点7に対する意見で述べたように、検閲により遮断する対象は客観的な基準により公正に判断されることが求められるところ、現に「マルウェア不正通信ブロックサービス」が対象の基準を不透明にしたまま実施されている現状からすれば、「民間部門の主体的・主導的」な実施では公正さを期待できない状況にある。

海賊版サイトを対象にしようとする本件の場合には、その公正さの確保はさらに難しいものとなる(実際、平成31年に国会への提出が見送られたダウンロード違法化拡大及びリーチサイト規制の著作権法改正法案は、対象の要件を適切に絞ることができずに頓挫したのであるし、「著作権を侵害する自動公衆送信」を行うサイトといった基準では、過剰な検閲となるのは明らかである。)ことから、検閲の禁止を適法に解除するためには、法律に定めるところにより実施し、司法判断によって対象を決定する手続きを介するものとするべきである。

意見4(論点5:ダウンロード行為が違法か否かによる違いがあるか)

「ユーザによる海賊版コンテンツのダウンロード行為が違法とされている場合とされていない場合とで、アクセス警告方式の意義(略)に相違があるか?」との記載があるが、仮にダウンロード行為が違法化されても、複製が行われない単なる閲覧行為は違法化され得ないのであるから、単に閲覧しようとしているだけのユーザからすれば、「あなたは海賊版サイト(略)にアクセスしようとしています。海賊版サイトにアクセスしてマンガのファイルをダウンロードすることは違法であり(略)」との警告画面が表示されることは、余計なお世話でしかなく、閲覧するだけのつもりが誤ってダウンロードしてしまう事態も起きにくいことからすれば、ユーザがそのような機能を欲することが通常であるとは言えない。したがって、このような機能の強制に「通常のユーザであれば同意することが想定し得る」とは言えない。

なお、ユーザが単なる閲覧ではなくダウンロード行為に及ぼうとしている場合にのみ警告画面を表示させることは、インターネット接続サービスの側からは技術的に区別できないため、実現不可能である。

意見5(論点3:ユーザの受け止め方)

アクセス警告方式は、知的財産戦略本部での検討で合意に至らなかったブロッキングの代替案として提案された経緯があるが、その検討でブロッキングが反対された理由が、通信の秘密が侵されてユーザのプライバシーが侵害される懸念にあったことからすれば、「あなたは(略)しようとしています」との警告画面を突き出すアクセス警告方式の方がよほどプライバシー侵害的であり、問題が大きい。このような措置は、まさに「Big brother is watching you.」と、監視されている意識をユーザに植え付けるものであり、「通常のユーザであれば同意することが想定し得る」などというフィクションに基づく約款改訂による包括同意で強行することは、国民を監視に慣れさせ文句を言わせなくする反プライバシー施策に他ならず、到底許容されるものではない。

むしろ、海賊版サイトをDNSエントリから削除するだけのブロッキングの方が、本当はプライバシー侵害がない。ブロッキングが反対された理由は通信の秘密侵害であったが、本来は、プライバシーの観点よりも、論点7で述べたように、検閲の禁止への抵触(結果として通信の秘密をも侵害する)の問題として検討するべきであった。この点ではブロッキングもアクセス警告方式も同等であり、検閲対象を画定する客観基準と公正な判断の運用の困難性こそが、ブロッキングを躊躇させる真の理由だったと言うべきである。

プライバシーを実質的には侵害しないDNSサイトブロッキングをプライバシー侵害だと批判して反対しながら、同時に「通常のユーザであれば同意することが想定し得る」などというフィクションに基づいてアクセス警告方式を合理化したことは、態度に一貫性がないか、辻褄合わせに終始したに過ぎず、本当に国民のプライバシーを尊重しているのかと首を傾げざるをえない。ブロッキングに反対する理由から誤っていたのであり、そこから検討し直すべきである。

意見6(論点6:アクセス警告方式の効果)

アクセス警告方式はただの脅しでしかない。ダウンロードによる複製が違法化されても、単なる閲覧は違法化され得ないのであり、複製が行われたか閲覧のみに止まったかは、サイト側からもインターネット接続サービス側からも判別不可能なのだから、こうした状況を理解しているユーザに対しては、警告は何ら抑止効果をもたらさない。

それどころか、実際には危険でないものを危険であると脅すような行為が横行することは、国民のリテラシーを低下させるばかりか、無用な不安感を植え付けるものである。

同様のことは、他の海賊版サイト対策キャンペーンにも見られる。出版広報センターの「海賊版緊急対策ワーキンググループ」が2018年9月に展開した「海賊版であなたが危ない」「忍び寄る4大リスク!!」と称するキャンペーン(https://shuppankoho.jp/damage/tokusetsu-2.html)は、海賊版サイトについて、「アクセスしただけでウイルスに感染する被害が拡大している」だの、「個人情報を盗み出すフィッシング詐欺の主要な舞台」だの、「仮想通貨のマイニングへの強制参加で通信費が膨れ上がる」だのと、ありもしない虚構の脅威を振りかざして、知識の低い階層の民衆の恐れ・偏見・無知に訴えることによって海賊版サイトに対抗しようとする、悪質なデマであった。いかに目的が正当であろうともデマが正当化されることはない。

アクセス警告方式の提案もこの類のデマに感化されて発案された疑いがある(知的財産戦略本部インターネット上の海賊版対策に関する検討会議(第6回)宍戸委員提出資料「アクセス警告方式について(補足)」には、「海賊版サイトの閲覧行為がマルウェア感染等別の形で利用者本人の不利益になる恐れが一般的にあるかどうかによることになる」との記載がある。)ので、デマの再生産とならないよう注意が必要である。

意見7(論点8:アクセス警告方式の技術的課題)

「検討の前提について」で示されているアクセス警告方式は、技術的に言って実現できない。「警告画面」を表示させるとのことであるが、閲覧者がアクセスしようとしている対象が「https://」で始まるURLのサイト(以下「HTTPSサイト」と言う。)である場合には、このような画面を出現させることが技術的にできないからである。

「検討の背景」で引用されている「インターネット上の海賊版対策に関する検討会議(第7回)宍戸委員提出資料」は、2013年から一時実施されていた官民連携プロジェクト「ACTIVE」の取り組みを参考にしたとされているものであるが、2013年当時は、非HTTPSサイト(「http://」で始まるURLのサイト)の割合が十分に大きかったことから、このような警告を出現させることができた。しかし、2012年ごろからインターネットコミュニティは、全てのWebサイトをHTTPSサイト化するべきであるとする方向性を打ち出し、徐々に実施されていった。日本は長らくこの動向に取り残され、10か国中で最もHTTPSサイト化が遅れており、2017年4月まで改善の兆しも見られない特異な国であることがGoogle社の調査により指摘される(https://transparencyreport.google.com/https/overview?lu=load_os_region)ほどであった。ACTIVEの取り組みは、このような技術トレンドに無頓着な時代遅れのピント外れ施策であったと言うべきである。

HTTPSサイトにおいて必要となるTLSのサーバ証明書は、ドメイン名所有者であれば実在性の審査なく誰でも自動的に取得できるものとなっていることから、ACTIVEが対象としたマルウェアのC&Cサーバのみならず、海賊版サイトにおいても、HTTPSサイト化が容易に可能となっている。海賊版サイトの代表例に挙げられた「漫画村」や「Anitube」は、当時は非HTTPSサイトであったが、閉鎖後に復活したと言われる後継サイトの一部は現にHTTPSサイト化されていた。

技術的に言って、可能なことはせいぜい接続できなくすることまでである。ISPが対象サイトのDNSエントリを差し替えて、警告表示用サイトのIPアドレスを設定したとしても、ユーザのWebブラウザは、HTTPSサイトへの接続時には警告表示用サイトに接続できない(TLSハンドシェイクの段階でエラーとなる)ので、ユーザは接続エラー画面しか目にすることがない。

DNSエントリの差し替えとは別に、deep packet inspection手法を用いてHTTPプロトコルに対する改ざんにより実現しようとしても、WebブラウザとHTTPSサイトとの間の接続は、TLS暗号化通信で保護されているので、改ざんすることはできない。どうしても改ざんするなら、「警告画面」表示用の偽造サーバ証明書を自動発行するためのルート認証局証明書を、ユーザのWebブラウザやOSにインストールさせて行う手法があるが、そのようなインストールを促すこと自体が国民のセキュリティリテラシーを低下させるものであり、到底認められない。そのインストールをISP等が提供するソフトウェアで密かに行うなら、不正指令電磁的記録供用罪(刑法168条の2)を犯すことになるだろう。Webブラウザに初めからそのようなルート認証局証明書を組み込んでもらうようWebブラウザのベンダーに交渉したとしても、拒否されるのは必然であり、そのような交渉をすること自体が、インターネットコミュニティの常識に反するものとして嘲笑の的となるであろう。

以上


推敲して明日までに出しておこう。

追記(13日)

若干、拙い表現だった部分を直して、提出した。上の文も差し替えた。

*1 その様子は、「海賊版サイト対策、ブロッキング賛成・反対の関係者が激論…川上氏発言に注目集まる」(弁護士ドットコム, 2018年9月2日)において、「高木氏、「アクセス警告方式」に異議をとなえる」との小見出しで報じられていた。

検索

<前の日記(2019年03月19日) 次の日記(2019年05月19日)> 最新 編集

最近のタイトル

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|
<前の日記(2019年03月19日) 次の日記(2019年05月19日)> 最新 編集