<前の日記(2012年04月21日) 次の日記(2012年05月04日)> 最新 編集

高木浩光@自宅の日記

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

2012年04月29日

オプトアウト不履行の責任はどう問えるか(と書こうと思ったら終了していた)

AppleがiOSアプリでのUDIDの使用を禁止にする方針を示すなか、KDDI子会社の広告会社mediba(JIAA加盟社)が、行動ターゲティング広告用のトラッキング目的で(UDIDの代わりに)MACアドレスを使用する旨を公表していたことに皆が気付いたのは3月16日から17日にかけてのことであった。当時、medibaのサイトには以下のようにはっきりとその旨が書かれていた。日付は2月20日となっていた。

画面キャプチャ
図1: mediba社の「広告とプライバシーについて」が、
MACアドレスのトラッキング目的利用を宣言していた様子(2012年3月16日時点)

「UDIDが禁止になるからMACアドレスを使う」というのはじつに筋が悪い。なぜUDIDが禁止されるのかその趣旨を知りながらMACアドレスを使うというのであれば、脱法的であると言わざるを得ない。(それどころか、MACアドレスを使うのはUDIDを使うより悪い*1。)

あれだけ業界の皆で駄目だ駄目だと言っている最中に、こうも堂々とこういうことをされると、呆れるというより、このまま貫き通すだけのよほどの自信があるのだろうと推察され、長い戦いになりそうだと戦慄が走ったのだったが、それはともかく、medibaのこのときの対応はもっとトンデモなことになっていた。

medibaのオプトアウト手段提供のページは以下のようになっていた。

画面キャプチャ 画面キャプチャ 画面キャプチャ
図2: medibaのオプトアウト手段提供ページ(2012年3月16日時点)

なんと、iPhoneのMACアドレスを調べてて入力せよというのである。

百歩譲ってそれはいいとしよう。しかし、これの実装方法がトンデモなものだった。このページの「送信」ボタンを押したときに実行されるJavaScriptコードは以下のようになっていた。

画面キャプチャ
図3: 「送信」ボタンで実行されるJavaScriptコード

なんと、入力された文字列をそのままSHA-1ハッシュ*2して送信していたのである。そして、MACアドレスの入力に際して、16進数の入力が必要となるが、A〜Fの文字を、大文字で入力すればいいのか、小文字で入力するのか、何ら注記されていなかった。加えて、区切りを「-」とするのか「:」とするのか、はたまた区切りを入れてはいけないのかについても注記がなかった。

つまり、入力方法は以下のように様々なバラエティが考えられるところ、これのどれか一つが正解であって、それ以外で入力した人は、オプトアウト手続きが無視されることを意味する。

表1: MACアドレスの表記方法の例とそのSHA-1値
MACアドレスの表記例SHA-1値
12:34:56:ab:cd:efc3fe7707f399b2999a0c936cfbb34981259e922d
12:34:56:AB:CD:EF049c2d42edac9008eda9a724a6c79c501fb8f531
12:34:56:Ab:cD:eF2fafb35b53ec2b90a7a64bef2d0d0b188a8f35ef
12-34-56-ab-cd-ef80bc761b01240463d6a1e81a4a62d3402331f14c
12-34-56-aB-Cd-Efea88d06300288f3ae31096e8c0fcbbb06bc6c15c
12-34-56-AB-CD-EFb8376c7a5ee83416d68f693e1cda6b65982b3707
123456abcdefd4fbef92af33c1789d9130384a56737d181cc6df
123456AbcDeF79b1f0b2641ddcaf364883d75bf746c577865d1c
123456ABCDEFcc1c4d837fc67e9ceed47034e906de78180dedd1

いったいどうするつもりなのだろうか。全部の表記に対応しようにも、後の祭りである。これまでにオプトアウトの入力をした人の分をどうするのか。サーバにあるのは表1のどれか一つ(さらなる他の値の場合もある)の値であるわけで、元の値(MACアドレス)に戻す事はできない(すべてについて)わけだ。*3

真っ当な対処は、全ての利用者(この広告モジュールを埋め込んだ全てのアプリの全ての利用者)に、この過ちを周知し、既にオプトアウトした人はもう一度オプトアウトするように呼びかけるしかない。しかし、堂々とUDIDをMACアドレスで代替するような会社がそういうことをやってくれるとは考えにくい。

このまま放置したり、しれっと直して周知しなかった場合に、はたして、正しい対処を強制することはできるだろうか。米国ならば、FTC(連邦取引委員会)に通報すれば処置してもらえそうだが、日本ではどうなのか。

幸い、medibaはJIAA加盟社であり、mediba自身、この取組みがJIAAの「行動ターゲティング広告ガイドライン」に従ったものであることを宣言しているから、JIAAに通報すればよいかもしれない。JIAAの存在意義が試されることになるだろう。

と、そんなことをこのブログエントリに書こうと思い立ち、改めてmedibaのサイトを見に行ったところ、なんと、奇遇にも4月26日付で、medibaの方針が変更され、MACアドレスの利用が中止になっていた。

