<前の日記(2003年08月15日) 次の日記(2003年08月17日)> 最新 編集

高木浩光@自宅の日記

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

2003年08月16日

理解せずに語られているcookieのプライバシー性

総務省のサイトに「電気通信サービスFAQ」というページがある。「5−1 携帯電話は誰かに盗聴されたりする心配はないのですか。」などは、総務省の公式な見解として読むと興味深い。

このFAQ、よく書けているところと、そうでもないところがあって、それぞれ担当した人が別なのかなあとも感じられるのだが、それはともかく、第5章「通信の秘密、個人情報保護 」に、「クッキーとは何ですか。クッキーを受け取らないようにすることは可能ですか」というQがある。

小さなデータ

回答の冒頭にはこう説明されている。

クッキーとは、ホームページを置いているサーバコンピュータが送信した情報をインターネットの利用者のパソコンに保存させ、その利用者が次に同じホームページにアクセスした時に自動的に保存された情報をサーバに送信するシステムのことをいいます。

総務省 電気通信サービスFAQ

この説明は正しい。続く部分、

このシステムの機能は、利用者の情報に固有の番号を振り、利用者が入力した情報の一部をサーバに覚えさせておくことで、その利用者が次回にそのホームページにアクセスした時にその情報を利用して、入力すべき情報を省かせたりします。

総務省 電気通信サービスFAQ

ここもおおむね正しい。

正しいのが当然なのになぜこれを取り上げるかというと、あまりにもいいかげんなcookie解説が巷にあふれているため、この正しい説明が珍しく見えてしまうのだ。いいかげんな解説はプライバシーポリシーや個人情報保護方針の文中に見られる。例えば、「クッキー 小さなデータ」で検索してみると、わらわらと変な解説が出てくる。典型的な文章はこんな感じだ。

クッキーは、ウェブサーバーからブラウザに送信される小さなデータです。

データが小さいかどうかは、プライバシーに何ら関係がない。総務省のFAQにあるように、サーバが発行し、ブラウザが受信して保存し、後に同じサイトにアクセスするときに自動的に送り返されるところに、cookieの本質がある。プライバシーポリシーを書く立場の職種の人たちは、cookieがどういうものかわからないままに書いている(書かされている)ことがあるのだろう。

「技術的に不可能ではない」?

そういうわけで、「電気通信サービスFAQ」のこのcookie解説は、きちんと技術的な仕組みを理解した方によって書かれたものと思われる。ところが、続く部分がちょっと変なのだ。

利用者がこの機能を正しく認識して使用すれば便利なものですが、ホームページの中には、利用者のパスワードなど必要以上の情報を保存させる場合があり、他人が利用者のパスワードを読むことも技術的に不可能ではありません

総務省 電気通信サービスFAQ

「技術的に不可能ではありません」と言うと、まるで、どうやっても防げない話のように聞こえる。実際には、セキュリティホールがない限り、他人にcookieを読まれることは起こりえない。cookieを盗まれるセキュリティホールは、ブラウザにある場合もあれば、サーバ側のWebアプリケーションにある場合もある。cookieは、中身がパスワードだろうが、単なるセッションIDであろうが、他人に読まれることはあってはならないものであり、それが起きるのは何らかの欠陥があるということだ。

とはいえ、実際問題として、ブラウザやサーバ側にセキュリティホールが残っていることも避けられない現実であるとして、ユーザ向けにそのリスクを説明することの意義はあるのであるから、そのような意図で書かれた解説なのかもしれない。ただ、仕様上の話と、欠陥がある場合の話は区別して説明するべきだ。なぜなら、欠陥があるならまず欠陥を直すことが第一だからだ。

で、この日記で言いたいのはその話ではない。なぜ、欠陥の存在を前提とした話を、「技術的に不可能ではない」という不用意な表現で書いてしまったのだろうか、ということだ。 これを私は次のように憶測する。

よくわからないが問題があるらしい

