<前の日記(2003年06月06日) 次の日記(2003年06月10日)> 最新 編集

高木浩光@自宅の日記

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

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のファイルでも同様の画像を埋め込める事実を指摘したのだ。これは次のように報道されている。

日本で「Webバグ」という言葉が認知されたのは、このときが初だったのではないかと思う。しかし、「バグ」というと日本では、プログラムが期待外の挙動をする原因を指す意味の「バグ」だけが連想されてしまうため、このニュースの意味がわからないという人が多かった記憶がある。「「Bug」ってのは盗聴器のこと」という指摘があるように、辞書をひくと、英語の「bug」には次の意味があるとされている。

1a 虫, 昆虫 (insect), 《特に》甲虫 (beetle); ナンキンムシ, ゴキブリ, アタマジラミ《など》.
b 《口》 微生物, 病原菌, 黴菌(ばいきん).
c 《口》 病気, 《特に》伝染病.
2a 《機械などの》欠陥, 故障; 【電算】 誤り, バグ.
b #《俗》 不機嫌, 腹立ち.
3a 《俗》 防犯ベル; 《口》 盗聴器, 隠しマイク; #《俗》 電信機のキー《上下でなく左右に作動する半自動式のもの》.
b #《俗》 小型自動車, フォルクスワーゲン (Beetle); #《俗》 月面車; #《俗》 ホットロッド(のドライバー).
c 毛針, 虫針; #《俗》 《工場などで使う》大ひしゃく, 大るつぼ; #《俗》 《大道商人の商う》安物雑貨, 小物.
d #《印刷俗》 星印, アステリスク《*》 (⇒5a), 《出版物などに小さく刷り込む》ユニオンショップマーク, 商標[著作権]記号, シンボルマーク.
4a (以下略)
[株式会社研究社 リーダーズ英和辞典第2版]

上の記事からいくつか引用してみる。

このバグによって文書作成者は、少なくとも理論上は、文書が他の読者に回ったり、組織ネットワーク外に送信された場合に、それがわかるようになる。スミス氏は、このバグの悪用例は知られていないが、利用しそうな人々は存在すると述べた。

たとえば、極秘文書の漏洩を内密に検知・追跡するために、企業がコードを文書に埋め込むことが可能だ。また、著作権を持っている人がこの機能を利用して、ニュースレターや報告書の著作権が侵害されていないかどうか追跡することも可能だ。

WIRED News: 『マイクロソフト・ワード』などに文書追跡可能なバグ

Smith氏が発見したのは,これまで誰も気付かなかったのが不思議なくらい非常にシンプルな手法。以前から,Webサイトが利用者のサーフィン習慣を捕捉してcookieを置くために,小さな画像(1×1ピクセル画像)のリンクを使うことは知られていた。これはオンライン広告サービスでよく使われている方法だ。

Smith氏は,この手法が「Word 2000」「Excel 2000」「PowerPoint 2000」の文書でも行えることを発見した。文書内の小さな画像の外部リンクにより,文書が開かれるたび,その文書がインターネットに出ていく。1×1ピクセルという極めて小さな画像であるため,ユーザーはダウンロードしていることに気づかないが,そのピクセルとともにcookieが届いているかもしれない。

ZDNet News: Office文書に“Webバグ”

Privacy FoundationのWebバグの解説は、「FAQ: Web Bugs」、「FAQ: Document Web Bugs」、「Why are they bugging you?」にある。

その後、次のような報道があった。


「技術的に困難」というのは、これを技術的に回避するには、第三者サイトにある画像のインライン埋め込みを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がどのような情報をインターネットから吸い上げられているか見当がつかない。また,選択肢もほとんど与えられていない。

ZDNet News: “Webバグ”の悪用回避は「技術的に困難」

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メールがこんなに嫌われるのかよく分からない、というのが実情だ。

こうした状況を変えていくには、関係者がねばり強くネットユーザーを啓蒙していくしかない。

@IT: 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月06日) 次の日記(2003年06月10日)> 最新 編集

最近のタイトル

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|
<前の日記(2003年06月06日) 次の日記(2003年06月10日)> 最新 編集