なんと、Android向けの広告モジュールで端末ID「Android ID」を利用していた件についても、5月で中止にするそうだ。これはめでたい。(加えて、ローカルストレージの使用も中止するようで、これもよいことだ。)

何がきっかけとなってこのような方針変更に至ったのかは定かでないが、この間に、AppleがUDID使用アプリの締め出しを開始し、GoogleのAdMobもUDID(のMD5値)の使用を中止していた。

Googleがこの方針をとったということは、そのうちAndroidにおいても同様の措置がとられるのではないか。

medibaは、今回の発表で、「ターゲティング広告を行わないSDKを配布」としていることから、アプリでのターゲティング自体をやめてしまうのだろうか。たしかに、AndroidやiOSにおいて、アプリ間にまたがった行動ターゲティング(アプリの利用状況をトラッキングした)を実現するには、端末IDを使用するしかなかった(又は、他の方法を用いても対策は不完全となる)。

従来の、Webのアドネットワークで行動ターゲティングが(オプトアウト手段の提供を前提に)許容されてきたのは、第三者cookieを用いていたからであり、第三者cookieは、広告サーバでしか取得できない値であることから(広告サーバ上で個人を特定することをしないのを約束として)「匿名のID」(他と共通に使えるIDではない)とされてきた。

スマホのアプリでは、この第三者cookie相当の機能がないため、同様のことが実現できなかったわけだが、今後、WebのIFRAMEのごとく、アプリの画面上に別のアプリの画面を部分的に重ねる機能をOSが提供してくれるとか、あるいは、アプリの画面の上にWebブラウザの画面の一部を重ねて表示させる機能が実現されれば、Webのアドネットワークと同等のことが可能になるのではないか。そうだとすれば、行動ターゲティング広告への道が絶たれたわけではないだろう。

なお、改訂された4月26日のmedibaの文書でも、誤った不適切な記述がある。

画面キャプチャ
図5: 現時点でも書かれている誤った記述

Android IDを使用している現時点では、medibaの言う「端末識別情報」に、(cookieの他に)スマホの「端末ID」が含まれているわけだが、これを「これらの情報は、いずれも個人を特定する情報は含まれず、第三者が個人を特定することはできません」とするのは誤りである。cookieについては正しいが、「端末ID」を指して「第三者が個人を特定することはできません」というのは嘘である。

未だに何が問題とされているのかわからないままなのだろうかと残念なところだが、5月になれば、Android IDの使用中止に伴って、この記述も消え去るのだろう。

そのほかにも、「「オプトアウト」(ターゲティング広告の無効化)について」を見ても、このオプトアウトが、単に広告表示の停止のことを言っているように読めて、トラッキングの停止(行動履歴情報の収集の停止)をしてくれるようには読めないところにも問題がある*4

さらに付け加えておくと、今回、iOS版について端末IDを用いた行動履歴収集を中止したわけだが、これまでに収集したデータを廃棄したのかが明らかにされていない。中止したのなら廃棄したらよいだろうし、少なくとも、オプトアウトしたのにそれが(上記の原因で)正しく機能せず、誤って収集してしまっていた人達の分の行動履歴ついては、廃棄すべきだろう。廃棄しないのであれば、オプトアウトが機能していなかった事実を告知しなければならない。

*1 スマホが登場する前、一般的なPCの世界では、MACアドレスのこうした利用は御法度であった。AppleがわざわざUDIDを作った(といっても、UDIDはMACアドレスとシリアル番号とIMEI(後にECIDに変更)のSHA-1ハッシュ値にすぎない)のは、MACアドレスをそのまま使うのは憚られるためであっただろうと思われる。MACアドレスは、LAN(Wi-Fiを含む)のアクセス制限に使われることがあるので、そのための値を勝手に取得することはセキュリティ上許されないとする考え方があるのだろう。

*2 しかも、使用されていた「sha1.js」のコード(現時点でもWebに置かれたままのようだ)は、「http://www.webtoolkit.info/javascript-sha1.html」からパクって著作者出典表示を削除したという酷いものであった。

画面キャプチャ
パクられたコードの冒頭部分

*3 medibaの広告モジュールの側で、MACアドレスを様々な表記方法に変換した上でそれぞれのハッシュ値を送信するようにし、どれか一つでも一致すればオプトアウトされていると判断するようにする策が考えられるが、送信すべき値の組み合わせは、少なくとも1万2千通りほど(2^12*3)あるので、現実的でない。

*4 JIAAの「行動ターゲティング広告ガイドライン」では、第5条で、「広告提供事業者は、利用者に対し、広告提供事業者が行動履歴情報を収集することの可否、広告提供事業者が行動履歴情報を利用することの可否を容易に選択できる手段を、自社サイトの分かり易いページから簡単にアクセスできる領域で提供する。」としており、可否を選択できるべきは、「収集」と「利用」であり、広告の非表示のことではない。

検索

<前の日記(2012年04月21日) 次の日記(2012年05月04日)> 最新 編集

最近のタイトル

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|
<前の日記(2012年04月21日) 次の日記(2012年05月04日)> 最新 編集