そもそも、cookieの話を「通信の秘密、個人情報保護」というFAQに書くからには、プライバシー上の問題点について書かないわけにはいかない。ブラウザにcookieの受入れを拒否する設定機能が存在するという事実から、cookieがプライバシーに何らかの影響があるらしいことは確かだ。そこで捻出されたのが、「他人が利用者のパスワードを読むことも技術的に不可能ではありません」という想定ではなかろうか。

つまり、このFAQの著者は、cookieの動作原理は理解しているものの、cookieがなぜプライバシー上の問題のあるものとされているのか、その本当の理由を理解していないのではないかということだ。

cookieの本当のプライバシー問題(のうち最も重大なもの)は、「第三者cookie」によるユーザ追跡効果にある。

第三者cookieとは、ユーザが今見ている画面のURLとは異なるドメインのサーバから発行されてくるcookieのことを指す。具体的には、たとえば、ページ中に貼り付けられた画像だ。HTMLの仕様上、画面を構成するHTMLの置かれているサーバとは別のサーバに置かれている画像ファイルを、ページ中に貼り付けることができる。このとき、画像を供給するサーバ(第三者のサーバ)がcookieを発行していると、ブラウザはそれを自動的に受け付けてしまう。これを「第三者cookie」と呼ぶ。

予測できなかった第三者cookieの乱用

第三者cookieの応用として最も多いのが、「バナー広告」だ。バナー広告の画像(Flashコンテンツでもよい)は、通常、広告業者のサーバに置かれていて、広告を掲示するページでは、その画像へのリンクが張られている。

広告業者がバナー広告の画像にcookieを発行する理由は、第一には、閲覧者に効果的な広告の見せ方をすることにある。たとえば、同じ閲覧者に同じ広告を何度も何度も見せても効果が薄いかもしれないし、閲覧者が既にクリックしたことのある広告を再び同じ閲覧者に見せても無駄に終わるかもしれないのだから、できるだけ新しい広告を見せるようにした方がよい。そうした仕組みは、cookieを使うことで簡単に実現できる。閲覧者ごとに固有の固定IDを、cookieとして発行すればよい。あるIDの人からアクセスがあったとき、そのIDの人に過去にどんな広告を見せたかを調べて、適切な広告画像を返すようにすればよい。

広告業者は、一社で、非常に多くのサイトに広告を流している。広告業者は、各閲覧者が過去にどこのサイトを訪れているかを、広告画像の Referer: フィールドの記録から知ることができる。これを活用すれば、各閲覧者のアクセス嗜好に応じた広告を選んで流すこともできる。普段ポルノサイトに行くことの多い人は、食品販売のサイトに行ったときにも、ポルノ系広告が現れるということが起こり得る。

もし10万か所のサイトに、同一広告業者のバナー画像が貼り付けられていたならば、その広告業者は、それぞれの人たちがその10万か所にどのようにアクセスしているのかを知ることができてしまう。IDだけでは、それが誰のIDであるかは不明だが、その10万か所のうちのどこかで、ユーザが個人情報を登録していて、それと広告のIDとが突き合わされる事態が起きれば、それが誰であるかも判明してしまう。

これが「第三者cookie」のプライバシー問題である。これが一部の特殊な人たちにだけ懸念されている問題というわけではないことは、最近のブラウザのcookie設定の画面を見れば明らかである。以下のように、NetscapeにもInternet Explorerにも、第三者cookieは、通常のcookieとは別に許可・拒否の設定ができるようになっている。IEでは、第三者cookieは「サードパーティのCookie」と表記されている。

cookieの機能を最初にブラウザに取り入れたのはNetscapeだった。彼らは、cookieなどという複雑な仕組みを編み出さなくても、ブラウザに固定IDを埋め込むだけで目的を果たせたはずだが、それをしなかった。それは、固定IDがプライバシー上の問題があるという見識を持っていたからだろう。だが、そんな彼らにも予測できなかった使われ方をしてしまった。それが、第三者cookieのサイト横断的利用だった。当初予想できなかった問題が起きれば、ブラウザ側で新たな対策をとる。それが上の新しい設定画面だ。

