さくらインターネットの公式FAQに次の記述があるのに気づいた。
Cookieは、パスなどを指定することができるため、初期ドメイン以外では共有SSLを利用している場合にCookieのパスを正しく指定しないと、同じサーバの他ユーザに盗まれる可能性があります。
(略)
上記については、「同サーバを利用しているユーザだけがCookieをのぞき見ることができる」というごく限定的な影響を示していています。また、Cookieの取扱いについて、問い合わせフォームやショッピングカート等、ビジネス向けのウェブコンテンツを設置されていなければ特に大きな問題とはなりませんが、個人情報を取り扱われる管理者であれば一読いただきたい内容であると判断し、掲載しています。
「ごく限定的な影響」というのはどういうつもりなのか疑問*1だが、この注意書きをちゃんと載せているあたりは、さすがはさくらインターネットと言える*2。しかし、「安全な設定」として紹介されている以下の記述は誤りであり、全く安全でない。
パス /example.com/
https://secure101.sakura.ne.jp/example.com/ のCookieは https://secure101.sakura.ne.jp/hoge.net/ のCGIでは取得できない。
Set-Cookie: における「path=...」指定は、じつはセキュリティ上何の効果もない*3ことが昔から知られている。
私が知ったのは2001年11月のことで、セキュリティホールmemoメーリングリストの[memo:2016]で以下のように書いている。
From: TAKAGI Hiromitsu <takagi.hiromitsu@aist.go.jp> Subject: [memo:2016] クロスサイトスクリプティングとcookieの有効path Date: 2001年11月26日 17:03:58 JST (略) クロスサイトスクリプティング対策として | cookieの有効pathを設定するとよい | - サイトの一部でしか使用しないcookieはpathの有効範囲を絞って発行す | ることで、クロスサイトスクリプティングの影響範囲を狭められる と書きましたが、これは有効な対策にならないことがわかりましたので、この 場をお借りして、訂正します。 以下、なぜ対策にならないかの説明です。 必要なCookie、例えば「sessionid」を Set-Cookie: sessionid=1234567890; path=/serviceA/cgi/; で発行したとします。 このcookieは、 http://example.com/serviceA/cgi/foo.cgi のページに埋め込まれたスクリプトからはアクセスできますが、 http://example.com/serviceB/cgi/foo.cgi や、 http://example.com/foo.html のページに埋め込まれたスクリプトからはアクセスできなくなります。これが Set-Cookie: のpath指定のはたらきです。 ここで、 http://example.com/serviceB/cgi/foo.cgi にクロスサイトスクリプティング脆弱性があったとしましょう。例えば、 http://example.com/serviceB/cgi/foo.cgi?<SCRIPT>...</SCRIPT> にアクセスするとそのページ上でこのスクリプトが動いてしまうとします。 そのスクリプトから目的のcookieにアクセスしようとしても、上に説明したよ うに、「path=/serviceA/cgi/」の指定されたcookieにはアクセスできません。 ところが、ここで、<FRAMESET>を使ってダミーのFRAME (pathがcookieの有効 パスと同一) を生成されると、そのFRAMEのdocument.cookieにアクセスされて しまい、目的のcookieを盗られてしまいます。 http://example.com/serviceB/cgi/foo.cgi?<FRAMESET><FRAME NAME="subframe" SRC="/serviceA/cgi/bar"><FRAME SRC=foo.cgi?<SCRIPT>alert(parent.subframe. document.cookie)</SCRIPT>"></FRAMESET> こんな感じです。parent.subframe.document. とフレームを辿ることによって、 異なるpathに限定して発行されたcookieにアクセスできてしまいます。 この手法は、先日の、Marc Slemko氏の「Microsoft Passport to Trouble」 http://alive.znep.com/~marcs/passport/ で知りました。
このときは、クロスサイトスクリプティング脆弱性への保険的対策としてのpath指定の無効性について述べているが、クロスサイトスクリプティング脆弱性の有無によらず、ホスト名が同一の共用サーバ上で、パス名で区切られた領域に異なる利用者によるページが混在する場合においても同様である。
通常のレンタルサーバでは、今日ではほとんどの場合、ホスト名で利用者を分けている*4ため、この問題の影響を受けないが、SSLの共用サーバとなると、サーバ証明書を1つで済まそうとするためか、同じホスト名のサーバ上にパス名で分けて提供するところが後を絶たない。
同じホスト名のサーバ上にパス名で分けている場合でも、たとえば、2009年6月27日の日記で示した共用SSLサーバでは、事前に用意された入力フォームしか設置することができないものであるため、この問題の影響を受けない。また、2009年8月26日の日記で示したエコポイントの申請画面が置かれたセールスフォースの件では、eco-points.secure.force.com というホスト名で分けられているため、この問題の影響を受けない。(ただし、これらには別の問題があり、その点については、それぞれの日記に書いている。)
さくらインターネットの場合は、自由にCGIプログラムを設置できるというくらいであるから、JavaScriptの記述は自由なのだろう。そうすると、さくらインターネットが挙げている以下のケース
は、実際には、たとえ example.comがpath指定無し、あるいは「path=/example.com/」の指定でcookieを発行していたとしても、攻撃者は、https://secure101.sakura.ne.jp/hoge.net/ 上に以下のようなスクリプトを設置することで、example.comのcookie等を取得することができてしまう。https://secure101.sakura.ne.jp/example.com/ のCookieは https://secure101.sakura.ne.jp/hoge.net/ のCGIでは取得できない。
<iframe src="/example.com/" name="foo"></iframe> <ul> <li><a href="javascript:alert(foo.document.cookie)">Get cookie</a> <li><a href="javascript:alert(foo.document.body.innerText)">Get text</a> <li><a href="javascript:alert(foo.document.body.innerHTML)">Get html</a> </ul>
この例にあるように、取得できるのはcookieだけではない。cookie(やBASIC認証など)を用いてログイン状態となっているページのコンテンツ(秘密であるはずの)も取得できてしまうし、コンテンツの内の入力欄やボタンを操作して、あらゆる不正な操作が可能になってしまう。
これはWebセキュリティの基本で、same-origin policyの「origin」はホスト名で区分される*5ものであって、パス名では区分されないことを忘れてはいけない。
では、同じホスト名の共用サーバ上(他の利用者が自由にCGIやJavaScriptの記述ができるところ)において、どういうことならやっても安全か(共用する他の利用者に攻撃される余地がないか)というと、それはなかなか簡単に結論がでない。仮に条件を示せたとしても、利用者に理解可能なものにはならないと思われるので、そもそもこのような共用SSLサーバのサービスはやめるべきだろう。少なくとも、ホスト名で分けて*6、サーバ証明書を一枚で済ませたいならワイルドカード型の証明書を使えばよい。
さくらインターネットの場合、ホスト名で利用者を分けた共用SSLが、既に追加料金なしに利用できるようになっていた。FAQのページで「初期ドメイン」と呼ばれているもの。それならば、パス名で分けた共用SSLは廃止して、「初期ドメイン」方式へ移行するよう利用者に呼びかけるべきだろう。
*1 このような不正直な表現をする事業者を信頼できるだろうか。
*2 何ら注意書きしていない共用SSLサーバ提供事業者ばかりである中で。
*3 同じ名前のcookieを共存させることができるくらいしか、pathを分けることの意味はない。
*4 パス名で分けているところでは、ページ内にJavaScrpt等を記述させないための対策(広義のクロスサイトスクリプティング対策)がとられている。たとえば、はてなダイアリーがそれに該当する。
*5 正確には、hostとschemeとportによって区分される。
*6 その場合でも、2009年6月27日の日記や2009年8月26日の日記で示した問題点は残る。
4月9日、「利用者視点を踏まえた(略)諸問題に関する研究会」の第二次提言案が公表された。
この提言案には重要な論点が複数含まれている。特に、今このタイミングで一般市民が広く察知して議論を深めておく必要性が高いと私が思うのは、「I CGMに関する検討について」の「2.青少年保護に向けた取組強化について」の「利用者年齢認証の確実化」の部分。
ここに書かれている文章はクネクネクネクネして文章の論理構造を把握しづらいものになっているので、以下に階層的箇条書きでまとめてみる。(脚註は私によるツッコミ。今時間がないので後日追加する予定。)
と、以上の内容になっており、あちこちの誰かからいろいろな要求を出されて、けっきょく何も結論を出せていない状態になっているように見受けられる。
そもそも、「指摘されている」とか言いながら、出典を示しておらず、いったい誰がそのような要求をしているのかが明らかにされていない。この研究会は、親会は公開の場で行われている(傍聴が可能)が、それぞれのWG(ワーキンググループ)は非公開で行われており、密室でこのような文書が作成されているため、なぜこうなったのかが不明である。
私は、小さなIDプロバイダーが年齢情報を属性情報として提供するというのは、その事業者の自由(一定の秩序の下で)だと思うが、電気通信事業という社会のインフラであり、かつ寡占事業である、携帯電話事業において、このような重大な決定が、非公開の場で実質的に決められていくことに危機感を覚える。
ツッコミどころは多々あるので、パブリックコメントで意見を提出したい。
パブリックコメントの提出期限は、冒頭のリンク先にあるとおり、5月10日午後5時必着(郵送なら同日消印有効)とのこと。
一昨年、
これを書いたとき、ケータイから一般のインターネット端末へと青少年の使用端末が移行するであろう近い将来、青少年ネット規制法の改正によって、日本のインターネットが強制終了となるというシナリオを想定した。スマートフォンが開花しつつある今、その運命の分かれ目は間近に迫っている。
そういう岐路に立たされている今、一昨日の日記「ケータイIDに添えて年齢情報も送信されるようになる?」に書いたように、青少年の保護を口実に、年齢情報までインターネット接続事業者に送信させようという動きが出てきている。総務省研究会の提言案自身が述べているように、悪いことをしようとする者を排除することはできないわけで、いくらかハードルを上げることで悪事のコストを高めることはできるだろうけども、それは結局いたちごっこになる。ひとたび年齢情報送信のような施策をとれば、不完全だという理由で、さらに完全な策を求める者が出てきて、次々とより厳格な策をとらざるを得なくなっていくだろう。そうこうするうちに、青少年の一般インターネット接続への移行が完了するが、そのとき、この施策に頼り切ってしまったSNS事業者達は、次に何を要求してくるだろうか。
いろいろ耳にするところでは、年齢認証の他にも、ケータイIDの変更を不可能にしてほしいと要求している人たちがいるらしい。そのような要求は表沙汰になっていないが、auのEZ番号やdocomoのiモードIDが、EZwebやiモードの解約と再契約によって容易に変更できる*1ことに対し、「ひどいよね」と、携帯電話事業者を非難しているという話を耳にした。
ケータイIDの変更を不可能にせよとする要求は、このところ、2ちゃんねる掲示板からも出てきかねない状況になっている。「2ちゃんねる携帯電話大規模規制に関するまとめwiki」などにまとめられているように、昨年の暮れから、携帯電話による2ちゃんねるへの書き込みが大規模に規制され続けており、docomoやauは、キャリア丸ごと規制され続けている。2ちゃんねるでは、悪質な利用者をiモードIDやEZ番号で特定して規制できるようになっているが、悪質な利用者が、iモードIDやEZ番号を頻繁に変更しながら悪事をはたらいているため、丸ごと規制せざるを得なくなっているらしい。
2ちゃんねるは、たかが一掲示板と言うには済まないレベルの影響力を持っているようで、たとえば、「jigブラウザ」までもがiモードIDを送信するようになっているのは、2ちゃんねる運営からの要請にjigブラウザの開発元が応じたことによるものだった。
805 名前: root▲▲ ★ 投稿日: 2008/06/01(日) 20:56:53 ID:???0 BE:3830876-DIA(100512)
・ibisブラウザ・jigブラウザの中の人へ:
NTT Docomoの端末の場合、これまでの端末シリアル番号にかわり、
iモードIDを送っていただくように変更いただくこととなりました。同期をとって対応しようと思いますので、
すみませんが、準備のほう、よろしくお願いいたします。(現在はまだ書き込み出来ますが、
近日中にbbs.cgi的にiモードIDを送っていただかないと書けなくする予定です)
827 名前: root▲▲ ★ 投稿日: 2008/06/02(月) 16:18:13 ID:???0 BE:730324-DIA(100512)
>>805 については、ibis, jig の中の人のご降臨待ちです。
今週末までに何らかの形でご降臨いただけない場合は、
該当ブラウザからの書き込み機能の停止もありえますです、、、。
830 名前: ◆w0gEWSRfYU 投稿日: 2008/06/02(月) 21:37:14 ID:tYiQLE9Z0
>>827
お世話になっております。
株式会社jig.jpの菊池です。ご連絡が遅くなりまして申し訳ございません。
iモードID対応の件了解致しました。弊社側の対応としては、iモードIDに対応したものを今週の木曜日(6月5日)にアップしたい
と考えております。
(略)2ch特化型サーバ・ロケーション構築作戦 Part28, 2ちゃんねる 運用情報
しかし、2ちゃんねる側で(その目的のために)必要としている要求を満たすには、iモードIDのような性質のIDは、過大なものであって、必要なものではない。2週間程度で自動的に変わる独自IDでもよいわけだし、ましてや全サイト共通のIDである必要は全くない。そういった工夫をしたIDの送信を求めてもよかったはずだが、そうではなかった。*2
今もdocomoやauに対するキャリア全域規制が続いているが、このまま利用者の不満が募れば、iモードIDやEZ番号の変更を不可能にしてくれという要請が、キャリアに対して突き付けられることになりかねない。
2ちゃんねるの運営は、たしか、技術的にわりとよくわかった人たちによって取り仕切られていたはずと思う。ならば、影響力あるコンテンツプロバイダーとして、プライバシー上の問題が小さくかつ悪質利用者の排斥にはそこそこ十分に有効な、新しいIDの創設を促すよう、キャリアに働きかけてはくれないものだろうか。
ちなみに、「終了する」というのは、そのような悪質行為の横行する場(掲示板やSNS等)のことを言っているのではなく、それらとは別の善良なサービス(中小企業のECサービス等)のことを指して言っている。なぜそれらが(巻き添えを食らう形で)「終了する」のかについては、「日本のインターネットが終了する日」の「契約者固有ID送信時代の安全なケータイWeb利用リテラシ」の部分で書いている。
*1 2008年7月10日の日記では、iモードIDについて、「「基本的にお客様にずっと通して使って頂くもの」とのことで、ID変更手続きは存在しない。」と書いたが、そうではなかったらしい。
*2 ちなみに、Googleなどが必要としている、広告の不正クリック対策の用途でも、このような仕様のIDで十分なはずである。(Googleのようなお利口さんが集結した会社なら、当然そういうことはわかっているよね?)
前々回の「ケータイIDに添えて年齢情報も送信されるようになる?」の件、パブリックコメントに以下の意見を提出した。
利用者視点を踏まえたICTサービスに係る諸問題に関する研究会 第二次提言(案)に対する意見
■意見1: セキュリティ上の欠陥を解決しない限り年齢情報の送信をしてはならない
(CGMに関する検討、利用者年齢認証の確実化)
要旨
以下の2つの要件のいずれかが満たされない限り、送信された年齢情報は不特定サイトが入手可能になってしまう。したがって、以下の2つのいずれかが満たされない限り、年齢情報の送信を実施してはならない。
理由
提言案は、携帯電話事業者がCGM運営者へ年齢情報を提供するにあたって、提供先の選定基準(適格性の判断基準)を明確にすることが望ましいとしているように、この年齢情報の提供は、選定された(適格性のある)一部のWebサイトに対してのみ送信されることを前提としている。したがって、選定されたWebサイト以外がその年齢情報を取得することができるならば、それはセキュリティ上の欠陥(脆弱性)であるということになる。
一方、提言案にも書かれている、大手SNS運営3社により2009年から実施されている「フィルタリング連動型年齢認証」は、他のWebサイトにおけるフィルタリング適用の有無を、画面上に埋め込んだ当該サイトの画像等へのリンクの表示状況等によって判別している。これは、フィルタリングの有無(未成年か成年か)という2値での判別ではあるものの、年齢に関する情報を反映して生成されたWebページの情報が、他のWebサイトから取得できることを意味している。
すなわち、既に現時点においても、フィルタリングの有無(未成年か成年か)という年齢に関する情報は、不特定のWebサイトで取得可能な状態にあるといえ、問題は既に存在しているとも言えるが、これは、2値での判別にすぎないこと、また、フィルタリングの有無が必ずしも未成年か成年かの区別に対応しているとは限らないことから、この事態の問題性は比較的小さいものとして、社会に許容されていると考えられる。
しかし、今回の提言案が検討している携帯電話事業者による年齢認証は、確実性の高い年齢情報を送信することになるものであるし、また、より粒度の細かい年齢情報の送信を検討しているものであるから、それらの年齢情報が「フィルタリング連動型年齢認証」と同様の手法によって、他の不特定のWebサイトから参照可能であるならば、それは許容されないレベルの問題であり、セキュリティ上の欠陥(脆弱性)である。
このような、他のWebサイトの情報を部分的に取得できてしまう事態は、従来、一般のインターネットのPCサイトにおいても同様に存在してきたものであるが、その場合には、取得できたとしても、それが誰のアクセスによるものかは不明であるため、たいていの場合、問題視されることがなかった。しかし、今日の携帯電話の場合、すべての携帯電話事業者において、アクセス者の契約者固有IDを取得することが可能となっているため、不特定のWebサイトが、他サイトから取得する年齢情報を契約者固有IDに紐付けて収集、蓄積することが可能である。
契約者固有IDは、それ単体では、個人情報保護法に言う「個人情報」には該当しないのかもしれないが、通常のIPアドレス等とは異なり、特定の個人に直接に連結して生成されているものである。もし仮に、「契約者固有IDは個人を特定しないので、年齢情報がそれに紐付けられても問題がない」とする主張が正しいと仮定すると、今回の提言案で検討されている「契約者固有IDを携帯電話事業者に送信して問い合わせると年齢情報が返答される」という仕組みも「不特定サイトからの問い合わせに返答しても問題がない」という帰結になるはずである。しかし、提言案は、そうした問い合わせへの返答を、選定された(適格性のある)一部のWebサイトに限定するとしているのであるし、その理由は、p.24の「CGM運営者における年齢情報の活用時について」に書かれた「仮に個人情報取扱事業者に該当しない場合であっても、年齢情報は利用者にとってセンシティブな情報の一つでもあることから、個人情報の適正な取扱いを求める個人情報保護法の基本理念に基づき、適正な取扱いや利用者への周知について配慮することが求められる」という趣旨によるものであろう。したがって、たとえ契約者固有IDがそれ単体で「個人情報」に該当しないものであっても、不特定のWebサイトが、契約者固有IDと年齢情報とを紐付けて収集できてしまうことは、提言案の前提を満たさない、セキュリティ上の欠陥(脆弱性)である。
よって、携帯電話事業者による年齢情報の送信を実施するには、次の2つの要件のいずれかが満たされなければならない。
今日の携帯電話は、JavaScript機能を搭載した端末が増えてきており、そうした機種においては、(b)で示された「反映内容が他のサイトから参照されることがない」を実現する方法が、必ずしも容易ではなく、少なくとも、各Webサイト運営事業者の自主的な取組みに任せておいて解決するほどに自明なことではない。
したがって、(a)の要件が満たされないのであれば、(b)の技術的対策を完全に実施するための技術仕様が公表されることが必要であり、それができないのであれば、年齢情報の送信をしてはならない。
■意見2: (以下略)
以下、昨年の関連報道。
(略)具体的には、フィルタリング判別専用サイトを設け、そのサイトにある画像(1ピクセル程度)をmixiのトップページなどに貼り付ける。mixi自体は、モバイルコンテンツ審査・運用監視機構(EMA)の認定サイトであるため、フィルタリングを通過できるが、貼り付けた画像は認定サイト外から持ってきたものであり、フィルタリングを通過できない。よって、その画像が表示されなければ、18歳未満のユーザーということになり、(略)
以下、今回の件の関連報道。
(略)年齢確認の強化は、有識者などでつくる総務省の作業部会が6日に提案し、通信会社とSNS運営会社双方が受け入れる意向を示した。
年内をめどに、通信会社が契約時などに確認した携帯電話利用者の年齢に関する情報を、利用者の同意を得た上でSNSやゲーム、自己紹介サイト「プロフ」を運営する各社に提供する。生年月日を含めるかなどの詳細は今後詰める。総務省によると、通信会社が犯罪防止目的で個人情報を第三者に提供するのは異例という。(略)
これまで、契約者固有ID(サブスクライバID)について、それ単体では「個人情報」(日本の個人情報保護法が言う)に該当しないという法解釈は存在した。それは、個人情報保護法がそういう法律だから(プライバシー保護の法律じゃないから)そういうものだという話*1だった。それでも、4月3日の日記にも書いたように、ウィルコムからは、「CPに対しても個人情報保護法に従った慎重な取扱いを求めています」という回答を得ていた。
ところが、auのKDDIが、以下のQ&Aを掲載していることに気づいた。
「EZ番号」(固体識別番号)はau電話ごとに割り振られており、変更することができません。
■EZ番号はお客さまがURLにアクセスした際にサイト提供元のサーバに通知され、会員のアクセス管理などに利用されますが携帯電話番号やメールアドレス、氏名などのプライバシーに関する情報は含まれておりませんのでご安心ください。
これは新しい。個人情報保護法の「個人情報」には当たらないというのは耳にタコだが、プライバシー情報じゃないという見解は初めて見た。KDDIの法務はいったいどうなっているのか。
もっとも、「個体識別」のことを「固体識別」と書くような頭の弱い人が書いた文章なので、そもそもこれを真に受けるのが間違っているのかもしれないが。*2
ちなみに、総務省の「利用者視点を踏まえたICTサービスに係る諸問題に関する研究会第二次提言(案)」には、契約者固有IDに関する法的検討がなされていて、個人情報保護法に関する検討の部分で、p.41の脚註44に、以下のように書かれている。
契約者固有IDについては、複数のコンテンツプロバイダに対して同一の契約者固有IDが送出されるため、各コンテンツプロバイダが保有するウェブページ上の行動履歴や位置情報を、同一IDに紐付けて集積することが極めて容易との指摘がある。また、各コンテンツプロバイダにとっては、契約者固有IDを、契約者情報等の個人情報と紐付けることが容易に可能であり、同一の契約者固有IDに紐付けて集積されたウェブページ上の行動履歴等が比較的容易に個人識別性を獲得するとの指摘がある。
また、プライバシーとの関係について検討されているp.45においても、次のように書かれている。
ウェブページ上の行動履歴や位置情報は、一般にそれ単独では個人識別性を有しないため、特定個人のプライバシーの侵害が成立しないとの指摘がある。(略)しかしながら、個人識別性のない情報であっても、行動履歴等の情報が大量に蓄積されて個人が容易に推定可能になるおそれがあることや、転々流通するうちに個人識別性を獲得してしまうおそれがあることから、現時点で情報に個人識別性がないことをもって、プライバシーとしての保護が完全に失われると考えるのは相当でない。
ところで、図1をよく見ると、「このQ&Aを見た方はこんなQ&Aも見ています」のところに、次のQ&Aがある。
これは、お客さまが受信した迷惑メール内のURLに、お客さまの携帯電話の情報 (電話番号、メールアドレス、EZ番号 (注 1)) とくくりつけられる識別番号が含まれており、そのURLへのアクセス者の情報が判別できるという手口です。
対策としましては、送信者が不明なメールに記載されているURLには、安易にアクセスしないことが一番です。(*) サイト上でお客さまのEZwebのご契約の有無を確認するための専用の番号
それって、EZ番号から電話番号を特定されるってことじゃないの?
KDDI曰く「安易にアクセスしないことが一番です。」
KDDI曰く「URLにアクセスした際にサーバに通知され……ますが……ご安心ください。」
どっちなんだ。
*1 たとえば、「suzukimasatomo先生の最近のつぶやき」、「suzukimasatomo先生の最近のつぶやき その2」など。
*2 だいたい、「個体識別」という言葉も、本来は動物の個体を指す言葉なので、電話機を指して言うのはおかしいし、そもそも、契約者に固有のIDであるなら、それは「個人識別」と呼ぶべきものだろう。最近は年齢も提供するという話なのだから、まさに個人識別番号だ。なぜその言葉を避けるのか。欺瞞じゃないのか。
実は、今年3月、総務省の「利用者視点を踏まえたICTサービスに係る諸問題に関する研究会」からは、有識者ヒアリングとして意見を述べる機会を頂いた。ただし、私に発言の機会が与えられたのは、「ライフログWG」における検討内容のうち、「より信頼されるサービスに向けて(配慮原則の提言)」の部分についてのみで、それ以外の部分については対象外だった。
あまり重大な指摘をする余地のない部分であったが、私としては与えられた使命を全うすべく可能な限り改善点を洗い出して、意見として列挙した。
この「配慮原則の提言」は、報告書案では「ライフログ活用サービス」という表現を使っているが、実質的には、これはすべて「行動ターゲティング広告」を対象としたものになっている。「ライフログ活用サービス」というと、利用者が自ら望んで活用する話に聞こえるが、行動ターゲティング広告では、基本的に利用者に無断で行おうとするものだから、配慮が必要となるというわけである。
配慮原則案は、「(1)広報、普及・啓発活動の促進、(2)透明性の確保、(3)利用者関与の機会の確保、(4)適正な手段による取得の確保、(5)適切な安全管理の確保、(6)苦情・質問への対応体制の確保」から成っており、このうち(3)の「利用者関与の機会の確保」は意味がわかりにくい表現になっているが、ようするに、オプトアウト手続きのことを指している。
(3) 利用者関与の機会の確保
対象事業者は、その事業の特性に応じ、対象情報の取得停止や利用停止等の利用者関与の手段を提供するよう努めるものとする。
このことについて、事業者がプライバシーポリシーで「cookieは拒否できます。削除もできます。」としているケースが散見されるけども「それだけでは配慮が十分とは言えない」というようなことが書かれていたので、その問題に切り込むならもっと根本的なところに切り込むとよいと思い、以下の意見を述べた。
残念ながらこの意見は採用されることはなく、パブリックコメントにかけられた報告書案に反映されていない。まあ、これはしかたがないかと思う。現実的にcookieによるオプトアウトがまかり通っている現状において、このような意見は無理筋であることはわかっていたが、せっかくの機会なので一推しで述べてみた意見だった。
それでも、スライドで例として示した、楽天のオプトアウト用cookieが1年の有効期限になっていた件*1については、総務省で意見を述べた甲斐あってか、数日後に再確認した際には、有効期限が20年(実質無期限)に変更されていた。
ただ、ライブドア社のオプトアウト手続きについて調べてみると、現時点でもオプトアウト用cookieの有効期限は1年になっている*2。
やはり、少なくともこのような欺瞞行為を是正させる何らかの規定なり、業界の自主ガイドラインなりが必要なのではないだろうか。
しかし、今回の「利用者視点 第二次提言案」はそもそもそのレベルまで問題認識が到達しておらず、私が呼ばれたのは、報告書案公表の1か月前(WG最終回の直前)だったので、そこで何か提案しても通らないようだった。
その後調べて知ったのだが、米国では、インターネット広告事業者の業界団体「Network Advertising Initiative」が自主的に、完全なオプトアウトの仕組みを提供する試みを実施しているようだ。
ネットワークアドバタイジングイニシアティブ(NAI)が「Firefox」向けのアドオンである「NAI Consumer Opt‐Out Protector」試験版の提供を開始。NAIの会員社のオプトアウトクッキーの不意な削除を防いで、行動履歴に基づく広告配信からのオプトアプトを維持する。
こういう活動が日本にはない。もしくは、あるのかもしれないが外から見えない。(良心的な広告事業者がそういった策を提言しているかもしれないが、表沙汰にならない。)
ヒアリングでは、次の意見も述べた。
「ライフログ活用サービス」と称すのだから、利用者の望むものを提供しているという建前であるはずだ。であれば、どれが行動ターゲティングの結果なのかを明示することに、何ら臆することはないはずである。
また、配慮原則案は「広報、普及・啓発活動の促進」も謳っているが、残念ながら広報・啓発活動には全く期待できないわけで、そういう状況で、表示された広告自身にそれが行動ターゲティングの結果である旨を示す表示がついていれば、消費者は自然にそれが何なのかを学ぶことができるだろう。
日本で広告業界の自主取組みが活発化しないのは、消費者がものを言わないからだろうが、日本では、ものを言わないというのは、必ずしも不満を抱いていないということではない。もし本当に「ライフログ活用サービス」が消費者の望むものであるなら、ちゃんと事実を説明していけばいいはずで、広告業界と消費者のウィンウィンの関係を築けるはずだろう。
米国では、既にこうしたマーク(アイコン)表示の計画が推進されているようだ。
Trying to ward off regulators, the advertising industry has agreed on a standard icon ― a little “i” ― that it will add to most online ads that use demographics and behavioral data to tell consumers what is happening. (略)
Most major companies running online ads are expected to begin adding the icon to their ads by midsummer, along with phrases like “Why did I get this ad?”
When consumers click on the icon, a white “i” surrounded by a circle on a blue background, they will be taken to a page explaining how the advertiser uses their Web surfing history and demographic profile to send them certain ads.
私のヒアリングでの提案は採用されることはなかったが、報告書案では脚註64に次のように記載された。
64 一部の構成員から、どの広告が対象情報を活用した行動ターゲティング広告等なのか、利用者に容易に認識かつ理解できるようにすべきとの指摘があった。
この提案が受け入れられないとすれば、「利用者の望むものを提供」というのは実は嘘で、本当は皆が嫌がることをやろうとしているのを自覚しているということではないか。
そういう意味で次の意見も述べた。
残念ながらこの意見は採用されなかったが、ヒアリングの席では、事業者の出席者からも「ライフログ」という言葉はおかしいという発言が相次いだ。行動ターゲティング広告を指す言葉として英語圏では通用しないため、ビジネスに支障が出るという。
いったい誰が、行動ターゲティング広告のことを「ライフログ」などと言い出したのだろう? 最初に言ったのは誰? 「マイ・ライフ・アシスト」のようなサービスは「ライフログ」と言ってもよいだろうが、それはオプトイン前提だからだ。
さて、私としては本命の提案は次のものであった。
残念ながら、私が呼ばれたのはWG最終回の直前なので、この検討をする余地はなかったと思われる。パブリックコメントにかけられた報告書案では、脚註63で次のように記載されるにとどまった。
63 保存期間には、端末等の識別を継続して行う期間と、蓄積した対象情報を保管する期限の2つがある。
ヒアリングに呼ばれて感じたのは、WGのメンバーは技術的なことをわからずに話しているらしいことだった。メンバーは弁護士や法学研究者、事業者は法務担当者ばかりで、オプトアウトcookieが識別性ゼロであることさえわからない*3まま議論になる一幕もあった。(詳しいことをここに書くのはやめておこうと思う。)
そんなことでは、落とし所を導くことができずに、「消費者優先か事業者優先か」「全否定か全肯定か」の言い合いにしかならないのもしかたないと思った。
*1 ちなみに、Yahoo! JAPANのオプトアウト手続きについて同じ日に確認したところ、2037年までと無期限になっていた。
*2 ちなみに、このライブドアのオプトアウト用cookieの有効期限は、2008年12月の時点では1か月だった。(「livedoorのad4U、拒否できるのは「1ヶ月」だけ」, xenoma日記, 2008年12月13日)
*3 フラグという概念がわからなかったらしい。
KDDI社員の方からタレコミがあった。
従来、EZ番号は、EZオプションを廃止して再加入すると新たな番号が付与されるようになっていたのだが、5月10日から、同じ個人には同じEZ番号を継続して付与するよう、システム変更があったという。その意図は、「EZ番号変更による問題行為の防止」だという。電話番号を変更してもEZ番号は変わらないようになったという。
エンドユーザのプライバシーにかかわる仕様変更であるにもかかわらず、プレスリリース等を出さずこっそり変更していることから、私から注意喚起をしてほしいとのことだった。
この情報は、とくに隠されているものではなく、聞かれたら答えられるよう各種窓口に周知されているものだそうで、以下のチラシが店頭掲示用として配布されているようだ。
KDDIのこの措置が誰の要求に応じたものなのかは知らない。
2ちゃんねるを調べてみたところ、以下のやり取りがあった。
205 :reffi@報告人 ★:2010/05/10(月) 20:01:26 ID:???0
>193
こちらでも確認しました。
これでは解除は難しいのでもうちょっと具体的な内容について問い合わせてもらいませんか?
(安易にEZ番号を変えてくるようなユーザーに対する対策等)
難しい交渉になると思いますがよろしくお願いします。>葱@報告人 ★さん
225 :葱@報告人 ★:2010/05/10(月) 22:10:13 ID:???0 ?2BP(2450)
おつかれさまです。
>>205
> 安易にEZ番号を変えてくるようなユーザーに対する対策等
従来のように個別に焼くだけならそのような対策も必要かと思うのですが、
\.ezweb.ne.jpとして一括規制するのにそのような対策をお聞きする必要はあるでしょうか……
それを言い出したら、変動しやすい動的IPアドレスを提供しているすべてのISPに
「繋ぎかえを繰り返すユーザーに対する対策」
をお聞きする必要がある気がします。「どうしても」とおっしゃるなら、先方に問い合わせいたしますが、
正直、携帯キャリアに対して厳しすぎるような気がしてなりません。大変失礼かとは存じますが、御一考いただけないでしょうか。
227 :reffi@報告人 ★:2010/05/10(月) 22:22:51 ID:???0
>225
単なる繋ぎ替えならユーザーは追いかけられるので再発した場合でも厳しく対応が出来ます。
携帯の場合、簡単に固有番号そのものを変えられてしまうのでその辺の対策について
問い合わせてほしいのです。
前回と同じような回答で解除したのではすぐに再発する可能性が高いのでもう少し
具体的な回答がほしいのでよろしくお願いします。
230 :名無しの報告:2010/05/10(月) 22:26:37 ID:+EKWuy6BP
>>227
EZ番号は今日から固定化になったようです
http://ktaimobilegadget.blog88.fc2.com/blog-entry-1211.html
235 :名無しの報告:2010/05/10(月) 23:02:13 ID:HdaY8zS30
こんばんは。
EZ番号の変更についてauホームページより転載です。
ttp://cs119.kddi.com/faq/1032/app/servlet/qadoc?QID=000021
>Q:EZ番号(固体識別番号)を変更したい。
>A:「EZ番号」(固体識別番号)はau電話ごとに割り振られており、変更することができません。
>>230のブログの通り本日よりEZ番号の変更は出来なくなったようです
これでもauの対策は不十分なのでしょうか?
やはり私個人やブログからの情報ではなくauから運営側への正式な返答が必要なんですかね?
236 :reffi@報告人 ★:2010/05/10(月) 23:04:32 ID:???0
>235
そういうことです。
正式に回答が来てから再度判断しますが対策が講じられていた場合は解除します。
247 :葱@報告人 ★:2010/05/11(火) 06:48:48 ID:???0 ?2BP(2450)
>>227
了解しました。少しいろいろ調べた上で後ほど問い合わせいたします。
あとは何かお聞きしたほうがよい点あるでしょうか?
248 :名無しの報告:2010/05/11(火) 08:33:07 ID:+SvVvs4eQ
>>235
auのホームページには以前からEZweb番号は変えられないと書いてあるのでは。
これは、EZwebを解約して再加入すればEZweb番号は変わるが、解約および再加入をしないでEZwebを契約してる状態ではEZ番号を変えることはできないという意味だと思います。
2chはau携帯をEZweb番号でピンポイント規制してるのでEZwebの解約→再加入でピンポイント規制を解除できてしまいます。
>>230に貼られたサイトには5月10日から EZwebの解約→再加入 をしてもEZweb番号が変わらなくなると書かれていますが、その根拠(ソース)は書かれていません。信用できる情報なのでしょうか?
295 :葱@報告人 ★:2010/05/12(水) 11:50:45 ID:???0 ?2BP(2450)
おつかれさまです。
>>205,225,227,247
大変遅くなりましたが、送信完了しました。なお、今回お聞きした内容は以下の通りです(メールより一部転載、原文ママ)。
=====
1.貴社公式webサイトにおいて、「EZ番号は変更できない(*1)」という記載がありますが、
これは「電話番号の変更(*2)」や「EZ WINコースの解約→再契約(*3)」等を含まないのでしょうか。2.外部の非公式webサイト(*4)より、「2010年5月10日よりEZ番号が固定化」「EZwebを解除、再加入しても
再度同じEZ番号が割り当てられるシステムに変更」というような情報が流れておりますが、これは事実でしょうか。3.「電話番号の変更」や「EZ WINコースの解約→再契約」でEZ番号が変わる場合、
安易にEZ番号の変更を繰り返すユーザーに対して、何か対策などを実施していらっしゃるでしょうか。
また、その対策内容について具体的に教えていただけないでしょうか。4.何らかの事情でEZ番号が変わる場合、新しいEZ番号で変更前のEZ番号迷惑行為歴を追うことは可能でしょうか。
5.何らかの事情でEZ番号が変わる場合、変更前のEZ番号が他のユーザーに割り当てられることはないでしょうか。
6.何らかの事情でEZ番号が変わる場合、新しいEZ番号はアトランダムに割り当てられるのでしょうか。
もし変動範囲がありましたら、それについて教えていただけないでしょうか。
【例】_△△.ezweb.ne.jpの部分は固定、等7.今回ご回答いただく情報について、当掲示板上で公開させていただくことは可能でしょうか。
【参照URL】
(*1)http://cs119.kddi.com/faq/1032/app/servlet/qadoc?QID=000021
(*2)http://cs119.kddi.com/faq/1032/app/servlet/qadoc?QID=000757
(*3)http://www.naruhodo-au.kddi.com/qa2950935.html(非公式情報)
http://parame.mwj.jp/blog/0273(非公式情報) など他多数
(*4)http://ktaimobilegadget.blog88.fc2.com/blog-entry-1211.html(非公式情報)=====
305 :葱@報告人 ★:2010/05/13(木) 09:54:15 ID:???0 ?2BP(2450)
おつかれさまです。
KDDI株式会社様より、>>295についてご回答をいただきました。
残念ながら内容の公開許可はいただけませんでしたので、返答内容の転載は差し控えます。ezweb.ne.jp 規制
http://qb5.2ch.net/test/read.cgi/sec2ch/1262876159/22-23
http://qb5.2ch.net/test/read.cgi/sec2ch/1262876159/24-25
http://qb5.2ch.net/test/read.cgi/sec2ch/1262876159/26-27
http://qb5.2ch.net/test/read.cgi/sec2ch/1262876159/28-29
\.ezweb.ne.jp (全サーバ規制) ※永久規制
306 :reffi@報告人 ★:2010/05/13(木) 10:33:32 ID:???0
>305
こちらでも確認しました。
代理人経由で最終判断を仰ぎますがこの内容でしたら解除できると思います。
KDDIから回答があったようだが、内容の公表を拒否されたようだ。なぜ公表を拒否するのだろう。
ちなみに、227は言っていることがおかしい。ケータイだと追いかけられないが一般のISPなら追いかけられるというのは、どういうことなのか?
こんな調子で、ISP丸ごと規制(丸焼き)をチラつかせて、IPアドレスの固定化を各ISPに要求していったら、日本のインターネットはいよいよ終了する。
KDDI社員の方からの情報によれば、正確には以下のとおりであるとのこと。
(1)変更概要
【変更前】EZオプション再加入時に、EZ番号が新たに付与される。
【変更後】回線契約中はEZオプション再加入時も、EZ番号を継続使用する。(2)変更背景
「EZweb」オプションの廃止⇒再加入等で「EZ番号」を変更し、SNSサイトで迷惑行為を繰り返すといった問題行為も確認されている場合がある事から、迷惑行為対策としてシステム改修します。(3)変更日
5月10日(月)受付分以降(4)変更該当申込種別
1.契約内容変更:EZwebオプションに再加入/EZwebオプションを廃止→取消した場合。
2.機種変更(端末増設):機種変更(端末増設)と同時に上記契約内容変更の処理を行った場合。
3.一次休止再利用:一次休止前にEzwebオプションに加入していた回線を再利用しEZwebオプションに再加入した場合。
4.一次休止・解約:Ezwebオプション加入中の回線を一次休止・解約し、その申込を取消した場合。
5.電話番号変更:電話番号変更をした場合。
※譲渡/承継の場合は現状通りEZ番号は変更されます。
「ユーザより業者最優先で本当にいやになります」とのことだった。
ろくに安全な作り方も確立していないくせになぜかやたら蔓延ってしまった「簡単ログイン」。そもそもUI設計からしておかしい。ボタンを押せば入れるなら、ボタンがある意味がない*1。ログアウト不可能な常時ログインサイトだ。(それなのに「ログアウト」ボタンがあったりする。)
「そんなこと言ったって便利だから必要なんだ」とか、「ケータイでパスワードなんか入れてられない」だとか、「お客さんが付けてくれって言ったら俺たちIT土方には何も助言なんてできないんだ」とか言う人が出てくるわけだが、そんなのは、一般のインターネットのサイトだって、昔から「□ 次回から自動的にログイン 」とか「□ 次回から入力を省略」といったチェックボックスが普通に用意されている。amazon.comなんか大昔からログインしっぱなしだ。
そしてそれはcookieによって実現されてきた。個人識別番号なんぞ使っちゃいない。日本だけこんなことになってしまったのは、docomoの旧型端末「iモード1.0」が永らくcookieをサポートしていなかったからにすぎない。
でも、最近のdocomo端末はcookieをサポートしている。では、現時点でcookieの使える端末は全体の何割くらいだろうか。この点について、モバツイの藤川真一氏が調査してくださった。
この結果を私なりにまとめなおすと次のようになる。
docomo | au | SoftBank | 全体 | |
---|---|---|---|---|
有効 | 648 (28.0%) | 1710 (99.9%) | 606 (98.7%) | 2964 (63.9%) |
無効 | 1667 (72.0%) | 1 (0.1%) | 8 (1.3%) | 1676 (36.1%) |
合計 | 2315 (100%) | 1711 (100%) | 614 (100%) | 4640 (100%) |
SoftBankにはcookieをオフに設定している人が少しいるということだろうか。そして、auにはcookieをオフにする機能がないのだろうか。おそらくこれらは全ての端末でcookieが使えると思われる。そして、docomoのcookie対応率は28%。cookieが使えないことがあるのはdocomoだけであることが改めて確認された。
全体では64%がcookieに対応していたということになる。今後この割合は、iモード2.0端末の普及とともに増えていくだろう。数年後には、簡単ログインの実現という点からは、個人識別番号は不要になると考えるべきである。
今週の土曜日、コクヨホールで「WASForum Conference 2010」が開催されます。この中で、ケータイの認証に関する講演があります。
野村総研の崎村様には、認証基盤連携フォーラム*2でのお取組みをご紹介頂きつつ、OpenIDのモバイル対応についてご講演頂きます。この話題は、日本のWebアプリケーション界における、認証方式の近未来を占う、重要な鍵となるかもしれないと私は考えています。
HASHコンサルティングの徳丸浩様からは、「ケータイ2.0が開けてしまったパンドラの箱」と題して、簡単ログインが危うい綱渡り状態になっていることについてご講演頂きます。
また、私からも、「どうするケータイ認証」として、簡単ログインやめようキャンペーンについて、その背景、趣旨、今後の見通しについてお話しします。
*1 元々は、番号送信時に確認ダイアログがポップアップするdocomoの「UTN」を用いた方法のために設計されたUIだったのだろうが、iモードIDが使われるようになった今となってはナンセンス。なぜそれに気づかないのか。
*2 認証基盤連携フォーラムは、総務省の「通信プラットフォーム研究会 報告書」の結論「認証基盤の相互運用性の確保に向けた検討を行うため、行政当局が関係者で構成する 「認証基盤連携フォーラム(仮称)」を設置」に基づいて設置されたフォーラム。
オレオレ証明書ではないSSLサーバ証明書は、2つの独立した機能を果たしていると言える。1つ目は、SSLプロトコルによるサーバとクライアント間の暗号化通信のために不可欠な役割であり、2つ目は当該サイト運営者の実在証明の機能である。ただし、今日では、後者を含まない、前者だけのサーバ証明書もある。
後者の実在証明は、かつては認証局サービスを提供する各事業者がそれぞれの独自の基準で、サイト運営者の実在性を確認、認証していたが、それでは利用者にわかりにくいことから、認証の際の実在性確認の方法が標準化され、誕生したのがEV SSLであった。
その結果、VeriSignなど、古くから実在証明に力を入れていた認証局サービスでは、EVのものとEVでない実在証明付きサーバ証明書の2種類が存在することとなった。VeriSignでは、EV証明書の提供開始後も、EVでない実在証明付きサーバ証明書の提供も続けている。
VeriSignは、実在証明のないサーバ証明書を提供するGeoTrustを2006年に買収したことから、今では、3種類のサーバ証明書を提供することになった。その結果、その違いを説明する必要に迫られることとなり、日本ベリサイン社は、実在証明の意義を以下のように説明している。
実在証明を必要とするケースと不要なケースが説明されているが、付け加えて言えば、不特定多数向けのサービスであっても、ドメイン名が広く知られている場合には、実在証明はなくてもよいと思う。また、実在証明を本当に必要とする場面として、マイナーな中小企業が運営するネットショップのケースがあると思う。
基本的に、SSLで安全な通信(偽サイトへの送信を防ぐ意味を含めて)ができるのは、以前訪れたことのあるサイト(ドメイン名や会社名を覚えているサイト)か、元々運営者のことをよく知っている場合のいずれかである。初めて訪れたサイトで、運営会社のことをよく知らない場合、本来は安全な通信は実現しようがない。
しかし、そんなことを言えば、マイナーな中小企業はネットショップを運営できなくなってしまう。そこで、そのような場合に、実在証明付きのSSLサーバ証明書を使うことで、結果的に、そのサイトの運営者について、ある程度の信用性が確認できる……と考えることができる。
VeriSignが古くから「VeriSign Secured Seal(ベリサインセキュアドシール)」を提供しているのは、そうした状況における、運営企業の実在証明のためだったはずだ*1と私は思う。
というように、VeriSignシールは、SSL暗号化通信には何の意味もないとよく言われるけれども、一応、中小企業向けに運営者の実在証明として意義をなしていると思う。
ところが、シールの意味が正しく理解されておらず、不正に貼られている事例があるようだ。以下は、私が作成した入力フォームだが、本物のVeriSignシールが貼られている。(もちろん、ここに入力されたデータは私の手中に入る。)
シールをクリックすると、「フォームメーラー」という、誰でも無料で入力フォームを設置できるサービスの運営会社の名前が表示される。カード番号を盗むような入力フォームを設置されたとき、この会社は責任を負うつもりなのだろうか。
この「フォームメーラー」は、昨年6月27日の日記「EV SSLを緑色だというだけで信用してはいけない実例」でも取りあげた。その後、このサービスはEV SSLの提供を中止していた。
中止したのはよかったが、なぜ中止しなければならないのか、その意味を理解していなかったようで、その後、2009年9月から、VeriSignシールを貼付ける機能が付け加えられていた。
入力画面にSSL シールを表示することができるようになりました。
そもそも「SSLシール」じゃなくて「VeriSignシール」だ。この会社はSSLが何なのかまるで理解していないようで、以下のように宣伝している。
「ベリサインのSSL」などというものがあるわけじゃない。SSLは単なるプロトコルの名前であって、VeriSign社が発明したわけじゃないし、どこの証明書を使おうが暗号化の強さに関係ない。
加えて言えば、図2の画面に書かれている「全世界標準の認証ガイドラインに基づいて発行されるSSL証明書なので」というのは、EV SSLの説明であって、このサービスはもうEV SSLの提供をしていないのだから、これは虚偽の商品説明ということになる。
ちょっと自分の頭で考えてみたらどうだろうか。
どのくらいおかしい話かは、このサービスを紹介した以下の個人のブログでわかる。
「フォームメーラー」を使って、友人のセミナー申し込みフォームを作ってみた。(略)運営元の組織の検証を行った上で証明書を発行しているので、安心して個人情報の通信ができる。
[VeriSign Secured Sealの例]
米国のVerSign社は、こうした不正なシール使用をやめさせる通報窓口を設けているが、日本ベリサインはそうした取り締まりをしないのだろうか。こういう使われ方を放置したり、「ベリサイン社のSSL」といった幻想が広がるのを(これ幸いとばかりに)放置すれば、結局はいずれ、VeriSignブランドの信用低下を招くのではないか。
もっとも、VeriSignの証明書発行事業は、Symantecに買収されることになったそうで、シールもSymantecのロゴに変更されるらしい。この際、わけのわからないシールの幻想から、バッサリおさらばした方がいいのではないか。「シマンテック社のSSL暗号化通信」という表現は胡散臭い。
シマンテックの買収後はベリサインのブランドを統合した、プレミアムの高いブランドを醸成していくとのこと。そのため、買収後にはロゴの変更も行なわれ、ベリサインロゴのチェックマークがシマンテックロゴに統合される予定となっている。
もし今後、シマンテックがSSLについて少しでも虚偽を含む解説を出してきたら、私は厳しく追求していくつもりだ。
*1 したがって、ドメイン名や会社名が著名で、元々よく知られた企業が、VeriSignシールを貼っている場合があるとすれば、マヌケだと思う。
この記事が今日の朝日新聞朝刊1面に出ている。紙の方の記事では「行動ターゲティング広告」と「米英では頓挫」のキーワード解説が載っている。
これは、総務省の「利用者視点を踏まえたICTサービスに係る諸問題に関する研究会 第二次提言」のことだろう。「ライフログ活用サービスに関する検討について」の中に「ディープ・パケット・インスペクション技術を活用した行動ターゲティング広告について」という節がある。(電気通信事業者の取扱中に係る通信の傍受のことを指して「ライフログ」を呼ぶのには強い違和感があるが。)
この提言は、4月9日から5月10日にかけてパブリックコメントにかけられていたので、私も意見を提出した。提出した意見は以下のとおり。
■意見2: DPI広告事業者の透明性は検証不能であるから第三者による監査を義務付けない限り実施を認めるべきでない
(ライフログ活用サービスに関する検討、DPI技術を活用した行動ターゲティング広告)理由
提言案は、DPI技術を活用した行動ターゲティング広告(DPI広告)の実施は、通信当事者の同意がない限り、通信の秘密の侵害行為であって違法性も阻却されないとしており、その通信当事者の同意についても、「その意味を正確に理解したうえで真意に基づいて同意したといえなければ有効な同意があるということはできない」としている。この点について、提言案は、最後の段落において、同意にあたっての判断材料として、「利用者に対してサービスの仕組みや運用について透明性が確保されるべき」とし、「各事業者は、透明性の確保に向けて運用にあたっての基準等を策定し、これを適用することが望ましい」と結んでいる。
そのような結論に従う場合、DPI広告を提供する事業者は、おそらく、そのサービスがいかに利用者のプライバシーに配慮したものであるかを説明し、たとえば「Webメールの内容については傍受しない」といった説明をして、利用者の同意を得ようとするであろう。また、利用者も、そのような配慮がなされているからこそ、同意してオプトインできるものと考えられる。
しかし、DPI広告の場合、そのような配慮が本当に実施されているかは、外部からは誰にも検証できない。これは、従来の行動ターゲティング広告にはなかった新しい事態である。従来の行動ターゲティング広告では、専門家がWebブラウザの挙動等を調べることによって大方その影響範囲を推定できるものであった。それに対し、DPI広告のシステムは、実際に何をやっているかは事業者のシステムに侵入して調べるなどしない限り第三者には検証できないものである。
そのような検証不能なシステムについては、事業者の説明があるからといって透明性が確保されたとは言えず、通信の秘密という重大な事項についての同意にあたっては、その程度の透明性で有効な同意があったと見なすべきではない。
したがって、DPI広告実施事業者の説明が真実であることを検証する第三者による監査を義務付けない限り、このようなサービスを合法と認めるべきではない。
つまり、10年前に登場したDoubleClick等の方式や、一昨年の「楽天ad4U」のケースなどでは、Web技術者が解析すればそこで何が行われているか、そして、何は行うことができないものなのかを調べることができたのに対し、電気通信事業者によるDPIでは、基本的に何でも可能なのだから、たとえば「Webメールの内容は見ていない」と言われても、本当にそうなのかは、私たち一般市民からでは調査することが不可能である。だから、法的権限を持った機関による監査が不可欠であるとした。
実際にそんなことが必要なのかといえば、日本のIT事業者は、これまでにも、プライバシーポリシーの記述においてcookieの説明が出鱈目だった前歴があるわけで、cookieが何かもわからないような技術に暗い法務の人々がそれを書いているために、嘘をつくつもりがなくても、利用者を怖がらせたくないという一心で、事実と異なる説明を書いてしまうという展開が、容易に予見されるところである。
欧州なら、もし今後オプトイン方式で実施する事業者が現れたなら、プライバシーコミッショナーが法的権限の下、第三者監査を義務付けるのではないだろうか。
この提出意見に対し、5月26日に公表された「提出された意見及びそれらに対する考え方」は、以下のように答えている。
ご指摘のとおり、DPI技術を活用した行動ターゲティング広告の実施に当たり、例えば有効な同意を得ずにパケットの解析を行う等、事業者が通信の秘密を侵害していたとしても、外部からの観察が容易でない場合があり得ます。しかしながら、通信の秘密の侵害行為には刑事罰が規定(電気通信事業法第179条)されており、一般予防の効果が期待されると考えます。
この意見に対してこの回答ということは、当該電気通信事業者の利用者への説明に1つでも事実でないことが書かれていたなら、刑事告発できるということだろうか。(そうでないとすれば回答の意味がわからない。)
それはそれで新しい展開が訪れるのかもしれない。