高木浩光＠自宅の日記
2003年06月02日
■ 日本は平和なのか、それとも単に遅れているだけなのか
「巧妙化するPayPal詐欺」という記事が出ていた。引用すると、
オンライン決済サービス PayPal の口座番号とパスワードを不正収集する詐欺はますます巧妙になってきた。最近登場した詐欺メールは、「セキュリティ対策」と称して、PayPal ユーザーに金融口座番号の提示を求めている。 ... 詐欺メールには、個人口座情報の入力を要求する偽サイトへのリンクも記されている。
とある。この記事からリンクされている昨年9月の記事「PayPal、詐欺メール攻撃の標的に」には、次のように書かれている。
この偽サイトは、セキュリティ対策が施された PayPal のサイトを装っており、アドレスも http://www.paypalsys.com/ で始まっているため、だまされやすい。
...
詐欺メールの手口はますます巧妙化しており、今では HTML 形式のメールで PayPal のロゴとタイプフェースがついたものが届くこともある。このようなメールには、セキュリティの鍵のマークまでついたサイトへのリンクが張られていたりもする。
本物のPayPalのドメインは、「paypal.com」だが、偽サイトは「paypalsys.com」だったそうだ。こうした偽メールに騙されないためには、消費者が、アクセス先のドメインを常に目視確認する習慣を身につけるしかない。5月21日の日記にも書いたように、それが基本中の基本だ。しかしどうだ、日本の銀行ときたら、アドレスバーを隠して、ドメインの確認をわざわざ難しくしている。すべての銀行がではないのだが、日経システム構築の調査によると、そうした銀行が32行も存在するという。
今後もし日本で同様の事件が起きたら、銀行側は、「システムに不具合はない」すなわち、騙される預金者の責任だとするコメントを発表するだろうと予想する。しかし、アドレスバーを隠したシステムは、こうした偽メールに騙されやすい顧客を自ら育てているものだ。こうした危険性は日本銀行主催のシンポジウムで1年以上前に指摘されている。「知らなかった」とは言えないだろう。対策はちっとも難しいことではない。アドレスバーを消すJavaScriptコードを削除するだけでよい。なのに、ちっとも改善される様子が見られない。
「日本は平和だな」と思うことがある。こうした事件の多くが日本以外で起きて、海外ニュースとして伝えられてくるからだ。「日本人のモラルが高いからなのか、検挙率が高いため犯罪が抑止されているからなのか……」と思わず考え始めてしまうが、そんなことはないだろう。架空請求の詐欺メールがいっこうに減らない。儲かるらしいとなると、こぞって模倣犯が現れる。けっしてモラルが高いということではなく、単に、そうした人物に技術的素養がないだけのように思える。
■ 「SSL-VPN」というネーミングセンス
このところ日経BP社がやたらと「SSL-VPN」なる製品をもちあげている。
- 日経システム構築: 新勢力●SSLでVPNを構築できる製品が相次ぎ登場
- 日経コミュニケーション: 【N+I Las Vegas速報】リモート・アクセスの主役となるか？。「SSL-VPNホット・スポット」が登場
- 日経コンピュータ: クライアントの設定が不要，VPN装置の新製品が登場
- 記者の目: リモート・アクセスVPNにSSLはいかが？
ようするに、Webブラウザさえあれば社内システムを出先から利用できるようにするシステムのことなのだが、ずいぶん以前から存在した、リバースプロキシタイプのシングルサインオンシステムと何が違うというのだろうか。
そもそもこれは、Virtual Private Networkではない。記事にも書かれているように、当然ながらWebブラウザでできることは限定される。おそらく、従来システムと異なる新しい機能は、Javaアプレットを使ったTCP接続の中継機能なのだろう。記事から引用すると、
すべてのアプリケーションを(1)で利用できればよいのだが，POP3やSMTP，telnetなどを使うアプリケーションからWebブラウザのSSL機能を利用することはできない。そこで考えられたのが，(2)の方法である。
(2)は，SSL-VPN装置からダウンロードしたJavaアプレットがサーバーの代わりとなってクライアントの通信を受け取り，SSLでカプセル化してSSL-VPN装置に渡す。
とある。この機能が付け加わったことで、Virtual Private Networkと呼ぶことが許されてしまうのだろうか。
VPNと言えば強固なセキュリティをイメージさせる。事実、VPNのソフトウェアにさえセキュリティホールがなければ、その安全性は社内からのアクセスと同等になる。それに対し、WebブラウザによるHTTPSへのアクセスでは、Webというシステムの脆さの影響を受けずには済まされない。「SSL-VPN」へのログインでセッション管理は何で行われるのか。cookieなのか、basic認証なのか、クライアント認証なのか？ 「Webブラウザが使える環境があれば，どこからでも社内のサーバーに接続できる」というくらいだから、クライアント認証は使わないのだろう。
複数のリバースプロキシタイプのシングルサインオンシステムに、セキュリティホールを見つけたことがある。ひとつは、展示会で当該製品の実演中にその場で穴の存在を確認し係員に指摘した。暗号化が意味をなさず、盗聴が可能な状況では、容易に内容を盗み見たり、アカウントを乗っ取ることができるものだった。Webの安全性というのはそんな程度のものなのだ。
「SSL-VPN」という名前付けには、VPNの安全性にタダ乗りしようとする魂胆が見え隠れする。
補足: 「Javaアプレットがサーバーの代わりとなってクライアントの通信を受け取り」というのもよくわからない。通常のJavaアプレットでは、サンドボックスセキュリティ制約により、ローカルホストからのアクセスを拒否するようになっている。それが可能だということは、署名アプレットであるはず。署名アプレットや署名ActiveXを使うのであれば、それは「専用ソフトをインストール」することと違いがないはずなのだが。
2003年06月05日
■ 明治記念館でRFIDセミナー
今日は、佐藤さん、山川さんとRFIDのセミナーだった。佐藤さんはRFIDタグの能力と特性を担当、私は技術面からプライバシーを、山川さんは法律面からのプライバシーを担当した。「RFID反応リンク集」のことをご存知という方に挙手をお願いしたところ、4〜5名程度だった。意外に少ない……と感じたが、世の中一般からすれば十分に多いか。
講演後、ご来場の方々と貴重なお話ができた。耳にしたのは、現場の個々の研究者や技術者には問題を認識している人も結構いるようだが、それがまとまった力になっていないという声。各社にばらばらに存在するそうした人材を活さねばという話。もうひとつは、法学者と技術系研究者の間の溝がとても深いという声。法学者も個人情報保護法のこともあり、RFIDのプライバシーについて議論することがあっても、理解がとんでもなくずれていることがあるという話。他には、研究部門と事業部に交流がなく、研究部門が問題解決を図っていても事業部が関心を示さないという話。残りの話は秘密だ。
■ 日経バイト「個人のプライバシは守れるか」
日経バイトから「カバンの中身が外から分かるICタグ 個人のプライバシは守れるか」という記事が出た。プライバシーの懸念には2つがあり、暗号化したIDでは一方しか解決しないこと、もう一方の解決には暗号回路が必要でコストが現実的でないこと、事実を周知する必要性について書かれている。
「IDを読み取るのにパスワードを設定する」というのは、スキャナ側が秘密情報を送って、それがタグ内蔵の値にマッチする場合だけ、応答をするという方式なのだろうか。
「（低価格路線で進める場合には）運用でプライバシを守ることを考えるべき」という文脈で、「ユーザー側で危険を避ける工夫もできる」を挙げているのは感心しない。セキュリティホールを指摘されたときに「ファイアウォールで防げるので告知だけして修正はしません」と開き直るのに近い。
電波到達範囲を短くするという対策案が書かれていないのはなぜなのだろう。アンチコリジョン機能を入れる場合に問題解決にならないからなのだろうか。
「スキャナの設置に規則を設ける」というのはどうなのだろうか。ユビキタスコンピューティングの研究者達は、街中にセンサーが遍在して、シームレスにその恩恵を受けられる世界を夢想しているわけで……。「スキャナを設置した場所はポスターなどでそれを明示する」というのは、販売店に設置する用途など、ごく一部のRFID用途だけを想定したもので、短期的な展望でしかないように思える。
2003年06月06日
■ HTMLメールマガジンをどうするか
先週から日経IT Proの「記者の眼」で、HTMLメールの是非の議論がヒートアップしていた。
前者は、「HTMLメールを拒否する人は少数に」なったので「HTMLメールに期待をかける事業者が急増している」という内容。これに、読者コメントが猛反発した。予想されていたことなのか記事の末尾には「来週，セキュリティの観点からも再度取り上げる予定」と予告されていた。その予告記事が後者の「HTMLはやめよう」だ。書いた記者が異なる。後者の著者は、IT Proでセキュリティ脆弱性の話題を追いかけてきた勝村幸博氏だ。すると、後者の記事にも反発コメントが寄せられた。代表的なコメントは、
このHTMLメールに対する批判は、非常に感情的で幼稚で間違ったものだと思います。企業は商業主義ですから、効果的なものを選ぶのが当然ですし、そこれそが資本主義の要です。それなのに、企業はHTMLメールの危険性を考慮するべきだ、とは、あまりに意味がなさ過ぎる提案です。時代は移り変わります。いつまでもHTMLメールを否定しているようでは、それこそ頭が堅いのではないでしょうか。
というもの。同趣旨のコメントが他にも複数見られる。
ここで注意したいのは、この議論はあくまで「HTMLメールマガジン」が対象という点である。つまり、個人間のHTMLメールのやりとりのことは議論の対象外だ。spamではなく、メールマガジンなので、オプトイン方式（受信者が望んで受け取っているもの）であるとする。
HTMLマガジンはWebサーバ上に置けばいい
さて、先に結論を述べておく。メールマガジンに視覚的な表現力を求めるなら、Webサイト上に（HTMLで書いた）マガジンを置けばいい。メールには、マガジンのURLだけ簡潔に紹介すればいい。たとえばこんな感じだ。
From: weekly-magazine@style.example.com
Subject: スタイルドットエグザンプル マガジン 第34号
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
スタイルドットエグザンプル マガジン 6月7日号
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第34号のメールマガジンをお届けします。
http://style.example.com/mag/0034.html
―――――――――――――――――――――――――――――
発行・編集： スタイルドットエグザンプル株式会社
配信の停止はこちら: http://style.example.com/unsubscribe.html
―――――――――――――――――――――――――――――
内容をこれだけにする。余計なことは書かない。
「こんなのメールマガジンじゃないじゃないか」と言われるかもしれないが、URLをクリック（ないしダブルクリック）すればマガジンを読める。「クリックしてもらえなかったら困る」と言われるかもしれないが、これだけ内容が簡潔だと、普通クリックするだろう。なにしろ、オプトインで受信しているのだから、無視することはないはずだ。マガジンのその回の表題をメールに書いてないところが重要だ。へたに表題を書くと、クリックしてもらえない可能性が増す。何も書いてないと、とりあえずクリックしてみるはずだ。クリックせずに捨てる人は、本来購読をやめているはずの人だ。
こう書くと、こう反論されるかもしれない。「わざわざクリックして見に行くはずがない。メールマガジンは受信し終えたものを、そのまま読むから効果的なのだ。ナローバンドのダイヤルアップ接続の購読者が、わざわざ回線をつないでアクセスしてくれるとは考えられない」と。
ちょっと待ってほしい。今はHTMLメールのことを話しているはずだ。ダイヤルアップ接続の人は対象としていない。HTMLメールマガジンのほとんどは、画像データをメール中に含めておらず、サーバ上の画像ファイルへのリンクを書いたHTMLを送信している（メールのデータサイズを小さくするためにそうなっている）。そのため、HTMLメールマガジンをメーラ上で表示させるとき、回線がつながっていないと画像が表示されない。HTMLメールマガジンは、購読者がブロードバンド常時接続環境であることを前提としているのだ。このことは、「HTMLメールが急増中」でも次のように書かれている。
こうした変化に大きく関係しているのが，ブロードバンドの普及である。平均的なHTMLメールのデータ容量は，100K〜150Kバイトと言われているが，ブロードバンドならば問題ない。また，HTMLメールでは画像をWebサーバーに置き，開封時にダウンロードするのが普通。オフラインでは画像が表示できないが，常時接続を実現するブロードバンドでは問題にならない。こうした回線環境の変化が，HTMLメールに対するユーザーの意識を変えたのである。
「こうした回線環境の変化」があるのだから、上の簡素なメールのURLをクリックすることなど、ごく自然に手が動くはずであろう。
そもそも、通常のWebサイト並の視覚的表現力を必要とする「チラシ」を、なぜわざわざメールで送ろうとするのか。そのままWebサイト上に掲示すればよいではないか。個人間メールと違って、チラシの内容は読者全員に同じ内容なのだから。メールは、チラシの最新号ができ上がったことを通知するためだけに使えばよい。メールで宣伝文句を送ろうなどというのは、ダイヤルアップ接続時代の都合で生まれた過去の遺物でしかない。
ここまでの議論で、「どっちでもよい」ということになる。あとは、HTMLメールでマガジンを配信することの問題点を示せばよい。
プライバシー問題
「HTMLメールはやめよう」の記事では、やめるべきとする理由として、主に「ウイルスの温床」を挙げている。Outlook Expressなどで、プレビューするだけで添付ファイルが起動してしまうことが問題だとしている。残念ながらこの根拠は弱い。それは仕様ではないからだ。
これはIEのセキュリティホールが原因なのであり、プログラムを修正すればその問題は解消する。この筆者は、修正していないユーザが現実に多いのだからと主張を続けるが、テキストメールでも、プレビューしただけで添付ファイルが起動してしまうセキュリティホールはあり得る。バッファオーバーフローが原因のものだ。事実、いくつかのメーラにはそうしたセキュリティホールが発覚している。たまたまそれを悪用したウイルスがさほど流行していないだけだ。
それでも現実にHTMLメールによるウイルスが多いのだから、HTMLメールをやめるべきだということなのだろう。私もそれに賛成だが、HTMLメールを否定する根拠としては弱い。
HTMLメールが否定される本物の根拠は、プライバシー問題である。「Webバグ」あるいは「Webビーコン」と呼ばれる問題のことだ。「HTMLメールはやめよう」の筆者の勝村氏は、このことについて次のように書いている。
HTMLメールにはウイルスの問題だけではなく，プライバシの問題もある。HTMLメール中にイメージ・タグを記述して，画像データを事業者のサーバーからダウンロードさせるようにすれば，サーバーのログからメールを“開封”したかどうかが分かる。ログからは，そのユーザーのIPアドレスが分かるだけだが，何らかの方法でユーザーの個人情報とひも付けることも可能だろう。
これには驚いた。あれだけセキュリティ問題を追いかけてきた勝村氏でさえ、Webバグのことを正しく理解していない。
Webバグの仕掛けられたメールをオンライン状態で表示したとき、発信元に通知されるのは、IPアドレスだけではない。受信者のメールアドレスが通知されるのである。実例で具体的に見てみよう。「HTMLメールが急増中」で取り上げられていた、「ファミマ・ドット・コム」のメールマガジンを早速購読してみたところ、HTMLメールの末尾部分は以下のようになっていた。
<img src="http://61.194.36.188/get_info.php?id=fami0602&send_id=b5b2...7934a&uid=4104"></HTML>
ここに私のメールアドレスは含まれていないが、「uid=4104」は私の会員番号だろう。このように、HTMLメールマガジン（のうち「Webバグ」を含むもの）は、送信先の相手ごとに異なる内容のメールを送っているのだ。メールを読むと会員番号が通知される。会員番号を通知することは、メールアドレスを通知しているのと同等である。
セキュリティ専門記者の勝村氏にさえこのことが知らされていないのだから、一般消費者は、99.9パーセント以上がこのことを知らないまま騙されているだろう。
これは、軽い道義的問題という程度のものではない。財団法人日本情報処理開発協会プライバシーマーク事務局の、「プライバシーマーク申請から利用までの流れ」に、次のように書かれている。
3. 現場での実施状況の確認
- オンライン特有の処置
- 個人情報保護方針の掲載
- 収集時の SSL の使用
- サービス、業務毎の“同意文言”
- Cookie などのウェブバグの利用の有無
- クロスサイトスクリプティング(CSS)などのセキュリティ対策
Webバグを使っていないかは、SSLの使用やクロスサイトスクリプティング対策と同列に重要なチェック項目とされているのだ。購読者の同意を得ずに密かにメールにWebバグを埋め込んでいる企業は、プライバシーマークを取得できない。ファミマ・ドット・コムのプライバシーポリシーに、「Webバグ」ないし「Webビーコン」についての説明は見当たらない。会員登録画面のメールマガジン要否選択の部分にも説明がない。
隠された本当の意図
実は、事業者がメールマガジンをHTMLメールで発行したがる本当の理由は、このWebバグによる情報収集にある。「[memo:6011] メールマガジン中のジャンプ先URL上の謎のID文字列の能力」には、事業者がそうした情報収集をはっきりと意思を持って行っていることが示されている。[memo:6011]の事例では、プレインテキストのメールマガジンであるため、IDによって追跡を行っている様子が目に見えている。[memo:6011]から引用すると、事業者は以下のように回答している。
ご指摘のとおり、この「ユニークな文字列」は配信されるメールごとに異なりますので、詳細な調査を行えば、それがどのメールアドレス宛てに配信されたものかを特定することは可能です。 ただし現時点では、この「ユニークな文字列」は、配信されるメールごとに固有のURLの一部として割り振られているだけで、お客様のメールアドレスと明確に 「関連付け」てはおりません。また、ダウンロードの有無によらず、どのお客様がアクセスされたか、という情報について確認および記録等の行為は行っておりません。つまり、現時点でこの仕組みから弊社が得ているのは、あくまでも「統計的データ」ということになります。
つまり、「統計的データ」を得るという意思を持って、こうした仕組みをわざわざ付けているのである。さらには、
将来的には、どのアドレスに送ったメールからアクセスがあったのかということを、メールを利用したマーケティング手法の一つとして把握する必要が出てまいります。その際には配信対象者へ必要な情報を開示し、承諾を得ながら実施いたします。
という考え方も存在しているようだ。
日経インターネットソリューションの小川弘晃氏は、「HTMLメールが急増中」の中で、なぜこの強力なマーケティング手法のことを書かないのだろうか。日経インターネットソリューションの記事は、多くの人がコメントしているように、マーケティングの立場から書かれた記事だ。HTMLメールのメリットとして、「ビジュアルな表現が可能」ということしか挙げていない。専門誌のくせに、Webバグマーケティングのことを知らないのだろうか。それとも、知っているが（お客様に余計な心配をかけないよう）あえて説明しないでおいているのだろうか。「説明による同意」ではなしに、「騙し騙し路線」で行くつもりなのか。
日本の事業者は、「説明による同意」ということがどうにも不得手のようだ。プライバシーポリシーの書き方として、何をどうするという説明をせずに、ただひたすら「お客様の個人情報は万全に管理して第三者に渡しません」とだけ書いて、あとは信じろという態度をとることが多い。事業者当人がいくらちゃんとやっているつもりであっても、何が起きているのかを本当にきちんと把握できているのかどうかだ。たとえば、先のファミマ・ドット・コムのWebバグ部分を見てみよう。
<img src="http://61.194.36.188/get_info.php?id=fami0602&send_id=b5b2...7934a&uid=4104"></HTML>
アクセス先のアドレスが、「famima.com」ではなく「61.194.36.188」となっている。逆引きしてみるとこれは「vmm.rootcom.jp」というホストだ。いったいどういう素性のサーバなのか。どうしてわざわざ数値形式のIPアドレスで書いているのか。「famima.com」以外に送信している事実を目立たなくしたいからなのか。なぜ目立たなくする必要があるのか。ファミマ・ドット・コムはこの事実を把握できているのか。プライバシーポリシーにこういうことをやっている事実説明が書かれていないだけに、もしかするとファミマ・ドット・コムの責任者も知らないのかもしれない。メールマガジンマーケティング会社の言うなりにアウトソースしているだけで。
マーケティングとプライバシーの両取りは可能では？
「説明による同意」は実施するとすれば、事業者にとってHTMLメールマガジンは有益なマーケティングツールとなる。私は冒頭で、HTMLマガジンはWebサーバ上に置けばよいとした。あの方法では、Webバグマーケティングが働かない。しかし、プレインテキストメールでも、IDを埋め込むことはできるので、次のように改良すればよい。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 第34号のメールマガジンをお届けします。 http://style.example.com/mag/0034.html?userid=24312 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
こうすることで、HTMLメールを使わずにしてマーケティング能力も温存できる。もはや、HTMLメールを使う意義は全くない。それどころか、プレインテキスト中にIDを記入したので、より透明性の高い「説明による同意」を達成できているという点で、こちらの方が優れている。
このようにユーザ番号がはっきり見えていると、購読者が毛嫌いするのではないかと心配する声もあるかもしれない。事業者としては統計的データだけを抽出しているのに、購読者が個人追跡をされていると誤解することが心配かもしれない。
ならば、統計的データしか得られないようにすればいいのだ。つまり、
のようにする。「312」は「24312」の下3桁だけを取り出したものだ。こうすると、個人を特定せずに最初から統計的データだけを得ることになる。これでは不十分なのか。どのみち有効桁2桁程度の値しか使う気がないのなら、これで十分じゃないのか。そういったことをきちんと検討したことがそもそもあるのかと問いたい。
つづく――次回予告: HTMLメールのもうひとつの危険性
■ 訂正
「「uid=4104」は私の会員番号だろう」と書いたが、「HTMLメールが急増中」によると、ファミマ・ドット・コムは「会員20万人」とあるので、つい最近登録した私の会員番号が「4104」ということはないか。
もう一度WebバグのURLを見てみると、
http://61.194.36.188/get_info.php? id=fami0602& send_id=b5b21eab18ce6428c7ba87a2b9f7934a& uid=4104という構成になっている。このサーバはメール配信業者のもので、おそらく、複数の顧客（メールマガジン発行主体）のメールマガジンを一手に扱っていると考えられる。「uid」はメール配信業者にとっての顧客番号なのかもしれない。「send_id」がおそらくメール1通ごとに割り当てられたIDで、これが送信先アドレスと対応付けられていると考えられる。IDと送信先アドレスとの対応表を保存しているかどうかは、説明されていないので不明。ちなみに、このメールマガジンは、Webバグ（見えない画像）だけでなく、通常のリンク先のURLも以下のように、同じ形式で管理している。
http://61.194.36.188/get_click.php? url_id=3& id=fami0602& send_id=b5b21eab18ce6428c7ba87a2b9f7934a& uid=4104「id」がメールマガジンの名称と発行番号、「url_id」がジャンプ先ページの番号で、「send_id」が購読者ごとに別々の番号、「uid」が契約者番号といったところか。
2003年06月07日
■ Webバグについて復習する
昨日の日記「HTMLメールマガジンをどうするか」で、「次回予告: HTMLメールのもうひとつの危険性」と予告したが、これはまた後日として、その前に昨日の話の補足を書く。
昨日の日記のリンク元をたどっていろいろな人たちのコメントを読むと、意外にも、「Webバグ」ないし「Webビーコン」という言葉を初めて聞いたという人が少なくないようだ。しかも、この問題の原理と存在を知っているという人が、「Webバグ」という用語があることを知らなかったという状況があるらしい。いかにこの問題がきちんと語られていないかの現れであろう。日経BPを代表とするITメディアが、単に不勉強なのか、あるいは意図的に騙し騙し戦略をとっているのか知らないが、彼らが自らの社会的使命を軽んじている結果だ。
Webバグの歴史
「Webバグ」の源流は古い。WWWにインライン画像機能（<img>要素）が導入された時点からその可能性は始まっている。Webページだけを想定すると、プライバシー上の問題はさほど大きくはない。Webページにアクセスするという行為が、アクセス先にアクセスログを残すものであることは公知であり、人々はそれを承知の上で行っているからだ。
そこに、バナー広告業者が現れる。広告画像に永続的なcookieを発行して閲覧者にIDを与え、無数のWebサイトに横断的に統一したIDを振るようになった。これは、DoubleClick社に対するプライバシー侵害訴訟という展開をもたらした。バナー広告へのIDの付与は、元々は、同じ人に同じ広告を何度も見せないようにという、広告システムの効率化のためであったが、結果的に、どの人がいつどこのサイトを訪れたかの情報が集まってしまうものだった。この時点では、IDはあくまでも単なる番号であり、それが誰なのかという情報とは結びつかない。（誰なのかの情報を持っているどこかの広告出稿先サイトと結託すると結び付けが可能になる。）
バナー広告と同じ仕組みをアクセス解析に使うという業者も現れた。画像を見えない大きさや色にして埋め込み、cookieによりIDを発行して、閲覧者ごとに、どんなタイミングでどのページを見たかを分析するというサービスだ。本来、そうした分析は、見えない画像を使わずともできるはずだ。普通に自サイト上でcookieを発行し、普通にアクセスログを分析することで可能だ（cookieのIDごとにアクセス履歴を調べるだけ）。この場合は、一般には、プライバシー侵害として指摘されることはほとんどない。それなのになぜ、見えない画像を使用するのかというと、アクセス解析を他社に委託するためだ。解析を依頼したいWebサイトは、アクセス解析業者のサーバに置かれた見えない画像へのリンクを張るだけで、そのサービスを受けることができる。その結果として、閲覧者は、気づかないうちにアクセス解析業者にアクセス履歴を残すことになる。もしアクセス解析業者が、閲覧者IDの発行方式として、各依頼元サイトに共通の番号としているなら、それは結果的に、先のバナー広告業者の事例と同レベルのプライバシー侵害能力を持つことになる（つまり、アクセス解析業者は、依頼元サイト毎に別々のID空間を用意すべきである）。こうした目的の見えない画像は「Webビーコン」と呼ばれ、日本でもプライバシーポリシーで言及しているサイトが少なくない。
その一方で、HTMLメールにID付きの画像を埋め込むという技法が現れてきた。メールは、Webアクセスと異なり、メールを送信しているという時点で相手が誰なのかが確定している（送信先メールアドレスとして）ので、送信先ごとに個別のIDを振ることで、バナー広告やアクセス解析のcookieよりも強力な個人追跡が実現する。こういうことが可能な仕組みは、技術的にセンスの悪い設計なのであって、廃止されるべきなのだが、NetscapeやMicrosoftが競って導入したHTMLメールは、もはや食い止めるのが困難な時期にさしかかっていた。
批判されなければ際限なくこうした密かな追跡行為が広がってしまうという状況の中で、ひとつの大きなインパクトをもたらす指摘が、2000年8月に登場した。Privacy FoundationのRichard M. Smith氏が、Microsoft WordやExcel、PowerPointのファイルでも同様の画像を埋め込める事実を指摘したのだ。これは次のように報道されている。
- ZDNet News: Office文書に“Webバグ” 2000年8月31日
- WIRED News: 『マイクロソフト・ワード』などに文書追跡可能なバグ 2000年8月31日
日本で「Webバグ」という言葉が認知されたのは、このときが初だったのではないかと思う。しかし、「バグ」というと日本では、プログラムが期待外の挙動をする原因を指す意味の「バグ」だけが連想されてしまうため、このニュースの意味がわからないという人が多かった記憶がある。「「Bug」ってのは盗聴器のこと」という指摘があるように、辞書をひくと、英語の「bug」には次の意味があるとされている。
1a 虫, 昆虫 (insect), 《特に》甲虫 (beetle); ナンキンムシ, ゴキブリ, アタマジラミ《など》.
b 《口》 微生物, 病原菌, 黴菌(ばいきん).
c 《口》 病気, 《特に》伝染病.
2a 《機械などの》欠陥, 故障; 【電算】 誤り, バグ.
b #《俗》 不機嫌, 腹立ち.
3a 《俗》 防犯ベル; 《口》 盗聴器, 隠しマイク; #《俗》 電信機のキー《上下でなく左右に作動する半自動式のもの》.
b #《俗》 小型自動車, フォルクスワーゲン (Beetle); #《俗》 月面車; #《俗》 ホットロッド(のドライバー).
c 毛針, 虫針; #《俗》 《工場などで使う》大ひしゃく, 大るつぼ; #《俗》 《大道商人の商う》安物雑貨, 小物.
d #《印刷俗》 星印, アステリスク《＊》 (⇒5a), 《出版物などに小さく刷り込む》ユニオンショップマーク, 商標[著作権]記号, シンボルマーク.
4a （以下略）
[株式会社研究社 リーダーズ英和辞典第2版]
上の記事からいくつか引用してみる。
このバグによって文書作成者は、少なくとも理論上は、文書が他の読者に回ったり、組織ネットワーク外に送信された場合に、それがわかるようになる。スミス氏は、このバグの悪用例は知られていないが、利用しそうな人々は存在すると述べた。
たとえば、極秘文書の漏洩を内密に検知・追跡するために、企業がコードを文書に埋め込むことが可能だ。また、著作権を持っている人がこの機能を利用して、ニュースレターや報告書の著作権が侵害されていないかどうか追跡することも可能だ。
Smith氏が発見したのは，これまで誰も気付かなかったのが不思議なくらい非常にシンプルな手法。以前から，Webサイトが利用者のサーフィン習慣を捕捉してcookieを置くために，小さな画像（1×1ピクセル画像）のリンクを使うことは知られていた。これはオンライン広告サービスでよく使われている方法だ。
Smith氏は，この手法が「Word 2000」「Excel 2000」「PowerPoint 2000」の文書でも行えることを発見した。文書内の小さな画像の外部リンクにより，文書が開かれるたび，その文書がインターネットに出ていく。1×1ピクセルという極めて小さな画像であるため，ユーザーはダウンロードしていることに気づかないが，そのピクセルとともにcookieが届いているかもしれない。
Privacy FoundationのWebバグの解説は、「FAQ: Web Bugs」、「FAQ: Document Web Bugs」、「Why are they bugging you?」にある。
その後、次のような報道があった。
- ZDNet News: “Webバグ”の悪用回避は「技術的に困難」 2000年9月1日
- INTERNET Watch: 米Privacy Foundation、個人情報収集手法「Web bugs」に関するガイドライン 2000年9月14日
- TechWeb/＠ITNews: Webバグの拡大で危険を冒す企業 2001年8月18日
- 毎日新聞DIGITALトゥデイ: オンライン広告の業界団体、「ウェブバグ」の標準仕様開発へ 2001年10月5日
「技術的に困難」というのは、これを技術的に回避するには、第三者サイトにある画像のインライン埋め込みをHTML的に禁止するしかないからだろう。現在では、いくつかのメーラでは、そうした機能が搭載されている。Mozillaには、「Privacy & Security - Images - Image Acceptance Policy」の設定項目に「Accept images that come from the originating server only」という選択肢があり、「Do not load remote images in Mail & Newsgroupmessage」というオプションもある。ちなみに、これらを有効にすると、ほとんどのHTMLメールマガジンは全く読めないものになる。記事の最後は次のようにまとめられていた。
ワシントンD.C.にあるシンクタンクCenter for Democracy and Technologyの政策アナリストAri Schwartz氏も，技術以外の解決策が必要との見方を示す。
「ユーザーが企業に圧力をかけ，不正な情報収集を止めさせる必要がある。法規制が必要なら，今起きていることについて人々に警告を発し，一定の選択肢を示すのがいいだろう」と同氏。
現状のままでは，Webユーザーの多くは，自分のPCがどのような情報をインターネットから吸い上げられているか見当がつかない。また，選択肢もほとんど与えられていない。
Privacy Foundationのガイドラインは「Guidelines for Using Web Bugs」にある。
日本のメディア人の不見識
一方、日本で独自にWebバグについてコメントした（つまりニュースの翻訳以外の）公式な発言は極めて少ない。元IPAセキュリティセンター長の前川徹さんが、情報処理学会誌の連載「米国インターネット事情」において、2001年10月号で書かれた「Web Bugとプライバシー問題」という記事くらいしか記憶にない。
今、検索して探してみたところ、日経BPでは、IT Proの記者の眼で2001年8月に日経インターネットテクノロジー副編集長により書かれた「Web Bugを考える」という記事があった。しかし、読んでみると、問題を過小評価したものとなっている。引用すると、
しかし，通常のWebアクセスやHTMLメールの受信でも，同じようなことができる。Webページの場合，Webサイト自身は“見えない画像”を使わなくてもユーザーのアクセス状況は把握できる。HTMLメールも，メール自身にすべてのコンテンツを入れずに，一部をサーバーからダウンロードするようにすれば，ユーザーの行動がわかる。個人的には，Web Bugは，そんなに大騒ぎするようなことだろうか，とさえ思う。
とあるが、先にに書いたように、HTMLメールでは、送信先毎に個別のIDをURLに含めることによって、具体的に誰のアクセスであるのかを特定できる。通常のWebアクセスで、アクセスした人のメールアドレスを特定されることなどない（ユーザ登録したサイトでない限り）。また、続く部分に、
プライバシ・ポリシーを掲げるサイトが多くなっているが，具体的になにをどのように取り扱うかを細かく記述してあることは少ない。せいぜい「サービスの向上のためにユーザー情報を使う。第三者には渡さない」程度である。もっとも，1つひとつ具体的に記述するのは，現実には難しいことだろうし，ユーザーも読まないだろう。
と書かれているが、プライバシーポリシーは、読まれる読まれないよりも、提示することに意義があるのだ。そんなこともわかっていないとは、専門誌の見識の低さに改めて驚く。
メディアの役割は、こうしたプライバシーの懸念が具体的にどのようなものであるかを解説し、どのような批判が起きているかを紹介し、事業者がなにをなさねばならないかを伝道することだろう。他の代表的ITメディアとしては、@IT があるが、「最新e-mailマーケティング事情」の「第3回 効果的なHTMLメールの使い方」や、「IT業界記者によるリレーコラム IT Business フロントライン」の「HTMLメール普及を狙う広告業界 嫌われ者は受け入れられるか？」を読んでみても、「Webバグ」に関する記述がなく、顧客のプライバシー配慮としてなにをなすべきかということについて、書かれていない。後者の著者の高橋智明氏は、記事中で
筆者も以前、HTMLメールの普及について記事を書いたときに、「見識を疑う」といった読者からの激しい反応が多数届き驚いたことがある。
と述べているが、まさに見識を疑う。
高橋智明氏の@ITの記事から興味深い部分を引用してみると、
日本より一足先にブロードバンド環境が整った韓国では、広告メールやメールマガジンのほぼ100％がHTML化している。米国でも半分程度がHTMLメールだ。日本もここへ来て、ようやくブロードバンドの普及率で世界のトップクラスに肩を並べる水準となり、今後、電子メールビジネスのHTML化がさらに加速する可能性は高い。
ただし、懸念材料はある。「日本のネットユーザーはなぜかHTMLメールを必要以上に嫌っている」と業界関係者は口を揃える。
...
HTMLメールが嫌われる主な原因は、セキュリティにある。テキストメールでウイルスが送られる場合、通常は添付ファイルを開かない限りは感染しない。しかし、HTMLメールでは本文やヘッダの中にファイルを実行するという記述を行うことができるので、メールを見ただけでウイルスに感染してしまうことがあるのだ。... ただし、こうした事情はほかのネット先進国でも変わりはない。なぜ日本だけHTMLメールがこんなに嫌われるのかよく分からない、というのが実情だ。
こうした状況を変えていくには、関係者がねばり強くネットユーザーを啓蒙していくしかない。
とある。誰が誰をどのように啓蒙すべきかを取り違えている。無知がゆえの仕方ない発言なのか、意図的な騙し騙し作戦なのかは不明だ。
韓国で100%がHTMLメール化しているという話はしばしば耳にするが、「HTMLメールはやめよう 」の読者コメントにもこういう発言があった。
インターネット先進国？で仕事をしている日本人です。韓国でIT関係者に、「日本ではHTMLメールはスパムに分類される」という話をしたら、キョトンとしていた。なぜだか理解できないと。私も全く理解できないし、こんな議論を持ち出すマスコミも理解できない。
韓国のプライバシー事情については、WIRED Newsの「電子メールがいつどこで読まれたかをこっそり追跡」（2001年2月8日）が興味深い。
韓国のポステル社とアイトレースユー社の両社は、電子メールが開封された時間を特定するために、隠されたHTMLタグを使っている。オンライン・マーケッターたちはこのタグを「ピクセルタグ」と呼んでおり、スパム・キャンペーンの成果を測定するために利用している。
...
ポステル社は、電子メールが転送されるときは常に送信者にそのことを通知し、転送されたメールを誰が読もうとも、その日時や、読んだ相手の電子メールアドレスとIP(アドレス)を知らせる、という付加機能を提供している。
...
ポステル社の設立者であるスーボック・リー氏は、韓国ではこの追跡システムは大人気だと語った。
「われわれは韓国に多数の顧客を持つ」とリー氏。「自分が出した業務連絡のメールを追跡し、読まれたかどうかを確認したいと考える顧客が、われわれのサービスを利用している。このサービスがないとすれば、相手がメールを読んだことを電話で確認しなければならないだろう。このサービスのおかげで、顧客は電話をしなくてすむのだ」
韓国にはプライバシーに無頓着な国民性があるのではないかと憶測しているが、まだ証拠を集め切れていない。
しばしば、プライバシーは欧米渡来のもので、日本人はプライバシーに疎いというようなことが言われることがあるが、私にはそうは思えない。プライバシーを重視しているが、誰も声を上げないでいる、もしくは、論理的に説明する力に欠けるために、不満が表面化しないだけではないかと思う。
なぜHTMLメールマガジンなのか
昨日の日記で、HTMLメールマガジンなんかやめて、Webサイト上にマガジンコンテンツを置き、メールは単に更新通知のためだけに使えばよいと提案した。それができない理由を考えてみる。
それは、メールマガジンはそれ専業の業者に委託されて発行されているためではなかろうか。Webサイト上にマガジンコンテンツを置くとなると、そのサイトのドメインがどこなのかが問われる。ネットショップのマガジンならば、そのネットショップのドメイン上にコンテンツを置きたいところだろう。しかし、そうするには、サーバへのアクセス権を、メールマガジン業者に与えなくてはならず、管理が難しくなるのかもしれない。また、「効果的なHTMLメールの使い方」によると、メールマガジンを配送した直後からアクセス集中が発生するため、サーバを別にする必要があるという事情があるようだ。しかし、ドメインだけ同じにして、別サーバとすることはできるはずだ。
ならば、堂々と、メールマガジン業者のドメイン上にコンテンツを載せてもよいのではないか。しかし、昨日の日記にも書いたように、「vmm.rootcom.jp」というホスト名をわざわざ「61.194.36.188」と書いてわかりにくくしているという実態がある。なぜ隠すのだろうか。
あるいは、ネットショップが自力でメールマガジンを発行すればよいのに、なぜそうしないのか。考えられるのは、大量のメールを高速に配信するのには技術と設備投資が必要であるため、アウトソーシングするのが効率的ということだ。しかし、それならば、メールの配信だけを委託して、コンテンツ（HTML形式の）は自前で用意すればよいのではなかろうか。つまり、自前のドメイン上にHTMLマガジンを置き、更新通知メールの配信を業者に委託するという方法だ。
現状がそうなっていないのは、おそらく、メールマガジン業者のセールスにまんまとのせられているためではないかと憶測する。あるネットショップが、これまでに、プレインテキストメールによるメールマガジンを、メールマガジン配信業者に委託してきたとする。その業者が最近、HTMLメール版のマガジンへの切り替えを売り込んでくる。業者のセールストークは、「HTMLメールにすれば、開封率や、クリック率を測定できますよ」というもの。配信業者からすれば、HTMLコンテンツの作成料を上乗せして、付加価値の高い商品を提供できるというわけだ。
しかし、本当にそんな開封率やクリック率の情報を買いたいのか？と問いたい。自前のサイトにHTMLマガジンのコンテンツを置いて、メールで更新のお知らせを出せば、あとは、自前のサイトのアクセスログを解析するだけで、開封率やクリック率に相当する情報は得られるはずだ。しかも、そうすることで、顧客のプライバシーとセキュリティーも保護される。
2003年06月10日
■ 高度情報公開行政の推進
行政の情報公開は粛々と進められているようで感心した。
「北海道室蘭市のICカード標準システム実証実験事例紹介(soumu.go.jp)」のp.10から引用:
この端末は、インターネットに物理的につながっていないか、つながっていても、この端末からインターネットのWebへのアクセスがファイアウォールで制限されているか、さもなくば、職員がこの端末からインターネットのWebを見ることが厳しく禁止されているのだろう。だから、イントラネットのURLが情報公開されているのだと思う。
関連: [JavaHouse-Brewers:33024] 任意のホストに接続できてしまうセキュリティ上の欠陥がもたらす危険性 (2000年5月7日)
2003年06月14日
■ HTMLメールマガジンのもうひとつの危険性
6月6日の日記「HTMLメールマガジンをどうするか」で予告していた、メールマガジンをHTMLメールで流すことの危険性、つまり、勝村氏が指摘するソフトウェアの欠陥の話以外の、セキュリティ上のより本質的な問題点について書く。
メールはWebに比べて偽物を作りやすい。メールのヘッダの「From:」は、元々自由記述するところなので、発信者が偽でないかを確認するには全く当てにならない。「Received:」を見れば偽の可能性を知ることができる場合もあるが、本物の場合に、それが必ずしも発行者のドメインと一致しているとは限らない（メールマガジン配送業者に委託されているかもしれない）ので、偽物か本物かの区別は一般の人には難しいだろう。メールに電子署名することでこの問題は解決するのだが、現状では全く行われていないと思われる。
Webでは、ブラウザのアドレスバーに表示されるURLを目視確認することで、閲覧者は、自分が今、本当に期待しているサイトを見ているのかを絶えず確認する習慣になっている。（万が一に発生するかもしれない、通信路上でのパケットすり替えや、DNSスプーフィング攻撃の心配を払拭したいときには、「https:」で同じサイトにアクセスしてみれば、本物であることを確認できる。）
プレインテキスト形式のメールマガジンでは、読者は、気に入った情報があれば、マガジン中に記載されたURLにアクセスすることになる。このときのURLは、テキストでそのまま書かれているのだから、読者はドメイン名を見て、それがいつもの信頼しているサイトであるかどうかを無意識のうちに確認しているだろう。それに対し、HTMLメール形式のメールマガジンでは、読者は、画像や、任意の文字列にマークアップされたリンクをクリックして、目的のページにジャンプするのだから、そのときにドメイン名を確認することを普通はしない。
HTMLメールからリンクをたどったときに、Webブラウザのウィンドウで開くようになっている場合には、ジャンプ後のブラウザのアドレスバーを見ることで、信頼しているドメインにアクセスしているかどうかを確認できる。しかし、アドレスバーを隠したポップアップウィンドウが現れる場合はどうか。
6月2日の日記にも書いたように、日経システム構築の調査によると、インターネットバンキングのログイン画面を、アドレスバーを隠したポップアップウィンドウにしている銀行が、32行も存在するという。「ITコマースの脆弱な現実と危機回避に向けた展望」の3.2節「なりすましに無警戒な銀行のログイン画面」では次のように指摘されている。
もしこの銀行を装った偽のウィンドウを出現させる悪意のあるサイトが存在していたらどうだろうか．「こちらは○○銀行です．只今キャンペーン実施中です．今ログインして頂いた方には粗品を差し上げます．」といった電子メールやバナー広告に誘われて，指定のサイトにアクセスしたときに，同じデザインのウィンドウが現れるといったことはあり得るだろう．このとき，日頃から図4のウィンドウに慣らされているユーザは，「右クリック＋プロパティ」によってそのウィンドウのURL のドメインを確かめようとするだろうか．これを確かめることなく，偽のウィンドウに口座番号とパスワードを入力してしまえば，それは悪意ある者によって収集されてしまう．
こうした偽のウィンドウを出す偽メールマガジンは、それがHTMLメール形式だと騙されやすいものとなる。リンクの部分が、任意の文字列や画像になっているからだ。より騙されやすいリンクとして、本物のURLが書かれているように見せかけて、リンク先は別のサイトになっているという罠もあり得る。たとえば次のようなコードだ。
<a href="http://example.com/doom.html">http://www.cyberpolice.go.jp/</a>
どうにもこう、アドレスバーを隠したポップアップウィンドウがやたらと不用意に使われているという実態がある。警察庁ですら警戒が足りないようで、警察庁の「@police」サイトの中央下に並んでいる「topics」というところの「重要」情報のリンクをクリックすると、アドレスバーを隠したポップアップウィンドウが現れる。この画面に見慣れている人は、「平成１５年６月１０日 警 察 庁」とさえ書かれていれば、本物と信じてしまう習慣が身についているかもしれない。このような「重要なお知らせ」を、ポップアップで出す意義がいったいどこにあるのだろうか。誰の判断なのか。実装業者がなんとなく見た目のデザインで決めたのか、発注時にこのような画面設計が指定されていたのか、それは知らないが、騙され難さを重視するなら、このような画面設計はやめるべきだ。どのくらいの騙されやすさがあるのか、知られていないのかもしれないので、実演してみることにする。以下をクリックするとどうなるだろうか。
本日の重要なお知らせ （平成１５年６月１３日）
普段からHTMLメールでメールマガジンを受け取っていると、こうした成りすまし攻撃に騙されやすくなってしまうといえる。メールマガジンの案内でアクセスする先が、クレジットカード番号や、パスワードや、個人情報を入力する画面を持つならば（たいていのメールマガジンはそうした画面に案内するものだろう）、こうした成りすましに警戒することは欠かせない配慮であるはずだ。特に、本物サイトでポップアップウィンドウを使っているところでは、すでに危険な状態にあるといえる。
これに対し、6月6日の日記で提案したように、HTMLマガジンをWebサーバに置いて、プレインテキスト形式のメールで最新号発刊の通知だけを送信するならば、購読者は、メール中のURLを目で見て、本物のドメインかを確認するので、騙されやすさを低く抑えられる。
HTMLメールのこの危険性のことはあまり知られていないのだろうか。小島さんの「セキュリティホールmemo」では5月30日付けのコメントでふれられているが、勝村氏の「HTMLメールはやめよう」では言及されていない。勝村氏は徹底してHTMLメールの問題を列挙したかったはずなのにだ。読者コメントにも無かったように記憶している。特にひどいのは、6月7日の日記で紹介した、高橋智明氏の@ITの記事「HTMLメール普及を狙う広告業界」だ。そこには次のように書かれている。
また、フォームで購入注文を受けつけたり、アンケート調査を行ったりしたい場合など、テキストメールではいったんURLをクリックしてもらい、所定のWebサイトに誘導する必要があるが、HTMLメールならメール本文にフォームを表示できる。そのため、ユーザーは直接入力して返信することが可能だ。たかがワンクリックと思われるかもしれないが、このワンクリックを省略できることでアンケートの回答率や購入率が飛躍的に上がるという。
そんな、どこに送信するのか得体の知れないフォームに、やすやすと入力させるとは、著しく見識を疑う。「所定のWebサイトに誘導する必要がある」からこそ、本物の情報だと確認できるのだ。
責めてばかりなのでフォローしておくと、高橋氏の記事には優れたものもある。同じ@ITのシリーズの「銀行界を震撼させたネットバンキング不正送金 拡大するインターネットバンキングに暗雲」と、「銀行は事態の深刻さを認識しているか？ ネットバンキング不正利用事件の問題の本質」という記事は、言うべきことを言っている貴重な記事だと思っている。こうした、セキュリティに意識の高いはずのIT記者にさえ、HTMLメールの本当の危険性が理解されていないことに、問題の深刻さが見える。
メールマガジン発行者は、自社のドメイン名を信頼の基点としてもっとアピールすべきではなかろうか。テキストメール形式のメールマガジン中にドメインを記述し、それが本物であることを確認するよう購読者に促してはどうだろうか。
あるいは、偽メールの危険性を重視して、メールマガジンに電子署名するようにしてはどうだろうか。認証局方式の署名付きメールは今ひとつ普及していないが、これは、署名に必要な証明書が有料であるため、個人ではあまりコストに見合っていないためと思われる。メールマガジンは事業者が発行するのであるから、https: 用のサーバ証明書を購入するのと同じように、メールマガジンのFrom:アドレスに対応するメール署名用証明書を購入して使用してはどうだろうか。信頼性に重きをおく事業者であるとアピールできるばかりでなく、これによって署名メールの一般への普及も促進されるかもしれない。なお、プレインテキストメールにも署名した方がよいだろう。
■ メールマガジン以外でのHTMLメール
これまではあえて論点をオプトイン方式のメールマガジンに絞ってきたが、それ以外について考えてみる。
HTML形式のspamメールは、Webバグを挿入することによって、有効なメールアドレス（到達して開封される「新鮮な」アドレス）の抽出を行うことが可能だ。つまり、何百万ものでたらめなメールアドレスを生成してシリアルナンバを振り、それをWebバグとして埋め込んだHTMLメールを送信すれば、Webサーバのアクセスログに記録されるシリアルナンバーから、新鮮なメールアドレスのリストを得ることができる。実際にそうしたWebバグを含むspamメールが多数流れている。<img>だけでなく、<iframe>と<ilayer>を使ったものも見つかる。他にもいくつかのタグで同様のことが可能だろう。
これは、もはや致命的な欠陥と言えよう。この脅威から逃れるには、HTMLメールを表示しない設定にするか、外部への参照をロードしない設定にするしかない。6月7日の日記に書いたように、Mozillaでは、「Privacy & Security - Images - Image Acceptance Policy」の設定項目で「Do not load remote images in Mail & Newsgroup message」をチェックしておけばよい。Netscape 7では、「プライバシーとセキュリティ - 画像 - 画像受入証書」の「Mail & Newsgroupメッセージにリモート画像を読み込まない」という翻訳となっている（「受入証書」は訳が変だなあ）。セキュリティホールmemoの6月9日のコメントの追記に、この機能に関連する話題が集められている。また、Office 2003のOutlookでは、デフォルト設定で外部コンテンツの参照が遮断されるという話が、ZDNetの「Office 2003――6つ（あるいはそれ以上！）の版のどれを選ぶか」に書かれている。引用すると、
これはつまり、Microsoftから送られてくるものを含め、私が受信するほぼすべての電子メールニューズレターがグラフィックスなしで表示されるということだ（AnchoeDeskのニューズレターのグラフィックスも遮断される）。
この機能はスパム対策の1つとされるものだが、これでは受け手が実際に受信したいコンテンツもめちゃくちゃになってしまう。この機能がOffice 2003のファイナルビルドで採用されようとされまいと、大量のジャンクメールをメールボックスに送りつける不届き者がその行為をやめることはないだろう。あまり役立ちそうにないこの機能をめぐって、私は今、Microsoftにかけあっている。結果は今後のコラムで報告しよう。
この人は、新鮮なアドレスが抽出される仕組みを知ってて言っているのだろうか。（原文記事のTalkBackを見てみると、「HTML Email Blocker is easy to turn off」と言っている人が……。）
そうした防衛が当たり前のものになってくると、現在のHTMLメールマガジンは、まともに内容を表示できなくなる。しかし、このことはマルチメディアメールを否定するものではない。MHTML (MIME-encapsulated HTML) 形式を使えばよい。MHTMLは、RFC 2557で定義されており、一通のメールにHTMLとそのリンク先オブジェクト（画像など）をまとめて送信できるようにする形式だ。Internet ExplorerでWebページを「名前を付けて保存」するとき、「ファイルの種類」を「Webアーカイブ、単一のファイル (*.mht)」を選ぶと、このMHTML形式で保存される。MHTMLの肝は、MIMEメール中のパートにContent-IDを付け、HTMLから「cid:」のURIで参照できるようにした点にある。ちなみに、2001年9月に大流行したNimdaワームは、この「cid:」を使ってウイルス本体をHTMLから起動する仕掛けになっていた。（ただし、起動してしまうのはIEのバグに原因があったのであり、MHTMLの欠陥ではない。）
1999年3月にリリースされたこのRFC 2557では、「Security Considerations」の章で、次のように述べられている。
HTML-formatted messages can be used to investigate user behaviour, for example to break anonymity, in ways which invade the privacy of individuals. If you send a message with a inline link to an object which is not itself included in the message, the recipients mailer or browser may request that object through HTTP. The HTTP transaction will then reveal who is reading the message. Example: A person who wants to find out who is behind an anonymous user identity, or from which workstation a user is reading his mail, can do this by sending a message with an inline link and then observe from where this link is used to request the object.
MHTMLメールを使えばこのプライバシー侵害がなくなるわけではない。MHTML中に外部サーバへの参照を書くことはできてしまう。メーラの設定で外部参照のダウンロードを止めた上で、マルチメディアコンテンツの必要があればMHTML形式で送ればよいという話だ。
では、メールマガジンでMHTML形式は使われるだろうか。当面それはないと思われる。MHTML形式にするとメールサイズが大きくなる。参照する画像のすべてを含ませるので、一通が500Kバイトくらいになるのではなかろうか。今のHTMLメールマガジンでも、画像はいずれにせよダウンロードするわけであるが、その場合は後で必要に応じてダウンロードするのに対して、MHTMLメールとして最初に全部をダウンロードせざるを得ないのは、次のメールの取得が遅れるという点で消費者は不快に思うだろうし、メールスプールが溢れてしまうという問題がある。やはり、HTMLマガジンは全部Webサーバに置けばいい。
■ それでもHTMLメールは必要なのか
実家の両親にWindowsマシンをプレゼントしていたのだが、ある日からメールがHTMLでやってくるようになった。「送信」の設定を「テキスト形式」にしておいたはずなのに、自力で設定を変えたらしい。帰省したとき尋問してみると、なにやら「夢メール」というものが「メル友」達との間で流行っているのだという。
「夢メール」とは、JavaScriptを使って画像に動きを与えた、「かわいいメール」のようだ。うちの両親は、知人から送られてきたメールでこれのことを知ったそうで、知人が言うには絵が動くはずなのに、自分の画面では絵が動かないと嘆いていた。これは、Outlook Expressのセキュリティ設定で「制限付きサイトゾーン」から「インターネットゾーン」に切り替えれば、絵が動くようになる。設定を変えて見せてやると、2人はいたく感激して、今までにもらったメールを全部読み返し、喜び勇んで「メル友」たちに新たなメールを送っていた。
この様子を眺めて私は、設定を元に戻すべきかに悩まされた。なにしろ、彼らは、動くメールや、色つきのメールを、旅先で知り合った「メル友」とやりとりすることくらいしか、「パソコン」の楽しみ方を知らないのだ。（ダイヤルアップ接続であるため、Webサーフィンを楽しめていないということはあるようだが。）
こういった人たちに対して、「HTMLメールはWebサーバに置けばいい」とは言えない。ホームページなんか持っていない人たちだからだ。
■ 追記
ナンバーディスプレイ機能のなかった時代の電話を思い出すと、かかってきた電話は基本的に信用できないもので、自分からかける電話はそれなりに信用できるものだというのは、誰でも直感的に知っていただろう。訪問販売で買わされるより、自ら出向く買い物の方が信用できることも皆知っている。（電子署名されていない）メールは、かかってくる電話や訪問販売と同様に、信用のアンカーとなるものがない。または希薄だ。HTMLメールは、見た目こそWebページと同じだが、信用のレベルは全く異なる。アドレスバーが隠されて、プロパティの確認もできないようにされた、得体の知れないWebサイトに等しい。Outlook Expressのデフォルト設定が「インターネットゾーン」から「制限付きサイトゾーン」に変更されたのは、理にかなっている。あるいは、もうひとつ別のゾーンとして「未信頼ゾーン(Untrusted zone)」を設けて、メールは未信頼ゾーンとすると、よりしっくりくるかもしれない。外部から認証なしで受け取るタイプのメディアは、未信頼のゾーンにある。
電話を折り返しかけなおしたり、訪問販売員の身分を確認するのと同様に、メールマガジンの購読者には、「未信頼ゾーン」から「信頼済みゾーン」（あるいはそこそこ信頼できる「インターネットゾーン」）へと移行するステップが必要なはずだ。プレインテキスト形式のメールマガジンでは、マガジン中のURLを開く操作がそれに相当するが、HTMLメール形式だと、そのステップの存在があやふやになってしまいかねない。この重要なステップのことを忘れて、見た目だけWebページ風のマガジンを発行するのは、（オプトイン購読してくれているという）顧客からの信頼を、蔑ろにしてしまっているとさえ言える。
2003年06月15日
■ ソニースタイルがやってくれた
偶然なのか必然なのか、日経IT Proで「HTMLメールが急増中」が掲載されたのと時を同じくして、ソニースタイルからこんな案内が来ていた。
─────────────────────────────────── このメールは2003年5月28日現在、ソニースタイルログインIDをお持ちの方へ お送りしています。 ─────────────────────────────────── ... ■□ 【お知らせ】 □■ Style Memberメールがビジュアル対応で読みやすくなります ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ ... HTML形式のメールをご希望されない方、および“Style Memberメール”の お受け取りをご希望されない方は、お手数をおかけいたしますが、 下記ページよりログインし、Style Memberメール配信方法を変更ください ますようお願い申し上げます。
つまり、HTMLメール形式のメールマガジンに移行しますよという告知だ。そのまま配信されてくるのを楽しみに待っていたのだが、13日についに来た。それはとても興味深い形式で送られてきた。
HTMLメール形式を受け入れたのだが、送られてきたメールは、HTML形式とプレインテキスト形式のハイブリッド版だった。
Content-Type: multipart/alternativeで送られきたのだが、「text/plain」パートには、これまで通りのテキスト形式のメールマガジンの内容が書かれていて、「text/html」パートに、よくあるHTML形式のメールマガジンが書かれているのだ。つまり、両方の形式のマガジンを1通のメールで送ってきている。内容は同一ではない。テキスト用とHTML用では書かれている内容が大幅に異なる。こういうのを「multipart/alternative」と称すのは誤りだと思うが、それはまあよしとしよう。
興味深いのは、「test/plain」パートの冒頭部分だ。HTML版にアクセスするURLが書かれているのだ。これはおそらく、HTMLメールを拒否した場合の、テキストのみ版のメールマガジンにも同じように案内さているのだろう。
─────────────────────────────────── このメールは2003年6月11日現在、ソニースタイルログインIDをお持ちの方で テキスト形式のメールをご希望の方にお送りしています。 ─────HTML版 http://mail.jp.sonystyle.com/cgi-bin16/DM/y/mP250HXXXXXXXXXkUF0Bo■□■━━━━━━━━━━━━━━━━━━━━━━━━━━━━━■□■ ◇◆ Style Memberメール 6月13日号 ◆◇ ■□■━━━━━━━━━━━━━━━━━━━━━━━━━━━━━■□■
つまり、HTMLマガジンをWebサーバに置いてくれたのだ。もしかしてこの日記の影響？……と考えるのは早計だろうか。すでに他でもやっていたのかもしれないが、未調査だ。
さて、HTMLマガジンをWebサーバに置くというアイデアを評価してみよう。上のURLにアクセスすると、以下のページに自動的にジャンプするようになっている。
http://www.jp.sonystyle.com/Mail/Stylemember/030613/この内容は、メールで送られてきた「text/html」パートと同一の内容になっている。
私は好き好んでソニースタイルのメールマガジンを購読してきたので、内容には関心があった。しかし、テキスト形式のメールマガジンでは、はっきり言って読むのが苦痛だった。要点だけ伝えてくれと願っているのに、ダラダラとどうでもいいことが書かれているからだ。たとえばこんな感じ。
「今日、帰りにちょっとソニプラ寄ってかない？」 高校生からOLまで幅広い層に熱心なファンを抱えるソニープラザ。 店内をぶらぶらしながら、最新コスメやユニークなバス用品、ポップなデザ インの輸入雑貨に思わず目をキラキラ！なんて思い出をお持ちの女性も多い ことでしょう。
他社のメールマガジンにはもっとウザいものがある。バカバカしい挨拶から始まるものだ。たとえば、「ぷららパラダイスFor You倶楽部」のメールマガジンから引用するとこういう挨拶で始まっている。
こんにちは、きむです！ 東京では最近、ぐずついたお天気が続いています。もう梅雨なのかなぁ。。。 と感じる今日この頃、皆さんいかがお過ごしでしょうか？ お天気の悪い日は、お家でのんびり今まで撮ったデジカメ画像を整理してみ るのはどうでしょう？ 思い切って外に飛び出して雨の街を写真に収めてみるのも新しい発見がある かも！？
「きむ」って誰だよ！ というか、どうせ偽名だろう。それだけで無礼な話だ。こういうコミュニケーションスタイルは、メールマガジンを読むことくらいにしかパソコンの活用方法を見出せてないピープルにとっては、「きむ」は待ち遠しい「メル友」の一人なのかもしれないが、要点だけ伝えてくれと願って購読している者にとっては、これだけで読む気が失せる。
HTML形式のマガジンでは、こうしたバカバカしさがなく、ウザい説明もなく、パッと見で要点を掴むことができる。だから、HTMLマガジンは事業者にとっても消費者にとっても有益なのだ。
この違いはなぜ生ずるのか。今回、ソニースタイルで同一のマガジンをテキスト形式とHTML形式の両方で読んで、それをはっきりと認識した。基本的に、テキスト形式のメールマガジンは、オフライン状態で読まれることを想定しているようだ。つまり、ダイヤルアップのナローバンド接続の顧客を想定している。そのため、メールを読むだけで、そこに案内されたURLにアクセスしてみたくなるように、いろいろと、ウダウダと、ダラダラと、挨拶やら説明やら馴れ馴れしい文句が書かれているわけだ。そういうのを読まされて「要点だけ伝えろよ！」とイライラするのは、私がブロードバンドの常時接続を使っているからだ。URLにアクセスするくらい、いつでもすぐにホイホイとクリックするよう、スタンバイしている。どれを選べばいいのか探しているのに、ダラダラとくだらない説明は邪魔なだけだ。
http://www.jp.sonystyle.com/Mail/Stylemember/030613/ を見ればわかるように、これはもはや、ごく普通のWebページだ。これでいいじゃないか。HTMLメールで送る必要など全くない。「メールマガジン」というメディアそのものが、つまり、形式だけでなく内容そのものについても、ダイヤルアップでナローバンドな接続の時代にのみ存在価値のあるものだったということだ。ブロードバンド常時接続では、Webに宣伝を書いて、更新があったことだけメールで通知すればいい。
6月6日の日記で、「マガジンのURLだけ簡潔に紹介すればいい」という案を示したが、ソニースタイルの今回のマガジンでは、テキスト版と共に、Webサーバ上のHTML版へのリンクを案内するという方法だった。なるほど、それはいいアイデアだ。
リンク元をたどって見つけた「DON's Diary」の6月10日の日記によると、
昨日書き損ねていた件だけど、同じく高木さんの主張で
HTMLメールを送る代わりに URL を一行書いただけのメールを送ればいい。やりそうによってはマーケティング的な要求も満たせる。(詳細はタイトルのリンクを参照)
というのも違うんじゃないかと。確かに、技術的には、仕組み的にはそれで等価なんだろうけど、広告的なインパクトはぜんぜん違うと思う。それを技術的な問題だけで流してしまうのはちょっとずるいなぁと。
とあった。つまり、購読者がWebサーバ上のHTMLマガジンへアクセスしてくれるかどうかということだが、好き好んで購読している人ならアクセスするだろう。ナローバンドなダイヤルアップ接続の人は見てくれないことも多いだろうが、ブロードバンド常時接続ならとりあえず開くことだけはする。開いてみて見ている時間がないと感じる人には見てもらえないわけだが、それは、HTMLメールで送ってプレビューされたときだって同じことだ。開けばいいというものではないだろう。内容を見てもらえるかで評価しなくては意味がない。
その点で、ソニースタイルの、テキスト版メールマガジンと共にHTMLマガジンを案内するという方式は、クリックしてもらえなかった場合にも備えている。常時接続とダイヤルアップ接続を併用している人（ノートPCを屋内で常時接続、屋外でPHS接続している人など）にとってはこれが最適だろう。だったら、HTMLメールはやめてしまったらどうか。
ブロードバンド常時接続の人は、一度Web版の方を見れば、その読みやすさに味を占めて、次回以降はすぐにそのURLにアクセスするようになるに違いない。問題は、まだそのわかりやすさを経験していない人たちにどうやって経験させるかだ。その点、今回のソニースタイルの「HTML版」という案内は地味すぎる。もっと積極的に、たとえば次のように案内してはどうだろうか。
─────────────────────────────────── このメールは2003年6月11日現在、ソニースタイルログインIDをお持ちの方で メールマガジンをご希望の方にお送りしています。ブロードバンド常時接続環境の方はこちらをご覧ください。このマガジンと同じ 内容をビジュアルにわかりやす伝えています。 http://mail.jp.sonystyle.com/cgi-bin16/DM/y/mP250HXXXXXXXXXkUF0Bo
■□■━━━━━━━━━━━━━━━━━━━━━━━━━━━━━■□■
ソニースタイルが、顧客の安全性に配慮する企業であることをアピールするならば、HTMLメールをやめてしまえばいい。その理由を説明して、Webマガジンへのアクセスを積極的に促せばいい。
HTMLマガジンをWebに載せることの問題点として考えられるのは、メールを購読していない人にもマガジンを読まれてしまうことだろうか。しかし、宣伝広告なのだから、より多くの人に読まれることは歓迎のはずだ。日記からリンクされることで、読者数は増えるかもしれない。デメリットは、URLに購読者IDを埋め込めないので、これまでWebバグで追跡して得てきた情報が得られなくなることだ。これまで購読してきた人たちが購読をやめていくことで、得られる情報が減っていく。
■ そもそも追跡は必要なのか
今回のソニースタイルのメールマガジンの「text/html」パートには、しっかりとWebバグが埋め込まれていた。HTMLパートの末尾がこうなっている。
<IMG SRC="http://mail.jp.sonystyle.com/cgi-bin16/flosensing?y=P250HXXXXXXXXXDg"></html>「text/plain」パートも、上に紹介したように、リンク先に同じIDが埋め込まれているので、同様に追跡されている。
こうした追跡はなぜ必要なのか。[memo:6011]の事例では、
この仕組みから弊社が得ているのは、あくまでも「統計的データ」ということになります。
とのことだった。個人の特定が可能な状態ではあるが、個人の特定はしていないという。得ている統計情報は、メールが開封された数と、マガジン内の各リンクがクリックされた数であろう。
こうした統計が必要な理由は、メールマガジン発行業者（あるいはメールマガジンを書く担当者）の仕事を評価するためではなかろうか。ナローバンド時代のメールマガジンでは、いかに購読者にクリックさせるかが勝負だった。ダイヤルアップして接続料を払ってまでアクセスさせるには、興味をひく文章と章立てが求められる。いろいろな方法を試して、どれが効果的かを確認するために、そうした統計情報が必要なのだろう。メールを開封しただけでIDが記録されるのは、開封率を求めるためと言われているが、これは、開封率（送信数に占める開封された数の割合）よりも、クリック率（マガジン中の各URLがクリックされる割合）を求めるための分母としての開封数を調べるために必要としているのではなかろうか。
そうだとすると、マガジンをWebに置いた場合では、母数はアクセスログから得られるので、追跡は不要になるのではないか。WebマガジンのサーバでIDを入れたcookieを発行し、cookieのIDと共にアクセスログを解析すれば、何割の人がどこを見たかを分析できる。このとき、cookieはセッション限りのものとしておけばいい。バナー広告では、同じ人に同じ広告を何度も出さないなどの目的で、ハードディスクに保存されるタイプのcookieにIDを発行しているが、Webマガジンでは、アクセス動向だけを調べたいのだから、そうした永続的なIDを必要としない。セッション限りのcookieならば、ブラウザを終了した時点で破棄される。更新通知のメールにも個別にIDを入れる必要がないので、プライバシー侵害の懸念は消滅する。
さらに言えば、cookieすら発行の必要がないようにも思える。cookieなしでアクセス解析をしようとすると、IPアドレスを頼りにすることになる。大企業からのアクセスなどでは、ProxyサーバやNATがあるため、同じIPアドレスから多数の人がアクセスしてくる場合がある（あるいは、負荷分散Proxyサーバが使われているために、同じ人が異なるIPアドレスからアクセスしてくる場合もある）。しかし、得たいのは統計的な情報だ。有効桁は2桁か3桁程度だろう。その程度の情報を得るためならば、ラフな集計でも十分のように思えるのだが。
高木浩光＠茨城県つくば市さんが、「なぜ、企業はHTMLメールマガジンを送りたがるのか」という件について以下のような考察をしているが、外していると思う。
おそらく、メールマガジン業者のセールスにまんまとのせられているためではないかと憶測する。
メールマガジン発行元 *1 自身が自ら望んでHTMLメールを出したがっているという例も少なくないと思うんだけどね〜 もちろん、その裏にマーケティング手法をコンサルしている会社とか、広告企画をアウトソースしている会社とかがある 場合もある とは思いますが。
と指摘しているが、HTMLマガジンが見やすいものであって、ネットショップなどがそれを出したがっていることは百も承知だし、消費者としての私自身がそれを望んでいる。私が言っているのは、Webサーバに置かずにメールで送信して、Webバグにより追跡する仕組みを使うのが、メールマーケティング業者の都合に過ぎないのではないかということだ。ネットショップ事業者にとって、顧客のプライバシー不安のデメリットを犠牲にしてまで、得たい統計情報がそこに本当にあるのかと問いたい。
「DON's Diary」の続く部分にあるように、一部のメールマガジンでは、誰がどの項目を見たかを記録して、それに応じた案内をしているところもあるのだろう。だが、それをやっていない事業者もある。[memo:6011]の事例では、統計的な情報だけを得ているとされている。これらは分けて議論する必要がある。
ネットショップ事業者が、顧客のプライバシーを大切にしたいと考えて、個人を特定せずに統計情報だけを得るつもりでいても、委託されたメールマーケティング事業者が、個人を特定できる状態のシステムを動かしているというのはどうなのか。ネットショップ事業者は、その事実の意味を理解しているのだろうか。理解しておらず、メールマーケティング事業者の言われるがままにしているのではないか？というのが私の懸念だ。
とはいえ、今回のソニースタイルのメールマガジンのように、テキストメールにURLを書いてWebマガジンにアクセスを促す試みを、始めたばかりのときには、本当にアクセスしてくれているかを調べたいだろうから、開封率の値も欲しいかもしれない。これについては6月6日の日記に書いたように、ハッシュした値（情報量を削った値）を埋め込む方法をとることで、個人が特定されることなく、開封率を得ることができる。ソニースタイルが顧客のプライバシーを尊重するのであれば、こうした工夫をしてみてはどうだろうか。
まとめるとこうだ。「ナローバンドなダイヤルアップ接続が主流だった昔、メールマガジンというメディアが生まれた。購読者は、オフライン状態でテキスト情報を読み、特に興味あるところだけ、インターネットにつないでWebアクセスをするという使い方をしていた。メールマガジンの発行者は、どうしたら興味を持ってアクセスしてくれるかにしのぎを削った。工夫の効果を確認するため、URLに購読者IDを埋め込んで、何割の人がどこを見てくれたかを集計する仕掛けを始めた。こうした統計情報は、メールマガジンの発行を委託するネットショップにとって、成果を評価する上で常識的な手段となった。しかし、メールを送っても開封してくれない購読者が増えてきたため、クリック率は低下していく。より正しい評価をするには、開封した人のうちの何割がクリックしてくれるかを調べることだ。そのために、HTMLメールを使えば、Webバグを埋め込むことによって、開封率を取得できる。メールマガジンのHTMLメールへの移行には、そうした目的もあった。しかしどうだろうか。ブロードバンド常時接続が当たり前になってきた現在、もはや、メールマガジンのクリック率を気にする必要などなくなってしまった。消費者にとって、見たい情報を見るのにコストがかからなくなったからだ。それでも見ない人は元々見ない人なのであるから、開封しない人の数を数えることには意味がなくなった。それだけではない。ナローバンド時代でもHTMLメールマガジンは発行していたが、それはテキストのマガジンに毛が生えた程度の画像を付け加えたものだった。それが、ブロードバンドが普及するにつれ、HTMLマガジンの内容は、もはやメールマガジンのようなものではなく、通常のWebページと同じような構成をとるように内容そのものが変化した。こうなると、もはや、どの部分が沢山クリックしてもらえたかということも気にする必要がない。メールマーケティング業者は、クリック率集計システムという技術で商売を展開してきたが、ブロードバンドが主流となり、もはや出る幕がなくなってしまった。生き残っていくには、単なる統計情報ではなく、顧客を特定してカスタマイズした情報を提供する、一歩先のサービスを提供することだ。だが、これは、個人が特定されていることが消費者にバレバレであるため、顧客を大切にするネットショップ事業者は導入に慎重だ。将来に理解が得られるようになるまでに、なんとか、HTMLメールが当たり前のものとして普及する下地を作っておかねばならない。今こそ、日経BPに「今時HTMLメールが常識だよね」という提灯記事を書かせて、批判を牽制しよう。日経ネットソリューション6月号には、うまいこと「メール・マーケティングの新しい“姿”」、「PC向けテキスト・メールはもう限界 HTML,携帯メールが主役へ」、「HTMLメールが必須のツールに」、「もう“やっかいもの”じゃない」という記事を書いてもらえた。だが、IT Proでは、タイトルの決定権を持つIT Pro編集者に「HTMLが急増中」などというショボいタイトルに変えられてしまった。あげくに「HTMLメールはやめよう」だと？クソ」と。 これはあくまでも想像だが、はたしてどうだろうか。
メールマーケティングは、ちょっとしたITスキルを活用して、比較的容易に参入できるベンチャービジネスだったのではなかろうか。外資系の著名業者が複数日本支社を持つ上に、日本発の業者も一時期は乱立していたように思う。ブロードバンド化によって生き残る道が模索されているのであれば、古くからのシステムに安住して既得権にしがみつくのでなしに、顧客プライバシーを最大限に保護した新たなメールマーケティングシステムを開発し、他の事業者との差別化を図っていったらどうか。ネットショップにとっても、そうした事業者を採用することは顧客へのアピールになるだろう。ただし、そのためには、消費者がそうしたプライバシー問題の存在を知っていなくてはならない。
■ プライバシーポリシーで解決するのか
リンク元をたどって見つけた「つれづれなる備忘録」の6月8日の日記によると、
famima.com のサービスは Root Communications の HTMLメールマーケティングガイド (or VMM - HTMLメールのプロフェッショナルサービス )のやつですか。 ("HTMLメール" で Google で検索すると先頭の方に出てくるところですが。)
うーむ。 HTMLメールを発行する前に準備すること (Japan.internet.com Webマーケティング) の記事とか見るに、プライバシーポリシー&Webビーコンの話にも触れてるし、ここは比較的まともそうに思ってたんですが、実態はそうではないのかなあ。
とあった。
たしかに同社の、HOW TO HTML MAIL MARKETINGという解説には、「HTMLメールを発行する前に準備すること」として、ユーザーに不快感を与えないためにやっておくべきことがあると指摘している。そこに書かれているのは、(1)HTMLメールとは何か説明すること、(2)希望しない人に拒否できるようにすること、(3)プライバシーポリシーを提示することの3点だ。
(1)と(2)については、多くの事業者がそうした説明を実施している。しかし、(3)はどうだろうか。この解説は、同じものがjapan.internet.comにも掲載されているが、プライバシーについて書かれたのはたったこれだけでしかない。
■プライバシーポリシーの検討
これは HTML メールに限った話ではありませんが、メールアドレスやその他個人情報を取得するにあたっては、サイトとしてのプライバシーポリシーを明確にし、ユーザーに告知する必要があります。加えて、HTML メール固有の問題として、クッキーの使用や WEB ビーコンの使用の問題がありますが、この点についても使用に関する明確なガイドラインを設け、ユーザーに告知することが必要です。
メールマガジンでメールアドレスを収集するのは当たり前だ。Webビーコンについての言及があるが、「使用に関する明確なガイドラインを設け、ユーザに告知すること」としか書かれておらず、具体的に何を説明すべきなのかについて、説明していない。次の回のHTMLメールを発行する前に準備すること (2) では、
■丁寧な準備でユーザーの信頼を獲得
メールというメディアは「相手の世界に踏み込む」という特性をもっていますから、最初のメール配信でユーザーの信頼を獲得することができれば、その後のマーケティングの効果はグンと違ってきます。 HTML メールで新規に配信を始める場合も、テキスト形式から切り替えていく場合も、事前の準備をていねいにしておくことがユーザーからの信頼向上につながるという点では、変わりありません。
と締められている。顧客の信頼を得ることを大切にしているようだが、どうやらそれは、HTMLメールへの移行を事前に説明すること程度にしか考えられていないようだ。プライバシーポリシーの書き方はこの回でも説明されていない。
「つれづれなる備忘録」の続きの部分で紹介されていた、社団法人関西経済連合会の「関西Ｅビジネスネットワークプライバシーポリシー規定」というのを読んでみたが、これは駄目なプライバシーポリシーの典型だ。
第６条 クッキー(Cookie)及びWebビーコンについて
- クッキーは、インターネットの効果的な運用のために、ウェブサーバーが利用者のブラウザに送信する小規模の情報ですが、運営者は、利用者個々のニーズに合わせてウェブサイトをカスタマイズしたり、ウェブサイトの内容やご提供するサービスを利用者がよりご満足いただけるよう改良したりする為、クッキーを使用することがあります。
利用者は、ブラウザの設定により、クッキーの受け取りを拒否したり、クッキーを受け取ったとき警告を表示させたりできます。しかしながら、その場合はパーソナライズ機能などが使えないなどの制約が生じることがあります。- Webビーコン（「クリアGIF」）とは、利用者のコンピュータからのアクセス状況を把握して、特定のwebページの使用率等に関する統計を取ることができる技術です。本システムでは、ウェブサイト改善のための統計的情報取得などの目的で、Webビーコンを使用することがあります。
と書かれているが、これは、cookieとは何か、Webビーコンとは何かという一般的な解説を述べているに過ぎず、「使用することがあります」という表現は、使っているのか使っていないのかすら説明していない。つまり、この文章は、あらゆるサイトでコピー&ペーストで使える、オールマイティな文章であって、このサイトでどうしているのかということについて説明している情報量はゼロ。全く意味がない。こんなのは「ポリシー」でない。経済連合会でさえこの程度の認識なのか。
さて、ソニースタイルではどうだろうか。HTMLメールへの移行に先立って予告があったときには、HTMLメールとは何かという説明と、HTMLメールを拒否する方法の説明の後に、
また、HTML形式のメールへの変更にともない、一部配信に関する規約に変更がございます。下記をご確認ください。
と書かれていた。その規約はここにある。「クッキー」、「ビーコン」、「プライバシー」という文字列が見当たらないが、第10条に「利用者の利用者情報」という説明がある。
1. ソニースタイルは、次項に定める目的のために利用者から提供を受けた氏名およびメールアドレス、配信メール内URLからのウェブサイト閲覧および行動履歴等の利用者情報を、厳重な管理体制のもとで保持し、第三者が不当に触れることがないよう合理的な範囲内でセキュリティの強化に努めるものとします。
とあり、メール内のID付きURLから行動履歴を収集していることに触れている。しかしこの文は、セキュリティ保護に努めるという文なので、さりげなく書かれた、行動履歴を得ているという部分に、普通の消費者は気づかないのではなかろうか。
この規約は、個人情報保護法をにらんだ法的な防衛でしかなく、消費者への説明にはなっていないように思える。Webビーコン付きのHTMLメールを始めるときに必要な消費者への説明は、以下の点ではなかろうか。
- ビーコンによってどんな情報がどこに蓄積されるのか
- 蓄積した情報はどのようにしか使わないのか
前者については説明されていない。「ウェブサイト閲覧および行動履歴等の利用者情報」という大雑把な説明があるだけだ。これでは、普通のWebアクセスのIPアドレス記録のことかと誤解する消費者が多いだろう。どのメールアドレスの人が、何時何分に、どこを見たかが記録されるという事実を具体的に説明しなくては、単なる防衛線でしかなく、顧客の信頼を得るための説明ではない。
後者については、続く部分に次のようにある。
2. ソニースタイルは、以下の各号に定める目的で利用者の利用者情報を利用するものとし、それ以外の目的で利用者情報を利用する際には、別途目的を明示し、利用者の同意を得るものとします 。
- 電子メールによる各種情報配信サービスの企画・提供
- ソニースタイルに対するご意見やご感想の提供のお願い
- 統計資料の作成
「電子メールによる各種情報配信サービスの企画・提供」というのがあると、何でもアリではないか。個人を特定して行う情報配信サービスもやると、この文章は言っているのだろうか。統計情報にしか使わないのか、個人を特定したサービスを行うのか、はっきりした説明になっていない。
ちなみに、
4. 利用者は、別途ソニースタイルが定める手続により、ソニースタイルに提供した自己の利用者情報の照会、修正および削除を行うことができます。ただし、配信メール内URLからのウェブサイト閲覧および行動履歴など、ソニースタイルが自動的に取得する情報については対象外といたします。
とあり、行動履歴は削除してくれないそうだ。
■ tracerouteしてみよう
ソニースタイルのメールマガジン内のジャンプ先URLは、mail.jp.sonystyle.com というホストだった。ここへ tracerouteしてみると、
12 28 ms 23 ms 30 ms ge9-0-1000M.cr1.NRT1.gblx.net [203.192.128.237] 13 177 ms 171 ms 218 ms so1-3-0-622M.ar2.DEN2.gblx.net [208.49.91.45] 14 172 ms 167 ms 170 ms Double-Click.so-1-0-0.ar2.DEN2.gblx.net [204.246.203.254] 15 168 ms 169 ms 170 ms network-65-167-64-66.dclk.net [65.167.64.66]にたどり着く。DoubleClick社か。気づかなかった。 メーラのゴミ箱を漁ると、これまでフィルタで自動的に捨ててしまっていた、日本航空と、アップルコンピュータのメールマガジンが見つかった。HTMLパートだけのメールだったので、spam扱いして捨ててしまっていて気づかなかった。そこには、やはりWebバグが埋め込まれていて、それぞれ
jmb.jal.co.jp news.apple.co.jpというホストにアクセスするようになっていた。これらについてもtracerouteしてみると、ソニースタイルと同じく「network-65-167-64-66.dclk.net」にたどり着くようだ。ありとあらゆる企業の顧客の行動履歴がダブルクリック社に蓄積されているようだ。
他の会社がDARTmailのテクノロジーを利用して電子メールの送信を行う場合、
の部分を読んでみたが、メールにWebバグを入れていることについて書かれていない。
「ウェブサイト上で取得した個人情報の取り扱いについて」には、
5.当社のウェブサイトについて（クッキー及びクリアーＧＩＦについて）
当社のウェブサイトはアクセスしたユーザーがウェブサイトをより効率よく使用できるようにするために、クッキーまたはクリアーＧＩＦを使用しています。これらのクッキー及びクリアーＧＩＦは、インターネット上の広告配信に用いられる当社のクッキーとは何ら関係がなく、かつ、個人を特定しうる情報を含むものではありません。
という説明があるが、メール中のクリアーGIFが「個人を特定しうる情報を含むものではない」というのは事実でない。しかし、この説明は、www.doubleclick.ne.jp に関する説明なので、メールのWebバグとは関係がないのだろう。
メールマガジンのWebバグに関する説明は、配信業者ではなく、発行事業者が説明するのが筋なのだろうか。
日本航空はどう説明しているだろうか。JAL 個人情報の保護を読んでみると、ウェブビーコンの使用についてという項目があるが、「ウェブビーコンを使用した調査についてはYahoo! JAPANに委託しております」とあり、メールマガジン中のWebバグについては述べていないようだ。JALマイレージバンク会員向けページ内の「Eメールアドレス登録・変更・削除」の画面に、「HTML形式でのメールニュースを 受信する/しない」の選択肢があるが、ここで説明されているのは、以下のことだけだ。
HTMLメールとは、通常のメール（テキスト形式）を発展させた形のメール形式で、画像を表示したりすることのできるメールです。
※HTML形式のメールをご覧いただくには、HTML形式のメールに対応しているメールソフトが必要です。 HTML形式対応については、メールソフトメーカーまたはサービスプロバイダにご確認ください。
■ 関連情報
- ZDNN: スパムに潜む小さなスパイ (2002年4月)
ユーザーのオンラインでの行動を追うcookieやWebビーコンは，WebサイトだけでなくHTML形式のメールからも送られてくる。だが，商業Webサイトでは既に定着しているプライバシーポリシーの開示が，この種のメールでは確立されていない。
...
メールに関するプライバシー施策を開示する上での問題の1つは，メールマーケティングキャンペーンの大部分が，サードパーティを介して，（広告主と）離れたところで行われていることから生じている。このため，メールマーケティングサービスを実施する企業は，キャンペーンを代行している企業がどういったことをやっているかを，常に完全に把握していない可能性がある。 - ZDNet エンタープライズ ニュース: その個人情報は本当に必要か？ アクセンチュアが語る個人情報保護対策 (2003年6月)
武田氏はもう1つ、興味深い指摘を行っている。「中には、特に明確な目的もないままに個人情報を収集しているケースもある。しかし、企業が個人情報を保有するということは、1つのリスクでもあり、不要な情報まで保有するのはリスクを高めることだ。“本当にその個人情報は必要なのか”といったところに立ち戻って見直す必要がある」
- ZDNet エンタープライズ ヘルプデスク: 第1回：プライバシーの保護は必要か？−Webバグ− (2001年12月)
しかし，こういった情報収集行動について，ユーザー側がその存在を知っているか，いないかでは大きく変わってくる。ユーザーが知らなければ「プライバシーの侵害だ」と，プライバシー援護団体などから猛反発をくらうことになる。クッキーの章にも書いたが，クッキーファイルもまた，ユーザーの知らぬ間に利用されているということで，プライバシー援護団体から問題視されている。
6月7日の日記で、「日本で独自にWebバグについてコメントした公式な発言は極めて少ない」と書いたが、上のZDNetの「プライバシーの保護は必要か？−Webバグ−」にそれがあった。しかし、この記事も間違ってはいないが、微妙に説明が足りないように思う。
これは「single pixel GIF」や「Webビーコン」などと呼ばれることもあり，多くのサイトで使用されているようだ。ただし，プライバシーの侵害といっても，世間で騒ぐほど重大な情報が，Webバグで漏れているわけではない（通常の閲覧時で悪意のあるものは省く）。...もちろん個人名やメールアドレスなど情報が漏れるわけではないため，個人を特定するものではないが，クッキーを使用して，同じユーザーが何回訪問したかなどの情報は得ることができる。
とある。これは、Webページに埋め込まれたWebバグのことなので、これでもよい。続く部分で、
これはHTMLメールでも同様に使用できる。HTMLメールを受信したユーザーが，そのメールをHTML対応メールソフトで閲覧すれば，メールを閲覧したユーザーのメールアドレスと，メールを閲覧したか否か，そしてメールを閲覧した場合は，その日時などの情報が得られる。
と一応は説明されている。しかし、この部分が目立たない。最後には、
ただし，ブラウザのセキュリティホールなどを利用する「悪意を持った情報収集」は別として，どのページを参照したかなどの情報は広告業者に限らず，Webサイトを作成，管理する側でも日常的に収集されており，それらの情報を元にWebページの改変などを行っている。つまりWebサイトを作成している側から見れば，これらの情報から個人が特定できるわけでもないので，なぜプライバシーの侵害と騒がれるのか，いささか疑問が残るのではないだろうか。
とまとめられているので、ここが目立ってしまう。続く部分に、
しかしHTMLメールでのWebバグは，スパマーが悪用すれば，どういったユーザーがスパムメールを読んでくれたか（つまり生きているメールアドレス）を教えてしまうため，あまり好ましい行為とは言えないのかもしれない。
と書かれているが、「あまり好ましいとは言えない」という程度のものではないし、spamだけでなく事業者が個人を特定していることについて紹介しておく必要がある。（といってもこの記事は1年半前に書かれたものだ。）
2003年06月17日
■ Webバグの責任分界点
一昨日の日記の「tracerouteしてみよう」で、mail.jp.sonystyle.com や、jmb.jal.co.jp、news.apple.co.jp がDoubleClick社に到達することについて書いたところ、悪いイメージを抱いたらしい反応が見られた。たとえば「ただのにっき」の6月16日の日記では、
今回の記事で一番衝撃だったのは、いろんな会社のメルマガに仕込まれているWebバグが、実はみんなDoubleClick社に通じていたってとこだな。これじゃドメイン名なんて信用できないじゃん。
という反応があった。類似の反応が他にもいくつかあった。その一方で、「Tea Room for Conference」No.1417では、
でも、このような例はむしろ良心的なのだと思う。ドメインがメールマガジン発行主体（発注元）のものになっていれば、メールマガジン発行主体が掲げているプライバシーポリシーで「当ホームページにおいて」などと書いていれば、Webバグの仕組みも「当ホームページ」に配下にあることことは明らかであり、責任の一端をメルマガ発行主体にあることが明確になるからだ。
というコメントがあった。
私は、これは、ソニースタイルが自身がすべての責任を負うのだということを消費者に明示しているのだと思う。ドメインを借りるには、ドメイン保有者の許可が必要であり、まともな組織であれば、自社のセキュリティポリシーに厳格に従わせた上で貸与しているはずだからだ。ソニースタイルのメールマガジンの利用規約にも次のように書かれている。
利用者から同意を得た目的のために、事業協力会社に対する利用者情報の開示が必要な場合。なお、この場合ソニースタイルは、当該事業協力会社に対して、当該利用者情報の厳重な管理を求め、利用者から同意を得た目的以外の利用を行わせないものとします。
一方、日本航空はどうか。日経BizTechの「本格的に動き始めた電子自治体」の「プライバシーポリシーの明示を！」によると、
サイト上での個人情報の保護について、お手本となる自治体はほとんどないようだ。企業ではこの点、非常にシビアに取り組んでいる。例えば日本IBM、日本航空のサイトのプライバシーポリシーなどが良い手本となる。手前味噌で恐縮だが、日経BP社のプライバシーポリシーも充実している。
とある。たしかに、日本航空のプライバシーポリシーは正しい書き方がなされている。「クッキーの使用について」では、
当社がクッキーを使用するのは以下の場合に限定しております。
○JMB会員専用ページにログインしていただいた後のセッション管理を安全に行うため ...
○「国内線空席照会」、「国際線空席照会」における入力補助を行うため ...
○「体験！JAL WEB」において、JALホームページのサービスをより忠実に再現するため ...
...
というように、cookieを何の目的で発行していて、それがどの程度の必然性のあるものであるかを具体的に説明している。一昨日参照した社団法人関西経済連合会のようなオールマイティで情報量ゼロの勘違いポリシーを掲げたサイトが多いのと対照的だ。
それだけ何を書くべきかをわかっている人によって日本航空のプライバシーポリシーは書かれたのに、HTMLメールマガジンのWebバグについて記述がないのはなぜだろうか。cookieや、ここに書かれているWebビーコン（Webページ内のWebビーコン）よりも、メール中のWebバグは、プライバシーへの影響が大きいものなのに。
想像するに、日本航空の個人情報保護担当者は、DoubleClick社のHTMLメールがそうしたことをやっている事実を知らされていないのではなかろうか。HTMLメールマガジンを始めるにあたり、プライバシーポリシーを改定する必要性に気づかなかったのではなかろうか。そうしたことはメールマガジン配信業者が説明しておくべきだろう。
プライバシーポリシーの提示がなぜ必要なのかというのは、こうした、知らないうちに、主体者が了解していない行為が、委託先によって行われるという事態を防止するためにもある。だから、プライバシーポリシーは具体的でなければならないのだ。コピー&ペーストで使えるようなものを掲げていると、こうした事態に気づくことができない。プライバシーポリシーは事業者にとっての自己点検リストでもある。
■ 塚田氏からメールを頂いた
一昨日の日記の「プライバシーポリシーで解決するのか」で触れた、「HTMLメールを発行する前に準備すること」の著者である塚田氏からメールを頂いた。内容を紹介してよいかについて確認中。
2003年06月18日
■ ルートコミュニケーションズがやってくれるらしい
6月15日の日記の「プライバシーポリシーで解決するのか」で話題にとりあげた「HTMLメールを発行する前に準備すること」の著者である塚田耕司さん（株式会社ルート・コミュニケーションズ代表取締役）から、この日記で書いたHTMLメールのプライバシーに関することについて、メールを頂いた。その内容の一部について日記に書いてよいとのお返事を頂いたので、私の理解した言葉で書くことにする。
「プライバシーについての配慮や取り組みについて、メディアやクライアントに説明できているつもりであったが、第三者から指摘されてそれが足りていなかったことに気づいた」とのことで、次の取り組みを進めているそうだ。
- 現在の配信システムについて、Webビーコンなしをデフォルトとし、依頼企業のプライバシーポリシーに適切な記述が認められる場合にのみ、Webビーコンを使用することにした。
- 開発中の次期配信エンジンでは、マーケティング機能に3段階のプライバシーレベルを設け、顧客のプライバシーポリシーに応じて選択できるようにする。
- 「HTMLメールマーケティングガイド」やInternet.com掲載のコラムに、新しい記事として、Webビーコン使用時のプライバシーポリシー記述に関するものを執筆する。
すばらしい。3段階のプライバシーレベルとは次のものだそうだ。
- 配信のみでマーケティング的な計測は行なわない
- 個人を認識せず、全体もしくはグループとしての動向把握
- 個別ユーザーと対になるIDをもった形での動向把握
1.はWebビーコンなしという意味だろうと思う。2.はハッシュしたIDや、属性（年代や性別）コードをビーコンのIDとする方式なのかなと想像する。
プライバシーポリシーをどう書くかだが、1.のケースでは、「Webビーコンを使用していません」と書くのだろう。現状では、プライバシーにかかわる仕掛けを使用している場合にだけ、プライバシーポリシーに書くという風潮があるように思うが、こうした「使用していません」ということを胸を張って示すという流れが出てきて欲しいように思う。「使ってもいないのに、そんなお客様が意味を理解できない言葉をあえて書く必要ないよ」という発想をする責任者がいて、なかなか実現しないかもしれない。どこか、公的なところ（プライバシーマーク事務局や、IPAのようなところ）に、WebバグやWebビーコンの解説ページがあれば、そこへリンクして、「当社ではそれを使用していない」と書けるようになるかもしれない。
2.のケースでは、Webビーコンの実例を示して、次のように説明するのが理想的だと思う。
メールマガジンには、Webビーコンと呼ばれる次のようなコードを埋め込んでいます。
<img src="http://beacon.example.com/?hash=99&age=3&sex=0">
「99」の部分の番号は、お客様にその都度ランダムに割り当てた2桁の番号です。これは100人ごとに同じ番号が割り当てられますので、お客様個人を特定するIDではありません（購読者が10万人の場合、1000人が同じ番号を持つことになり、そのうちの誰であるかは特定されません）。「3」は年代を表すもので「3」は30代を表します。「0」は性別で男性を表します。これらの番号は、配信したメールマガジンの何割が開封されたか、どの項目が閲覧されたか、また、それらが年代や性別とどのような相関関係を持つかを統計的に調べるためのものです。お客様のプライバシーを保護するため、個人を特定せずに、統計的な情報しか記録できないように配慮した仕組みです。
しかし、広告を出稿する事業者からすれば、こうした具体的なことを書いてしまうと「かえって購読者が不安がる」という懸念をすることがあるかもしれない。というか、いかにもありがちだ。上の説明は、「個人が特定され得るIDでWebビーコンが埋め込まれている」という現状を知っている消費者からすれば、安心できる説明となるが、そもそもこれまでにそうした情報収集が行われていたことを知らない消費者からすれば、「気持ち悪い」という印象を持ってしまうかもしれない。中途半端な説明でなんとなく凌いでいくか、正直に事実をすべて告げて信頼を得ていくかの選択となると思われる。
「正直な説明をしても報われない」ということにならないよう、私も微力ながら何かをしていきたい。こうしたことは、マスメディアの方々に期待したいところだ。
2003年06月19日
■ EZwebを初めて実用的に使った
これまで、私の携帯電話に付いているEZwebブラウザは、着メロのダウンロードくらいにしか使っていなかったのだが、今日、終電を逃してしまい、宿を当日予約するため、やむにやまれず、某ホテル予約サイトを使った。
これで、そのホテル予約サイトがもし、アクセスログにsubscriber IDも記録しているなら、私の氏名と、某携帯電話事業者における私の契約者番号（subscriber ID）とが結び付けられ得る状態になった。
もし、そのホテル予約サイトが、subscriber IDと氏名との対応表を転売したならば、その対応表を購入した任意のサイトは、私がそのサイトにアクセスしただけで、それが私であることを氏名で特定できることになる。
そろそろｉモードに変えたいよー。マジで。番号さえ変わらなければなあ……。
2003年06月21日
■ 電子政府に向けての社会基盤シンポジウム
情報処理学会EIP研究会主催の「電子政府に向けての社会基盤シンポジウム」に参加してきた。情報処理学会の場でこうした内容について議論されることに期待に胸を膨らませ、土曜なのに眠い目をこすり朝から出かけたのだが、内容は残念なものだった。発表時間が短すぎて質疑応答がほとんどの発表で省略された。これでは、シンポジウムではなくて、セミナーだ。（遅刻して聴き損ねた最初の一件と、途中からしか聴けなかった二件目を除き）ほとんどの講演が基礎的な内容に（おそらくあえて）とどめられていたので、質疑応答にこそ意義があったはずなのに。はなから一件も質問を受け付けようとしなかったあの座長は、何のためにこういう会合をやっていると思っているのだろう。
講演後に名刺交換にうかがって、井上源三自治行政局市町村課長に直接質問と議論ができたのが大きな収穫だった。
■ マーケ本を物色
八重洲ブックセンターの横を通りがかったので、IT本コーナーへ。CRM (Customer Relationship Management) だの、ワン・トゥ・ワン・マーケティングだのの本をパラパラとめくり漁る。マーケな人たちは何をやろうとしているのか、知っておかないと。どれも1999年ごろに書かれた本で、新しいものがないようだった。
ISBN:4-478-50170-Xから引用:
Q83 カードシステムを導入したいと考えていますが、ワン・トゥ・ワン・マーケティングに発展できますか？
...顧客固定化に最も有用なのはプリペイドカードですが、これはワン・トゥ・ワンにはなりません。クレジットカードも顧客識別できる以上、その発展の可能性を秘めていますが、現状では代金決済以外の用途に活用されているとはいえません。
「代金決済以外の用途に活用されているとはいえません」って、そりゃそうだろ。……いや、クレジットカードの目的外使用の禁止って、カード会社が規定しているのかなあ。
...また、ワン・トゥ・ワンの観点からは、来店時に顧客識別できることが大切です。...「いらっしゃいませ、○○様」と声のかけられる接点対応から始まるのと、最後の「ありがとうございました、○○様」では、コミュニケーションの密度と時間に相当な開きがあり、結果として顧客心理も別のものになります。
ですから、最終的な顧客識別方法は、カードシステムではありません。顧客の顔を遠くから見ただけで識別できるシステムがベストでしょう。...本人認証技術で注目されているのは、バイオメトリクスという方法です。...将来、顔貌や虹彩などによる認証技術が発展すれば、やがて解決していくと考えられます。このあたりの期待は飲食店に多いと思います。
そんな店、嬉しいかねえ。プライバシー云々以前の話として。「いらっしゃいませ○○様、いつものですね？」と機械に言われると。……あ、違う。そういう話ではないらしい。従業員が機械に自動的に表示される顧客の嗜好情報を見て、あたかも暗記しているかのように応対することを狙っているのか。いきつけの理髪店で受付で氏名を書くと、理容師が裏でカルテを見て客の好みを把握して出てくるのと同じか。
2003年06月22日
■ 意図的な収集と結果的な収集
「Netscapeのプライバシー訴訟、解決へ」(CNET News, 2003年6月16日)というニュース記事が出ていた。これによると、
今回、調査官は、Netscapeが公表しているプライバシーポリシーに反して、SmartDownloadを利用したユーザーの振る舞いを監視し、ダウンロードしたファイルの格納場所などの操作情報を保存していたとの結論をまとめた。
という。
「SmartDownload」とは、Netscape Communicator 4.Xに付属して、デフォルトでインストールされるようになっていた別ソフトウェアで、現在も配布されている。これをインストールすると、Netscapeで（だけでなくInternet Explorerなどの他のブラウザでも）「.exe」または「.zip」の拡張子のファイルをクリックしたとき、そのすべてがSmartDownloadでダウンロードされるようになる。Netscapeの標準のダウンロード機能の代わりにSmartDownloadを使うことの意義は、大きなファイルをダウンロードしている途中で一時停止し、後からいつでもそこから再開できるというものだ。
- 中断してもダウンロードを再開できる「日本語版Netscape SmartDownload」 (ZDNet JAPAN, 1999年8月2日)
当時のNetscapeユーザは、突如広告が出るようになったことを覚えているだろう。この広告ウィンドウは、クローズボックスが押せないようになっていて、広告を消すことができないというウザいものだった。それがSmartDownloadによるダウンロードだ。大きなファイルをダウンロードするという長い時間待ちの間に、広告を見させるというのも、SmartDownloadの「スマート」な機能であった。
Netscapeに対する訴訟は2000年7月に起こされた。
- ネットスケープがプライバシー訴訟の標的に (WIRED News, 2000年7月7日)
- 「Netscapeブラウザがプライバシー侵害」――AOLに新たな集団訴訟 (ZDNet News, 2000年7月10日)
この訴訟で問題とされたスパイ行為とは、ダウンロードの際に、そのファイルのURLが cgi.netscape.com に送信されるようになっていたことらしい。加えて、ユーザのコンピュータごとに固有のIDを格納したcookieが発行されていたことも含むようだ。
- Experts Claim Netscape Browser "Spies" On Users (ComputerUser.com, 2000年7月17日)
Netscapeはなぜこのようなことをしたのだろうか。「Netscape，「ユーザー監視」の指摘を受けSmartDownloadの一機能削除へ」(ZDNet News, 2000年8月5日) によると、
同社広報担当者は「この機能はもともと，技術サポートの目的で組み込まれたもの。だが当社はこれまで一度もこの機能を使ったことはなく，またSmartDownloadユーザーについての情報を取得したこともない。当社としてはこの機能を将来のバージョンから削除する予定だ」と話している。
という。
あえて「Netscapeがスパイ行為をするはずがない」という信仰的発想に立ち、「技術サポートの目的」という言葉を信じるならば、cookieのIDは、広告の効果的な表示のために発行していたと考えることができる。あるユーザの画面で、既にクリックした広告が再び表示されるのは、広告としては効率の悪い表示方法だ。そのため、バナー広告と同様に、クリック済みの広告が再び出ないようにしたり、満遍なく異なる広告を表示するために、まず、ユーザを特定して、ユーザごとの情報をデータベースに持つことで、広告を制御するということが行われているのだろう。しかし、これと、ダウンロードファイルのURLの記録とを合わせると、結果的に、ユーザごとに何をいつダウンロードしたかが特定されることになる。
「一度も使ったことはない」という発言は、6月15日の日記と6月6日の日記でとりあげた、[memo:6011]の事例にも見ることができる。このメールマガジン発行者は、
この文字列は、〓〓〓〓〓〓〓にご登録いただいたメールアドレスの情報と関連付けられており、URLをクリックすることで、そのユニークな文字列からアクセスがあったことの記録は残されますが、
と述べてた一方で、
ご指摘のとおり、この「ユニークな文字列」は配信されるメールごとに異なりますので、詳細な調査を行えば、それがどのメールアドレス宛てに配信されたものかを特定することは可能です。
ただし現時点では、この「ユニークな文字列」は、配信されるメールごとに固有のURLの一部として割り振られているだけで、お客様のメールアドレスと明確に 「関連付け」てはおりません。また、ダウンロードの有無によらず、どのお客様がアクセスされたか、という情報について確認および記録等の行為は行っておりません。つまり、現時点でこの仕組みから弊社が得ているのは、あくまでも「統計的データ」ということになります。
と説明している。
これらの事例に共通しているのは、個人の動向を特定可能な仕掛けは用意したけれども、それを活用してはいないという態度だ。プライバシーについての批判があったとき、こう答えることで、懸念を否定したことになる。つまり、結果的に収集されてはいるが、意図的に収集したものではないというわけだ。
しばしば、プライバシー侵害を懸念する立場の者は、そうした情報収集事業者に対して、悪の事業者であるかのようなニュアンスで非難することがある。しかし、そう非難したところで、「別の正当な目的のため収集した情報が、結果的にそのような目的のためにも利用可能な状態となっただけで、そうした目的では使用していない」と否定されれば、悪の事業者だとする非難は、一般大衆からすれば妄想に見えてしまうかもしれない。
ここで重要な論点が2つある。
まず第一に、その事業者は本当に最初からそうした目的を意図していなかったのかどうかだ。つまり、プライバシーの懸念を指摘されたためその目的での利用を取りやめただけではないのかという疑いがある。Netscapeの事例では、「もともと，技術サポートの目的で組み込まれたもの」、「これまで一度もこの機能を使ったことはない」とのコメントが報道されているが、「技術サポート」の意味が、「広告を効果的に表示するための技術的仕掛け」のことを指す可能性を含めれば、実は「元々は消費者のアクセス動向を追跡して利用する意図があった」のだとしても、矛盾しない発言といえる。
したがって、事業者の意図が不明確な段階では、悪意（少なくない人たちにとって懸念される行為）があるのではないかとする疑いを表明して批判することは、事業者に本当に悪意があるかないかとは無関係に、正当な行為である。悪意がないことを文書で約束させることに意義がある。
[memo:6011]の事例では、「何のためにメールアドレスの情報と関連付けを行っているのですか？」という問いに対して、事業者は、
前述のとおり、現在はメールアドレスとの関連付けは行っておりませんが、将来的には、どのアドレスに送ったメールからアクセスがあったのかということを、メールを利用したマーケティング手法の一つとして把握する必要が出てまいります。その際には配信対象者へ必要な情報を開示し、承諾を得ながら実施いたします。
と答えている。この約束をプライバシーポリシーで表明させることに意義がある。
第二に、事業者がそうした意図で活用しないつもりであっても、依然として後で活用可能なデータは蓄積されるのであり、それが漏洩した場合や、他社に転売されたときにどのように使われることになるかはわからない。転売はしないとプライバシーポリシーで約束されている場合であっても、その事業者が倒産したときにはどうなのか。日本では過去に、「凸版印刷：顧客名簿を担保、売却 ５０万件 通販会社倒産で」(毎日新聞, 2001年7月5日)という事例が起きている。引用すると、
凸版印刷広報部は「法律上、適正に処理された。当事者間の問題であり、詳細な説明は控えたい」と話している。
とある。
事業者に活用の意図がないならそうした情報は集めなくても良いはずだ。漏洩の危険性や、倒産による売却の可能性が残るなら、集めない方がよい。集めなくて済む手段があるなら、集めないべきである。集めなくて済む簡単な手段が存在する場合があることは、6月18日の日記の事例が実証した。不必要な情報を「大丈夫だ」との説明の下で収集し続けるのを考え直させるには、危うさを指摘し続けるしかないだろう。
このように、こうした批判は必要なことであるが、必要のない批判が合わせて行われることがあり、それが逆効果を招くことがある。一度あげたこぶしを降ろせないのか、いつまでも当初の悪意があることを前提とした指摘を続けることなどがそれだ。それを傍観する一般大衆は、電波系サヨク市民運動家のレッテルをはり、関心を背けてしまう。
ただし、続けなくてはならない批判もある。「そういうことはしない」という約束が守られなかったときに法的責任を取らさせる仕組みができていない社会では、何もしないでいるわけにもいかないだろう。「約束を守らなくても責任を負わなくて済む」のは別問題であるから、当事者は別問題だと一蹴するかもしれない。そういうとき、いったいどのような行動を取るべきなのだろうか。
関連報道
- FTCも動き出した“DoubleClick問題”，渦中のCEOに聞く (ZDNet, 2000年2月16日)
- DoubleClickの新プライバシー指針，消費者団体は「スタンドプレイ」と批判 (ZDNet, 2000年2月15日)
- 「プライバシー侵害」と消費者団体から反発受けるDoubleClickのデータ照合 (ZDNet, 2000年1月27日)
2003年06月24日
■ 通信キャリアの独占型PKIは安全なのか
「ドコモ、FOMA向けクライアント認証サービス「FirstPass」」(ZDNet JAPAN Mobile, 6月20日) というニュースが出ていた。SSLのクライアント認証が携帯電話で利用できるようになるらしい。
これは携帯電話のWeb機能の安全確保にとって画期的なことだ。なぜなら、これまで、携帯電話向けのWebアプリケーションには、セキュリティ的に怪しげなものが多く、かなりまずい状況ではないかと心配していたからだ。携帯電話の通信キャリア自らが、アクセス制御の欠如したWebアプリを提供していたという事例すらある。
- Re: auのWAP2.0端末によるHTTP_REFERERの誤送信について (BUGTRAQ-JP, 2002年7月30日)
auの携帯電話はWeb上から通話/通信料金の確認を行なう事ができます。このURLは下記のようなもので、実際には"x"の部分には数字が入ります。
http://cs-ez.au.kddi.com/IDOCustomerService?pageId=CMNxxxG&custID=Dxxxxxxx&menuId=CCI
このページが、auの携帯電話だけでなくインターネットにつながっている端末ならどれでも(HDMLでかかれていますが)このURLを指定するだけで、認証なしに料金を参照できるようになっていました。
携帯電話向けWebアプリが危なっかしいのには、いくつかのシステム的な原因が考えられる。ひとつは、cookieをサポートしていない端末があるため、セッション管理をcookieを使わずに怪しげな方式で作ってしまいがちということ、もうひとつは、携帯電話の操作性の限界から、ユーザにとってユーザ名とパスワードを入力することが面倒であるため、そうしたアクセス制限をかけずに、指定のURLにジャンプするだけでアクセスできるという「なんとなく認証」が使われていることがある。
- auのWAP2.0端末によるHTTP_REFERERの誤送信について (BUGTRAQ-JP, 2002年7月25日)
J-Phoneは自社や他社の携帯電話他へ写真を通常のメール以外でもWeb経由で伝えるサービスを行なっている
このサービスは、主に携帯電話向けに送ることを想定しているためかメールや写真が記載されたページを参照するためのパスワード等の認証機能はなく、複雑で予想されにくいURLを生成することで秘匿性を保っている。
こうした状況がある中で、端末にクライアント認証が導入されるというのは、劇的な安全性向上が期待できる。なぜなら、クライアント認証付きのSSL接続では、サーバ側は、アクセスのたびに、クライアント証明書のCN (Common Name)を読み出すだけで、アクセス者が誰であるのかを特定できるため、面倒なセッション管理の仕組み（セッションIDを発行したり、それを元にユーザを特定する検索機能）を実装する必要がない。そのため、これが普及すれば、素人設計の危ないWebアプリケーションは減っていくだろう。
クライアント認証の有効性は、携帯電話だけでなく、一般のWebにおいても同じだ。Webアプリケーションにおけるセッション管理方式として最も安全なのは、クライアント認証である。しかし、現時点ではほとんど使われていないのが実情だ。使われているところというと、野村證券のホームトレードなど、数えるほどしか知らない。
クライアント認証が普及していないのには理由がある。コストが高いからだ。証明書を発行する中間認証局を運営するため、システムを構築（もしくは購入）し、認証局運用規定を整備し、VeriSign等の（一般のブラウザに普及している）ルート認証局から中間認証局の証明書（年間100万円ほど）を購入しなくてはならない。
それに対し、今回のFOMA向けクライアント認証では、ZDNetの記事によると、
初年度で10数万程度の証明書発行を行い、対応サーバ数は数百を見込む。今後登場するすべてのFOMAで対応する予定。料金は無料となっている。... サーバを構築する企業は、事務手数料3000円のみが必要。
ドコモ、FOMA向けクライアント認証サービス「FirstPass」 (ZDNet JAPAN Mobile, 6月20日)
と、激安になっている。社員が外出先から社内システムにログインするシステムなどで大きな需要があり、これは急速に普及するように思える。
しかし、ここで持つべき疑問は、「どうしてこんなうまい話があり得るのだろうか」ということだ。一般のWebで、中間認証局の証明書を購入するのに年間100万円ほどするというのは、高すぎるように思われるかもしれないが、認証局業務には高度な安全性が求められるのであり、それに必要なコストを各事業者が、そしてその各利用者が分担して負担するという仕組みになっている。NTTドコモの今回の「FirstPass」サービスが激安なのは、コストが電話料金に含まれているか、さもなくば、安全対策へのコストが小さくなっているのではないかと考えられる。
もうひとつ疑問に思うべきなのは、
各サービスごとに複数のID・パスワードが必要だった従来のID・パスワード認証よりも簡単な操作で、
ユーザーは複数の証明書をダウンロードする必要なく複数のサイトで利用が可能だ。
ドコモ、FOMA向けクライアント認証サービス「FirstPass」 (ZDNet JAPAN Mobile, 6月20日)
という点だ。つまり、ドコモが発行したクライアント証明書を、異なる複数の事業者のサーバで使用するというのだ。
一般のWebのクライアント認証では、普通こういう使い方をしない。たとえば野村證券のサービスで発行してもらったクライアント証明書は、野村證券のサービスでしか使えない。ブラウザには複数のクライアント証明書を格納できるようになっており、アクセス先がクライアント証明書を要求してきたとき、どれを送るかをユーザが選択するようになっている。
ドコモの「FirstPass」対応FOMA端末では、複数のクライアント証明書を格納できるようになっているのだろうか。ZDNetの記事にある写真からでは、選択なしに「ユーザ証明書を送信します はい/いいえ」となるように見える。ただ、2つ以上の証明書を格納している場合に別の画面が出る可能性もあるので、これは確かではない。
証明書のcommon nameはどうなっているだろうか。一般に、common nameの名前空間は、その証明書を発行した認証局単位に別々となる。つまり、○○証券のサービスが発行するクライアント証明書では、○○証券が自由に名前を付けることができる。偶然に他のサービスと同じ名前の証明書を発行することがあるかもしれないが、各証明書は発行した認証局のサービスでしか使えないので、衝突することはない。つまり、クライアント証明書のcommon nameは、一般的なWebサイトのログインサービスの「ユーザ名」と同じ性質を持つ。あるサービスで使っている名前は、そのサービスでしか有効でないし、ユーザは、サービスごとに異なる名前を使うのが一般的である。
それに対し、ドコモの「FirstPass」では、認証局が唯一つしかなく、各サービスで共通して同じクライアント証明書を使うのであるから、名前は、各サービスで共通とならざるを得ない。具体的にどうなっているかというと、日経IT Proの記事によると、
端末にはあらかじめ，FirstPassが発行した証明書を入れておく必要がある。通常SSLのクライアント認証用証明書にはメールアドレスなどが入っているが，この証明書にはFirstPassが発行する固有のID番号が入っている。携帯電話ユーザーのプライバシーに配慮したためだ。
SSLクライアント証明書をFOMA端末に無償で発行，NTTドコモが携帯初のサービスを開始 (日経IT Pro 日経バイト, 6月23日)
とある。
日経バイトは、「通常SSLのクライアント認証用証明書にはメールアドレスなどが入っているが」と言っているが、それは正しくない。たしかに、電子メール用の証明書（暗号化メールや、署名付きメール用）ではcommon nameは必ずメールアドレスとなるが、SSL用のクライアント証明書では名前は自由に決められる。通常のログインサービスの「ユーザ名」と同じだ。ちなみに、IPAの電子申請システムで発行されるクライアント証明書のcommon nameは、「CertID0000XXXX」という形式だった。ドコモがcommon nameとしてメールアドレスを使わなかったのは、「プライバシーに配慮」という意味で正しい選択であるが、元々「通常…メールアドレス」という習慣があるわけではなく、プライバシーが向上したわけではない。
そして、「固定のID番号」であればプライバシーに問題がないかというと、既にこれまでにいろいろな事例で見てきたとおりだ。「ID番号からお客様を特定することはできません」などと簡単に言えるようなものではない。
ただ、EZwebの「subscriber ID」とは性質が異なる。EZwebでは、非公式サイトを含むあらゆるWebサーバに対して、アクセスしただけで無条件に、つまり、ユーザの確認すらなしに、「X-Up-Subno」というヘッダフィールドで契約者に固定のIDを送信してしまうが、ドコモの「FirstPass」では、「ユーザ証明書を送信します はい/いいえ」という確認ステップがあるし、PIN番号（暗証番号）の入力も必要になっているので、悪意あるサイトに固定IDを送信してしまうことを、ユーザは避けることができる。しかも、ドコモのルート証明書を持っているサーバでないとSSL接続が確立しないので、この「FirstPass」に契約した者しかIDを読むことはできないと思われる。ZDNetの記事によると、
iモード公式サイトと異なり、FirstPassは公序良俗に反するかどうかだけのネガティブチェック。企業内のイントラネットアクセスのような非公式サイトでも利用できる。
ドコモ、FOMA向けクライアント認証サービス「FirstPass」 (ZDNet JAPAN Mobile, 6月20日)
とあり、なんらかの「ネガティブチェック」が行われるようだ。
では、この状況をプライバシーについてどう考えればよいか。これは、「Webのあらゆるログインサービスで、ユーザ名が唯一の機関によって定められている」という状況に近いと言える。つまり、たとえば、Microsoftの「Passport」サービスが独占的に普及した世界を想像すればよい。Windowsを購入すると、無料でPassportサービスにアカウントを作ってもらうことができ、どこのネットショップに行ってもPassportの同じアカウントでログインするという世界だ。さらに、勤務先のイントラネットに外出先からアクセスする際にも、MicrosoftのPassportのアカウントでログインするという世界だ。
実際に、Microsoftは当初、Passportをそのようなものにしようと企てていた様子が見える。これには多くの批判があった。独占的だという指摘だけでなく、プライバシー上の問題でもあると批判され、対抗するものとして「Liberty Alliance」が結成されている。 -Sun主導で「Liberty Alliance」結成，Microsoftに圧力 (ZDNet News, 2001年9月27日)
Liberty Allianceの方式は、さまざまなプライバシー確保の仕組みを導入し、やるべきことをすべてやろうとしているようだ。
同プロジェクトではSSOの実現に，中央集権型の単一のレポジトリではなく，フェデレーション（協調）モデルと呼ばれる手法を採用している。個々のユーザーID情報を管理して認証を行うIdentity Provider（識別プロバイダー：IDP）と，実際にサービスを提供するプロバイダーが，1つの「信頼の輪」の下で協調し，ユーザーの許可に基づいてSSOを実現していくというものだ。
「（フェデレーション型に比べて），マイクロソフトのPassportで採用されているようなグローバルで一意なIDは，管理が難しい。実際，マイクロソフトも，フェデレーションモデルへと移行していくことを発表済みだ」
クライアント認証に話を戻すと、Microsoftでさえ、万能クライアント証明書（どこでも使える証明書）を無料で発行（あるいは、Windowsに出荷時からプリインストール）などということはしてこなかった。もしそんなことをすれば、強い批判にさらされることは見えているし、そもそもPKIとはそのような使い方をするものではないことを技術者が認識しているのだろう。
Windowsには沢山のルート証明書が入っている。Windowsの上で、多数の認証サービスプロバイダーが事業を展開できるようになっている。OSと、通信インフラと、認証サービスとが独立して提供されるという、これこそがPKIの理念ではなかろうか。
ドコモの独占的PKIである「FirstPass」は、はたしてPKIとして妥当なものだろうか。
まず、安全管理の点で考えてみる。ルート証明書の秘密鍵の管理など、認証局の運営には安全管理にコストがかかるはずだが、「FirstPass」の料金はほぼ無料になっている。しかし、ドコモは、電気通信事業者として、元々、さまざまな場面で高い安全管理を求められているわけであり、それらと同時に認証局の管理をすることによって、コストを見えなくしていると考えることができる。つまり、OSと、通信インフラと、認証サービスを一社で提供することにより、コストを低減したものと見ることができる。
次に、プライバシーの点で考えてみる。ZDNetの記事には、
同様のクライアント認証システムとしては、ｉモード公式サイトで利用している方式がある。中村氏は、「（iモード公式サイトのやり方も）ドコモのネットワークが出しているIDなのでセキュリティは高い」と話すが、FirstPassには別のメリットがあると言う。
「iモード公式サイトと異なり、FirstPassは公序良俗に反するかどうかだけのネガティブチェック。企業内のイントラネットアクセスのような非公式サイトでも利用できる。また、ドコモのネットワークを離れてインターネットに出ていく場合、FirstPassのほうがセキュリティが高い。
ドコモ、FOMA向けクライアント認証サービス「FirstPass」 (ZDNet JAPAN Mobile, 6月20日)
とある。たしかに、ｉモードの公式サイトでは、なんらかのIDによってユーザを特定しているようだ。契約者固有番号がドコモのネットワーク内で流れていると思われる。これは、ドコモのネットワークで閉じているので、安全性が確保されているのだろう。非公式サイトに対しても、ドコモは、端末固有番号の送信機能を 503i から導入してる。
端末IDの取得方法は以下の通りだ。 <form action="http://" method="get" utn> という形で，末尾に“utn”の3文字を追加すると，リンク先に飛んだ際に，「携帯電話情報を送信しますか？」という表示が出る。そこで「送信する」を選ぶと，ヘッダーのUser-Agentのところに DoCoMo/1.0/F503i/C10/ser に続いて，端末のIDが表示される。
非公式サイトへ送信されるIDは、インターネットを流れるので、なりすましが可能な場合があり、安全性が低い。クライアント証明書を使えば、SSLで安全性が保証されるので、「FirstPassのほうがセキュリティが高い」ということなのだろう。
つまり、固定IDによるプライバシー低下の問題は、503i が導入された時点で既に生じていた。「携帯電話情報を送信しますか？」という確認ステップを設けているのは、ドコモが固定IDのプライバシー問題を理解していて、それに配慮したことの現れであろう。今回の「FirstPass」でも、同様に「ユーザ証明書を送信します はい/いいえ」という確認ステップを用意しているのだから、503i よりプライバシーレベルが低下することはない。「ネガティブチェック」をパスして、3000円でルート証明書を手に入れた者しか、IDを得られないという点で、その分プライバシーレベルは向上したと言える。
ところで、そもそも公式サイトに契約者番号が送られているというのは、どうなのだろうか。秘密保持契約で縛られていると聞く。ドコモは電気通信事業法の縛りで秘密が確保されているが、それが、契約によって公式サイト群まで拡大されている。これの守秘性はどうなのだろうか。公式サイト数が増えていけば、守秘性は低下していく。どんな契約になっているのか調べてみたいところだ。
その一方、非公式サイトには契約がないので、503i の端末番号のプライバシーは、「送信しますか？」にどう答えるかというユーザの責任となっている。今回の「FirstPass」ではどうだろうか。3000円を支払ってルート証明書を受け取るときに、どのような契約になっているのだろうか。受信したcommon nameを他者に漏らしてはいけないといった守秘義務が規定されているだろうか。
独占的PKIのプライバシー低下については、公的個人認証についても考えてみる必要がある。これについては、またいずれ書くつもりだ。
安全性の話に戻すと、PKIは、独占的なものでは、万が一秘密鍵が危殆化した場合などに、影響が各サービス全域に及んでしまうので、本来ならば複数の認証局が参入できるようにしておくのが普通だ。FOMAではそれを可能にする予定があるのだろうか。つまり、複数のクライアント証明書を端末に格納できるかどうかだ。可能だとしても、認証事業者の新規参入は困難だろう。なぜなら、ドコモが事実上無料で証明書を発行しているからだ。ただ、安全性をドコモ認証局に依存しないことを重視して、コストを払ってでも他の認証局を使うという需要はあるのかもしれない。
他の認証局の存在し得ない完全に独占的なPKIだとすると、これは、一般的な公開鍵認証の安全性を確保したものというよりも、契約者番号による識別システムを、公開鍵暗号の技術を応用して、独自に安全性を高めたものと見るのが妥当かもしれない。
2003年06月25日
■ 続・通信キャリアの独占型PKI
昨日の日記について、セキュリティホールmemoの6月25日付の欄外で次のコメントを頂いた。
OSと、通信インフラと、認証サービスとが独立して提供されるという、これこそがPKIの理念ではなかろうか。
そんなことないと思いますけど……。 全部 1 社が提供しても、「そういう実装の PKI」というだけのことなのでは。
これについては、まず、文章を次のように訂正する。
OSと、通信インフラと、認証サービスとを独立して提供できるようにしたというのが、PKIという仕組みの設計理念だったのではなかろうか。
この日記の書き始めた当初からのテーマは、「よりよい方法が存在するにもかかわらず、それが選択されないことによる、プライバシーの犠牲」という現実を理解し、少しでもましな方向へ進もうということだ。
「FirstPass」が成功しそうなのは、ほぼ無料だからというところによるものが大きいと思う。そしてそれが可能なのは、OSと、通信インフラと、認証サービスの提供主体が一体だからだろう。その反面で失われているものは、名前空間の独立性、代替認証局の利用可能性によるリスクの分散化である。名前空間の独立性が失われたことは、すなわち、統一IDによるプライバシーの低下を意味する。
もし、第三者認証事業者が対等に参入できる仕組みにしたら、携帯電話のクライアント認証は普及しないかもしれない。無料というわけにはいかないので、料金が高すぎるために普及しないという、これまでの一般のWebでの二の舞になるのかもしれない。
その点で、ドコモのやり方はビジネスとして上手だと言える。これまでも、インターネットの技術を中途半端に導入することで「いいとこ取り」をして、成功してきたと言えるだろう。インターネットは、多くの技術者や研究者の厳しい目で磨かれ洗練された技術をベースにしている。最大限の自由と公平性が得られる技術をインフラとし、その上で必要に応じたサービスを構築すればよいという理念に基づいているように思う。それに対し、携帯電話事業者の場合は、そうした理念なんかよりも、いかに現実的に成功するかを追求しているのだろう。しかし、通信インフラレベルで「いいとこ取り」（中途半端な導入）をすることは、一般的に、長期的に綻びが生じてくる懸念があるように思う。
この件で私が言いたいのは、「FirstPass」は大成功するかもしれないが、「クライアント認証ってこういうものなのね」という理解はして欲しくないということだ。
さて、次に、話を変えて、昨日の日記で書き漏らしたことを追記する。
「FirstPass」で証明書の再発行はできるのだろうか。まず、紛失した場合に再発行できるのかというと、できるのかもしれない。では、紛失していない場合でも再発行できるのか。できるとした場合、異なるID（common name）の証明書を取得することができるかどうかだ。その必要性が想定されていないならば、再発行してもIDは変化しないだろう。つまり、IDは契約者番号と一対一対応しているという可能性がある。
異なるIDで証明書を再発行してもらう必要性がどこにあるかというと、プライバシーが損なわれたと思ったときに、その証明書を破棄して、IDの異なる新しいものを取り直すという自衛手段が提供されるという点にある。IDが変わると、クライアント証明書を登録した各サービスで再登録が必要になるが、それで正常にサービスは受けられるわけであるし、手間をかけてでもプライバシーを重視したいという要求が満たされるようになる。
希望によってIDを変更するという仕組みは、住民基本台帳の住民票コードにさえ用意されているものだ。
住民基本台帳に記録されている者は、その者が記録されている住民基本台帳を備える市町村の市町村長に対し、その者に係る住民票に記載されている住民票コードの記載の変更を請求することができる。
これは、住民票コードによる追跡が起き得る状態になったとの不安を抱いた住民が、番号を変更することで追跡から逃れられるようにするという配慮からだ。ただし、変更履歴が記録されているので、追跡者が、変更履歴を閲覧できる者である場合には、これは有効な回避策ではない。有効となるのは、次のケースなどだ。
- 住基ネット不正利用 一部金融機関が「通知票」で本人確認 (毎日新聞, 2003年2月17日)
- 住民票コード、「除票」を消費者金融などに発行 那覇市がミス (毎日新聞, 2003年4月9日)
ここで気づいたが、EZwebの「subscriber ID」も、IDの変更ができるようにしたらどうだろうか。あるいは、既に変更できる仕組みが用意されているのだろうか。今度問い合わせてみよう。
2003年06月29日
■ 「これはいたずらな不安の煽りである」という合理化
経済産業研究所のit@RIETIに、6月25日付けで、「非接触ICタグ(RFID)とプライバシー：〜書き込み型RFIDの問題とネットワークの活用〜」というコラムが掲載されていた。著者の泉田裕彦氏は、同研究所のコンサルティングフェローで、経済産業省から国土交通省に出向中の、国土交通省貨物流通システム高度化推進調整官でもある。泉田氏は、3月に「自動認識技術（非接触タグ:RFID）の可能性と幻想」というコラムも発表なさっている。このときの主張は、書き込み可能タグよりも、固定ID単純応答型のタグとネットワークの合わせ技を使った方がよいとするものだった。つまり、Auto-IDセンターの考え方に追従する意見である。書き換え可能型を使わない方がよいとする理由として、タグ内のデータは破損に備えて外部にバックアップが必要で、データを同期化する必要が生ずるため二度手間になるという点と、タグのハードウェアコストが高くつく点を挙げている。関連する箇所をコラムから引用しておく。
書き込み可能なRFIDの技術は、本当に、これまで、コストをかけて行っていたデータ共有が劇的に改善したり、商流や物流を画期的に改善する技術なのであろうか？...
平成１３年度に国土交通省が航空手荷物にRFIDを貼付して物流の効率化を行う実証実験を実施しているが、この際にも、いくつかのチップが破損している。結局、書き込み型RFIDに格納した情報のうち紛失してはいけない情報は、別にサーバー等にバックアップする必要がある。換言すれば、RFIDへ書き込みを行う場合は、データ保管に２重コストが発生することとなるのである。...
この場合、個体（商品等）の特定ができれば良いので、コストをかけて書き込み型RFIDにする必要はない。その個体（商品等）に関する情報は、サーバーに存在しておれば良く、ネットワークを介してアクセスできれば十分ということになる。
そして今回の新しいコラムでは、RFIDタグのプライバシー問題について論じられている。ここでまず、泉田氏が、私の4月の日経ネット時評の論点を十分に把握なさっているであろうことを確認しておきたい。Geocitiesの無料レンタルページに「 ＜研究資料リンク集＞」と題するリンク集があるが、これは、「My SITE」という部分に「泉田 裕彦 （いずみだ ひろひこ）」と署名されているので、この泉田氏により作られたものだと推定される。ここには、「RFIDとプライバシー」というリンク集があり、以下のリンクがリストアップされている。
- RFIDがもたらすプライバシーへの影響 （[memo:5768]）
- RFID反応リンク集 高木光浩さん記事レスのホームページ （RFID反応リンク集）
- NIKKEIネット時評、電子タグ・トレーサビリティ・プライバシー （network styly *）
加えて、泉田氏の今回のコラムの文章には、私の日経ネット時評の文章に良く似た部分が散見される。
RFIDは電波を利用して自動認識することから、RFID付きの物を持ち歩くと、所有者の意思と無関係に どんな属性の物を所持しているかを他人に知られるてしまうという可能性が生じる。
泉田裕彦, 非接触ICタグ(RFID)とプライバシー：〜書き込み型RFIDの問題とネットワークの活用〜, it@RIETI, 2003年6月25日
RFIDは、所有者の意思と無関係に読み取られるので、IDの発行者以外によって活用され得る。...
このように、RFIDのプライバシー問題が語られるとき、どんな属性の物を所持しているかを他人に知られる問題がクローズアップされがちである。
例えば、全ての商品にRFIDが貼付された社会が実現すると、はいている下着の色、所持している本のタイトルが、街を歩くだけで他人に知られてしまうという危険が生じる。また、店舗等の定点にリーダーを設置すれば、RFIDの発行者以外によってマーケッティング等に活用されるかも知れない。これらの点は、所有者が提示しない限り情報が流出する危険が生じない接触型のICカードと大きく異なる。
泉田裕彦, 非接触ICタグ(RFID)とプライバシー：〜書き込み型RFIDの問題とネットワークの活用〜, it@RIETI, 2003年6月25日
はいているパンツの色、所持している本のタイトルが、街を歩くだけで知られてしまうといったように。...
会員証の場合では、所有者が提示しない限り番号を読み取られないので、IDは発行者によってのみ活用される。それに対し、RFIDは、所有者の意思と無関係に読み取られるので、IDの発行者以外によって活用され得る。
例えば、既に、電波で電話機固有の識別番号を発信して局と通信している携帯電話は広く普及している。... 携帯電話は通信手順が非公開であり、これを解読して番号を解読しても得られるメリットとつり合わないことがプライバシー侵害問題は生じさせていない。
泉田裕彦, 非接触ICタグ(RFID)とプライバシー：〜書き込み型RFIDの問題とネットワークの活用〜, it@RIETI, 2003年6月25日
携帯電話だって電話機固有の識別番号を電波で飛ばして局と通信している。だが、その通信手順は非公開であり、一般の人が傍受して番号を得られるわけではないだろう。
このことからも、泉田氏は私の文章を精読なさった上でこれを書かれたと推察できる*1。
泉田氏のコラムの主張は、今回も、書き込み可能型よりも固定ID単純応答型のタグの方が良いとするもので、その根拠として、書き込み可能型ではプライバシーの問題があるという点を、前回のコラムに付け加えるものとなっている。具体的には、
RFIDのプライバシー侵害問題の対策
まず、言えることは、生のデータを直接RFIDに記述することは、危険であるということである。...
そこで、考えられるのが、RFIDには、ユニークな番号だけを記載して、固有のアイテムに関するデータはセキュリティのかけられたネットワークシステムに保存するという方法である。アクセス権を管理することにより、セキュリティーの確保と利便性の追求を両立させる可能性が出てくる。
泉田裕彦, 非接触ICタグ(RFID)とプライバシー：〜書き込み型RFIDの問題とネットワークの活用〜, it@RIETI, 2003年6月25日
の部分がそれを述べている。なお、この主張は、私のネット時評における以下の部分と同じ内容を指す。
オートIDセンターの「クラス1」規格は、RFIDタグを極限まで単純化し、64〜96ビットの固定ID番号だけを持たせ、タグ内に属性情報を記録しない方式だという。そのため、オートIDセンターのQ & Aには、「プライバシー保護の取り組み」として次のように書かれている。
EPCには固有のコード番号が記載されているだけで、それ自体は重要な意味を持ちません。EPCに関連付けられる固有のアイテムに関する重要なデータはセキュリティのかけられたネットワークシステムに保存されており、これらのデータへのアクセス権は厳重に管理されています。
確かにこの方式ならば、電車内で他人に属性情報を読まれることはない。RFIDの研究者が「RFIDのUIDから商品の特定は困難」と発言することがあるのはこのためである。
さて、問題は、泉田氏が、固定IDがもたらすプライバシーへの影響をどのように述べているかである。これがコラム後半で次のように結論付けられている。
次に、ID番号が付いた物を所持するだけで、個人が特定されるという危惧だが、要は、利便性とリスクのバランスの中でどのように評価し対策を行うかという問題であると考えられる。例えば、既に、電波で電話機固有の識別番号を発信して局と通信している携帯電話は広く普及している。クレジットカードにいたっては、有効期限、番号と名前だけで引き落としが可能である。携帯電話は通信手順が非公開であり、これを解読して番号を解読しても得られるメリットとつり合わないことがプライバシー侵害問題は生じさせていない。また、クレジットカードは、危険ではあるが、問題が生じた際には、一定期間過去に遡って保険が適用されるという仕組みが構築されており、クレジットシステムには高い信頼が存在する。ユニークなID有するRFIDが貼付された物を持ち歩くとプライバシーが漏洩する可能性があると、いたずらに不安を煽るのは適切でないであろう。万が一の場合は、事後的に司法を通じて問題を解決する方法もあり、対策のコストと事後解決のコストの比較衡量が欠かせない。
泉田裕彦, 非接触ICタグ(RFID)とプライバシー：〜書き込み型RFIDの問題とネットワークの活用〜, it@RIETI, 2003年6月25日
この問題が「利便性とリスクのバランスの評価」に帰結されることは、改めて述べるまでもない自明のことであろう。泉田氏は、このコラムで具体的にどのような評価を与えているだろうか。
そこには、携帯電話が基地局と通信する電話機固有の識別番号の話と、クレジットカード番号の話が書かれている。それぞれを分離して文脈を追いかけてみると次のような論理構成になっている。
例えば、既に、電波で電話機固有の識別番号を発信して局と通信している携帯電話は広く普及している。...
携帯電話は通信手順が非公開であり、これを解読して番号を解読しても得られるメリットとつり合わないことがプライバシー侵害問題は生じさせていない。...
ユニークなID有するRFIDが貼付された物を持ち歩くとプライバシーが漏洩する可能性があると、いたずらに不安を煽るのは適切でないであろう。
泉田裕彦, 非接触ICタグ(RFID)とプライバシー：〜書き込み型RFIDの問題とネットワークの活用〜, it@RIETI, 2003年6月25日
クレジットカードにいたっては、有効期限、番号と名前だけで引き落としが可能である。...
クレジットカードは、危険ではあるが、問題が生じた際には、一定期間過去に遡って保険が適用されるという仕組みが構築されており、クレジットシステムには高い信頼が存在する。
ユニークなID有するRFIDが貼付された物を持ち歩くとプライバシーが漏洩する可能性があると、いたずらに不安を煽るのは適切でないであろう。
泉田裕彦, 非接触ICタグ(RFID)とプライバシー：〜書き込み型RFIDの問題とネットワークの活用〜, it@RIETI, 2003年6月25日
先にも指摘したように、携帯電話が非公開の手順で基地局と通信するとき電話機固有の識別番号が含まれているという話は、私の日経ネット時評でも取り上げた比較材料である。私のネット時評では、この題材について次のように書いた。
IDは既にいろいろなところに付いている。...
携帯電話だって電話機固有の識別番号を電波で飛ばして局と通信している。だが、その通信手順は非公開であり、一般の人が傍受して番号を得られるわけではないだろう。
これらに比べて、RFIDの脅威が新しいのは、
- IDの発行や収集に法的制限がない。
- 離れたところから、所有者の意思に反して読むことができる。
- 安価な市販の装置でだれでも読むことができる。
という点である。
泉田裕彦, 非接触ICタグ(RFID)とプライバシー：〜書き込み型RFIDの問題とネットワークの活用〜, it@RIETI, 2003年6月25日
そのとおりだが、具体的な議論が進んでいない。
具体的な議論が進んでいない段階で、一方の技術的可能性の指摘を、「いたずらに不安を煽るのは適切でないであろう」と一蹴してしまうのは、判断を誤る危険がある。可能性は可能性として冷静に認識した上で、議論を進めるべきである。
可能性の指摘があったとき、ある種の人たちの思考が「いたずらに不安を煽るべきでない」というところへ陥ってしまうのには、いくつかの原因が考えられる。技術に明るくない人からすると、可能性の指摘があっただけで、あたかも、技術的解決策が存在しない話であるかのように早とちりしてしまい、絶望感に襲われ、「これはいたずらな不安の煽りである」と理解することで合理化することがあるのではなかろうか。
私の日経ネット時評は、後半を読めばわかるように、「技術的な解決手段を検討しよう」というのが主題だ。固定IDにならないようにする技術的方法は、何種類も考えることができる。ネット時評でも2種類を提示しているが、他にもその後、素人ながら自力で考えたものとして次のアイデアがある。
- RFIDチップ内に、単純増加カウンタと公開鍵暗号の演算回路と公開鍵を内蔵させる。スキャナからアクセスがある毎に、カウンタの値を1増やしながら、カウンタの値と固定IDの連接ビット列を公開鍵で暗号化してスキャナへの応答とする。スキャナ側は、スキャンする毎に異なるビット列が返ってくるので、そのままでは個人追跡には使えない。チップ内の公開鍵に対応する秘密鍵を保有している者だけが、固定IDを取り出すことができる。
もちろん、これを実現するにはハードウェアコストがかかる。公開鍵暗号の演算器をハードウェアロジックで構成するのは効率的でないであろうから、小さなCPUを内蔵する必要があるだろう。このコストをさらに下げる方法として次の案も考えてみた。
- RFIDチップ内に、単純増加カウンタと対称鍵暗号の演算回路と共通鍵を内蔵させる。対称鍵暗号の演算回路は、暗号アルゴリズムによってはそれなりに低コストで実装可能であろう。後は先の案と同様に暗号化して応答する。このままでは、RFIDチップを分解して解析されると鍵は読み出されてしまう。かといってRFIDチップに耐タンパー性を求めるのはコストがかかりすぎる。そこで、RFIDを製造する際に、頻繁にこの鍵を変更するようにする。鍵にはシリアルナンバーを付けて、データベースに登録しておく。不正にIDを読み取ろうとする者は、頻繁にRFIDチップの分析をしなくては、一部のスキャンしか復号できない。正規のスキャンでは、スキャンデータの上位ビットの鍵番号から、データベースを検索して鍵を得て、それで復号して固定IDを得る。不完全な方法ではあるが、追跡のコストを増大させ、ある程度の抑止が期待できる。
この方法でもなお依然として、ある程度のハードウェアコスト増は生ずるので、泉田氏が前提としている、固定ID単純応答型（日立のミューチップなど）ほどの低コストは、今すぐには望めないだろう。しかし、RFIDタグの製造コストには、チップの製造コストだけでなく、アンテナの取り付けも含まれるため、チップだけいくら安くしても限界があるという話をしばしば耳にする。したがって、5年後、10年後の将来には、こうしたなんらかの対策回路を内蔵したチップであっても、十分に競争力のある価格に抑えられる可能性がある。先月、RSA Conference 2003 Japanの坂村健教授の講演を聴講した際、会場から次のように質問をした。
昨今、急激にRFIDの実用化が注目され始めたのは、10円、5円という低価格化が見えてきたためだと思いますが、ユビキタスIDセンターのタグは、どのくらいの価格を想定しているのでしょうか？
これに対して坂村教授は、「10年くらい先を見越して研究している」という趣旨の回答だった。
この日記で、一貫して、様々な事例を挙げながら書いてきたように、一般に、固定IDのもたらすプライバシーへの影響は、技術的な解決策（ないし脅威の軽減策）が存在する場合が多い。暗号研究者はもちろんのこと、一部の関心の高い技術者や技術系研究者はそのことを知っている。だが、消費者が対策を求めなければ、事業者はそれを採用することの意義を見出さないだろう。そして、消費者は、脅威の可能性の存在を知らされなければ、そうした軽減策の採用を望むことに気づきようがない。技術研究が忘れ去られるのである。そうならないために、技術系研究者が脅威の原理を正しく説明していくことは当然の使命である。それに対して、
ユニークなID有するRFIDが貼付された物を持ち歩くとプライバシーが漏洩する可能性があると、いたずらに不安を煽るのは適切でないであろう。
泉田裕彦, 非接触ICタグ(RFID)とプライバシー：〜書き込み型RFIDの問題とネットワークの活用〜, it@RIETI, 2003年6月25日
と一蹴するのは、そうした努力を破壊する。
原理的な脅威は常に現実的なわけではない。たとえば、まだ「ユビキタス社会」とは到底言えない現在の状況（ごく稀な場所にしかRFIDスキャナが設置されていない状況）では、固定IDのRFIDを街で持ち歩いていても、個人の移動を追跡されることはほぼないだろう。しかし、泉田氏も、
将来のユビキタス社会の発展という観点からは、夢のない解決方法である。
泉田裕彦, 非接触ICタグ(RFID)とプライバシー：〜書き込み型RFIDの問題とネットワークの活用〜, it@RIETI, 2003年6月25日
と述べているような、何十年後かの、本物のユビキタスコンピューティング社会が到来したときを想定すると、あらゆる場所にスキャナが設置され、現実的なコストで大量のIDが計算処理される状況となり、追跡の可能性は現在とは異なるものになる。そのときには、ビット列が変化する対策を施したタグが使用されるのかもしれないが、過去に流通させてしまった固定IDのタグをそのときどうするのか。
このように、時系列での環境変化や、その他、電波の届く距離による影響の違いなども含めて、個別のケースにおいて、プライバシーへの影響がどの程度現実的にあるのかを整理しておくことが、今必要なことである。それをする前に、「いたずらに不安を煽るのは適切でない」と発言するのは、その整理を放棄しますという宣言である。
なお、泉田氏の記述には、技術的に誤った部分もある。書き込み可能タグにおいて、書き込んだデータが「誰にでも簡単に読みとられるようでは、実用に耐えない」という文脈において、
このためには、第一に、データを暗号化するという手法が考えられる。しかしながら、厳格な暗号化を行えば、チップのコストが上昇し、普及はおぼつかなくなるという問題が存在する。ユビキタス社会の実現を考えるとプライバシー等の「情報保護は暗号化で」というのでは、限界があると言わざるを得ない。
泉田裕彦, 非接触ICタグ(RFID)とプライバシー：〜書き込み型RFIDの問題とネットワークの活用〜, it@RIETI, 2003年6月25日
と述べているが、暗号化済みのデータをタグに書き込めばよいのであるから、タグ自身が暗号化回路を持つ必要はない。「チップのコストが上昇する」というのは誤りである。
泉田氏のコラムが政策的にどのような意味を持つかはわからないが、技術面の考察が足りないまま結論を急いでいるように見える。技術系の研究所に相談するなどしてはどうだろうか。旧工業技術院の研究所は、経済産業省の機関でありながら、そうした相談を受けることはほとんどなかったように思う（少なくとも電総研については）。これは、通常、研究者達がそうした議論に無関心であるため、もとより期待されてこなかったのだろう。
■ 「ユビキタス社会の光と影」を読んだ
[memo:5793]で書かれているように、木下真吾さん（NTT情報流通プラットフォーム研究所情報セキュリティプロジェクトセキュリティ社会科学研究グループ研究主任）と、5月に何通かのメールのやりとりがあった。その際に、CYBER SECURITY MANAGEMENT誌に、木下さんがRFIDのプライバシー問題について記事を執筆なさったと聞いた。先々週、その掲載号が出ましたよと教えていただいたので、読ませていただいた。記事のタイトルは「ユビキタス社会の光と影 ―脅かされるプライバシー―」となっている。
6ページにわたる文章で、大まかな内容を紹介すると、まず、ユビキタス社会が到来した際の一般的な情報セキュリティの問題が深刻になるであろうという話が述べられ、次に、「無線ICタグの光と影」として、プライバシー問題が書かれている。プライバシー問題には、「(1) 所持品の盗聴」、「(2)ID追跡による行動追跡、本人特定」の2種類があると分類され、これらの問題についての技術的対策の研究開発の現状について整理されている。
紹介されているのは、まず、Auto-IDセンターの「MetaID」（これは比較的広く知られていると思う）と、それに改良を加えて(2)の問題も解決しようとする「Randomized Access Control」を提案した、以下の論文だ。
- Stephen A. Weis, Sanjay E. Sarma, Ronald L. Rivest and Daniel W. Engels, Security and Privacy Aspects of Low-Cost Radio Frequency Identification Systems, First International Conference on Security in Pervasive Computing, 2003.
この論文のことは5月にメールで木下さんから教わっていたのだが、読んで興味深かったのは、RFIDの電波到達距離が 3メートルだとしても、スキャナの電波の到達距離はそれよりずっと長く、100メートルに及ぶという話だ。確かにそうなるように思える。タグの有効距離を数センチに抑えたとしても、スキャナの電波は数メートルにおよぶのかもしれない。
スキャナの電波が傍受されることがプライバシーにどう関係があるかというと、アンチコリジョン機能を持つRFIDタグでは、複数のタグがスキャン範囲に存在する場合に、スキャナからIDを部分指定してタグを選択し、ひとつひとつ順次読み出しするという処理を行うものがあり（日経バイト2003年5月号「ICタグ,飛躍への課題」のアンチコリジョンの説明図参照）、この場合、遠く離れたところで行われているスキャンで読まれているIDを、スキャナからの電波を傍受するだけで特定できてしまう場合があるという話だ。これの対策として、タグを限定していくアルゴリズムを改良した、「Silent Tree Walking」という手法が提案されている。
話を戻すと、木下さんの記事には、NTT研究所での取り組みとして、(1)の問題を解決するために暗号化した値をタグに書き込んでおくという、日経バイトの記事で紹介されていた手法とその他が整理されており、さらに、(2)の問題を解決する手法として、「ワンタイム秘匿化ID」が簡単に紹介されている。引用すると次のように説明されている。
我々は、(2)の問題に対して、毎回、あるいは定期的に、秘匿化IDを確率暗号の性質を利用して再暗号化し返答する方法を検討している。
本方法は、無線ICタグ上に秘密鍵を保存しなくても、再暗号化でき、更に、センター側の復号処理負担は、先に述べた匿名化IDの復号処理と同等であることから、スケーラビリティの問題も小さい。ただし、再暗号化用の回路も暗号化回路と同様のコストが掛かるため、低コスト化が今後の検討課題である。
木下真吾, ユビキタス社会の光と影, CYBER SECURITY MANAGEMENT, Vol.4, No.44, pp.34-39, 2003年6月
その他、「社会的方策」として、次のようにも書かれている。
無線ICタグがあらゆるモノに装着される将来の社会は、これまで人々が経験したことのない未知の社会となるため、誤った利用や過度の不安、そして感情的な拒絶など人々の混乱を招く可能性がある。それに対して技術的な方策だけではなく、技術レベルや利用方法に関する正しい情報開示、啓発活動、企業側の運用ポリシー／規制、あるいは法的保護手段を早い時期から検討しておく必要がある。
情報開示や啓発活動を怠ったために、無線ICタグの導入を断念せざるを得なくなり、優れた業務効率改善のチャンスを逃したベネトンの例は記憶に新しいところである。
木下真吾, ユビキタス社会の光と影, CYBER SECURITY MANAGEMENT, Vol.4, No.44, pp.34-39, 2003年6月
続く部分によると、Auto-IDセンターでは、2年ほど前から専門家と協議しながら市民の反応や意見を収集分析して、運用時のポリシー策定や規制への参考情報を提示しているそうだ。これについて以下の文献が紹介されている。が、ログインしないと入手できないようなので、残念ながらタイトルも不明だ。
- http://www.autoidcenter.org/research/CAM-AUTOID-EB-002.pdf
- http://www.autoidcenter.org/research/MIT-AUTOID-EB-006.pdf
7月5日追記: URLが間違っていたとのこと。
*1 「文章をパクりましたね」などと言うつもりは毛頭ない。単に、私のネット時評をよくお読みになっていることの証拠として挙げただけだ。ただ、参考文献に挙げないというのは、研究者の執筆スタイルとしていかがなものかとは思う。