蚊帳の外だった日本が初めて患う大人の麻疹

FAQの文章に戻ると、

このシステムの機能は、利用者の情報に固有の番号を振り、利用者が入力した情報の一部をサーバに覚えさせておくことで、その利用者が次回にそのホームページにアクセスした時にその情報を利用して、入力すべき情報を省かせたりします。

総務省 電気通信サービスFAQ

というように、cookieが固有番号を記憶するために使われていることは理解されているようだが、それ自体はプライバシー上の懸念をもたらすものではないとして説明されている。あくまでも、

ホームページの中には、利用者のパスワードなど必要以上の情報を保存させる場合があり、 総務省 電気通信サービスFAQ

というように、サイト側がcookieの使い方を誤って、パスワード(やユーザ名)をcookieに直接入れてしまっている場合にだけ問題が起きるとして書かれている。

こうした誤った理解は、総務省の担当者だけでなく、かなり広範囲の人たち(技術者を含む)に根強く残っているのではなかろうか。

このFAQの文章が総務省の総意を示すわけではないことは重々承知しているのだが、携帯電話事業の監督官庁である総務省の関係スタッフが、もし固定IDの問題を理解していないとすると、それはまずい。

EZwebの「サブスクライバーID」や、J-PHONEの「ユーザーID」は、その仕組みからして、第三者cookieと同じプライバシー問題を起こす能力を持ち、それどころか、cookieのようにID発行の準備をせずとも最初から電話会社から勝手にIDが送られてくるという点で、より性質の悪い仕組みになっている。

「電気通信サービスFAQ」でcookieが取り上げられているのは、「cookieにプライバシー問題あり」というのが、国際的コンセンサスとなっているからだろう。それに対し、携帯電話の簡易Web機能は、日本市場で先行して普及してきたため、まだ諸外国ではそのプライバシー問題がほとんど認識されていない。今後、欧米諸国に普及していったときに、消費者団体からのバッシングに遭い、政府の介入という事態にもなると予想される。

私が固定IDのプライバシー問題をここで書いているのは、私個人がプライバシーに敏感だからとかそういうことではない。セキュリティ問題を追いかけてきた経験から、国際的に何がプライバシー問題(どんな技術手法が禁じ手)として認識されているのかを、たまたま詳しく知る立場にあった。それがどうやら、肝心な人たちには理解されていないらしいことが、昨年あたりからわかってきたため、このままではまずいと思い、筆をとっているところだ。

日本は、これまで、こうした技術の標準化において蚊帳の外にいることが多かった。主なWebブラウザは日本製ではないし*1IntelのPentium IIIにIDを内蔵させて活用する件でも日本は蚊帳の外だった。固定IDにプライバシー問題があるという議論は、海外ニュースの翻訳版で対岸の火事として傍観する程度のかかわりしか持ってこなかった。「Webバグ」の議論だって日本のメディアが独自に取り上げることはなかった。日本にとってRFIDの今の議論は、大人になって今ごろかかった麻疹のようなものだ。

e-Japan重点計画-2003」では、「安全・安心」がキーワードとなっており、各技術でプライバシーを確保することが謳われている。国際的に恥をかくはめにならないよう、なんとか固定IDの問題を正しく認識した上での政策を進めていただきたい。そのためにはあらゆる協力を惜しまないつもりでいるのだが……。

と、こんなところで言っていてもはじまらないのだが。

補足

e-Japan重点計画-2003」のp.45に次の記述がある。

(2) インターネット端末やインターネット家電が普及し、それらがインターネットに常時接続されることを想定し、十分なアドレス空間を備え、プライバシーとセキュリティの保護がしやすいIPv6を備えたインターネット網への移行を推進する。

e-Japan重点計画-2003, III重点政策5分野, 1.世界最高水準の高度情報通信ネットワークの形成

IPv6が「プライバシーの保護がしやすい」ものだというのは、初めて目にした。どういう根拠なのだろうか。ちゃんとわかっている人が書いているのかどうか、不安になる。

「電気通信サービスFAQ」の別のページにはこんな記述もある。

4−4−4  自分のパソコンがコンピュータ・ウィルスに感染しないようにするには、どうすればよいのでしょうか。

○ パソコンがコンピュータ・ウィルスに感染すると、パソコンに保存してあるファイルが破壊されてしまうことがあります。このようなコンピュータ・ウィルスに対処するためには、市販のウィルス対策ソフトを活用し、ウィルスの侵入を防ぐことが大切です。

○ ウィルスは電子メールに添付されて侵入する場合が多く、添付ファイルを開くとパソコンがウィルスに感染してしまいます。そして、コンピュータの中のメールアドレスなどを参照して、勝手にウィルス付きの電子メールを送信し、知り合いにもウィルスの被害を広げてしまうことがあります。

○ 最近のウィルスは手口が高度化してきており、メールの添付ファイルを開かなくても、メールを読むだけで、あるいはWebを見るだけで感染してしまうようなケースがあります。 ○ このため、ウィルス対策ソフトを定期的に起動させて、ウィルスチェックを行うことをお勧めします。また、身に覚えのない相手や怪しい件名のメールが届いたときには、安易に添付ファイルを開かずに削除したほうがよいでしょう。

○ また、新しいウィルスが日々発見されている状況なので、ウィルス対策ソフトや、その定義ファイルの更新を常に行うようにすることが重要です。

○ プロバイダによっては、自動でメールのウィルス検査を行うサービスを提供しているので、こういうサービスを利用する方法もあります。

総務省 電気通信サービスFAQ

セキュリティホールの話や、パッチをあてよという話が全く書かれていない。これはちょっと愕然とする。

きっとこの文書は3年前くらいに書かれたものなのだろう。そのころは、こんな報道もあったくらいで、世間の認識はそういうレベルだった。

中央省庁などのホームページの不正書き換え事件で、15件のうち6件は、ハッカーがサーバーコンピューターに一度に大量のデータを送信して異常作動を起こさせる方法で侵入していたことが、15日までの警視庁麹町署捜査本部の調べで分かった。この方法は「バッファ・オーバー・フロー攻撃」と呼ばれる手口。大量のデータを受けたサーバーコンピューターからあふれ出たパスワードなどのデータを使ってハッカーが不正アクセス用の「裏口」を作り、管理者になりすましてホームページを書き換える。防ぐのは難しいという。

毎日新聞, 大量データ送り、異常誘う手口−−省庁ハッカー被害, 2000年2月16日

たった3年半前の話なのに、隔世の感がある。

まだこんなことを言っている人がいるよ その2

  • 菊田一郎, RFIDの実用化と セキュリティ問題, 月刊「マテリアルフロー」, 2003年8月

    タグには危ない情報を入れないこと
    ...

    いろいろなサイトの書き手が、すぐにあの小説「1984年」に出てくる、プライバシー情報を含む一切の支配者・ビッグブラザーを持ち出したりしています。

    RFIDタグに、商品名や製造日や原料や値段(上代・下代)やサイズ・色、といった全ての情報をそのまま書き込むのだろう、そんなこと他人に知られてはたまらない、と言う理解がまず頭にあるから、そうした反応になるのでしょうか。
    ...

    タグに入っているのは製品のシリアルナンバーだけです。数字の羅列。それだけでは意味がなく、製品情報・生産情報・流通情報はそれぞれの責任を担う企業のサーバに置き、ネットワーク経由で権利のあるものだけがアクセスできる方式を目指しています。
    ...

    てなわけで、...
    導入関連社側が根気よく、一般消費者に向けて説明していくことでしょう。

コメントは不要だろう。この人を理解させるにはどういう手段があるのか。

*1 例外はあるが。

検索

<前の日記(2003年08月15日) 次の日記(2003年08月17日)> 最新 編集

最近のタイトル

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月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|04|
<前の日記(2003年08月15日) 次の日記(2003年08月17日)> 最新 編集