株式会社ミログのAndroidスパイアプリ問題について »

なぜミログはクロか

2011/10/16

Permalink 03:36:00, by Nobuo Sakiyama Email , 103 words   Japanese (JP)
Categories: プライバシー

なぜミログはクロか

前回の「株式会社ミログのAndroidスパイアプリ問題について」や、なかのきえたさんの「app.tv系コンテンツアプリによる実行されている及びインストール済みアプリ情報の送信について」に対しては、早速、当日10月10日のうちにミログからの反応があった。それは、「app.tvサービス停止に関して」という文書の発表と、app.tv系アプリ全ての Android Market からの消去である。また、アプリを開いてもサービス停止のお知らせが表示される状態に変更となっている。こうした事情により、前回エントリでのミログのapp.tvサービス許諾画面へのリンクや、app.tv系アプリの Android Market上での紹介へのリンクは機能しなくなっている。

ミログの発表は、「ユーザー様の許諾を得ない段階で情報を取得送信しているという重大な瑕疵」という表現で、技術的な面においては指摘事項を認めつつも、それが故意であったことは否定する形となっている。そして、それを前提とした形で、翌11日に「第三者委員会設置のご報告」という発表を行っている。しかし、私としては、ミログが故意を否定しているのは虚偽であると、単なる印象論を越えたレベルで確信している。それについて説明したいと思う。

その前にひとつ。app.tv が停止に至る前のできごととして、高木浩光さんの「スパイウェア「app.tv」に係るミログ社の大嘘」というエントリについて、あとでふれるということを述べてから本論に入りたい。

私が app.tv というスパイウェアの問題で注目しているのは、そのプログラムの構造である。それも、app.tv 単独ではなく、AppLogSDK との比較において、である。

前回述べたように、app.tv は利用許諾の入力の前に端末内のアプリ情報を収集・送信する。これがもし、「瑕疵」であるなら、せめて、利用許諾とアプリ情報収集・送信を結びつけるような、なんらかのロジックが存在し、それが間違っていた、といったことを期待したいものである。が、そうではない。app.tv のアプリ情報収集・送信は、プロトコル上、ミログの log.friend-app.com というサーバに、データを一方的に平文HTTPで post するだけのものである。一方、app.tv の利用許諾や、動画やコミックの視聴、つまりユーザから見ての本来の目的に関係するやりとりは、もっぱら api.androidappcredit.com というサーバに対して行われ、広告関係は ads.androidappcredit.com というサーバに対してのものとなる(これら2サーバとの通信は、SSLで保護されている)。つまり、利用許諾とアプリ情報収集・送信は、なんら結びつきがないのだ。

また、log.friend-app.com へ送られた情報と androidappcredit.com に送られた情報を結びつけようとしても、前者は ANDROID_ID が識別子だが、後者は登録したメールアドレスが識別子になり ANDROID_ID は送信される情報に含まれないため、結びつけようがない。

さらに許諾画面だが、前回の説明でも述べているように、画面の内容はアプリに同梱されているのではなく、Web上のものである。Android アプリでは、Webページを表示するのにWebViewというクラスを通常用いるようになっていて、それはapp.tv も同じである。WebView には addJavascriptInterface というメソッドがあり、これによってアプリ中の Java オブジェクトをJavaScript から操作可能とし、Webページの内容とアプリの間をつなぐことができる。しかし、app.tv でaddJavascriptInterface の引数となるオブジェクトは jp.co.milog.apptv.sdk.common.utils.CommandInterfaceというクラスのもので、このクラスのJavascriptから見えるメソッドは closeWindow, login, openWindow, playComic, playMovie, purchasePoint, shareFriends, showAds といったもので、役割もそれぞれの名前通りのもので、許諾状態をアプリに伝えるものはない(なお、shareFriends は、端末内の他のアプリを通して情報共有を行うための機能で、Android アプリにはよくあるものでミログのFriendAppとの関係はない)。

このようなアプリ全体の構造をみると、仮にミログが犯したのが瑕疵だったとすると、アプリ情報取得について「許諾を得損なった瑕疵」というのはおよそありえず、「許諾を得るつもりもなかった瑕疵」というほかはない。これは高木さんが指摘した、10月7日以前の利用許諾画面とも整合する。はたしてこれを「瑕疵」と呼んでいいのだろうか?

百歩譲って、app.tv の実装からAndroid Marketでのアプリ公開、7月27日の発表、ここまでに行われた、スパイウェア作成と提供は瑕疵であったと認めたとしよう。そうすると、今度は AppLog との関係で問題が出てくる。

AppLogSDK は、9月27日に発表され、同日にmedibaとの提携についての共同名義リリースも出ている。AppLogSDK では「オプトイン」「明示的な許諾確認」ということが強くうたわれている(それが実際のところどうか、というのはこの記事の対象としない)。app.tv では、アプリ情報取得についての同意ということを明確にうたっていなかったものが、AppLogでは前面に出てきた、というのは大きな変化である。

この変化は、単にビジネスモデルが違うということだけではない。AppLogSDK の場合、アプリ情報送信の前に、必ず、アプリ情報ログ許可状態を含むサーバ側の状態をアプリが取得して、許可状態の場合に限ってアプリ情報を送信するという形にプロトコルが変わっている。また、前述の addJavascriptInterface を使って、Webページとして作られた許諾ダイアログから AppLogSDK に、アプリ情報ログ許可の状態が送られ、そこで始めてアプリ情報の記録が始まるようになっている。つまり、AppLogSDK の実装にあたって、設計者は「利用者の許諾の得ること」の必要性をよく認識し、それは設計仕様書が存在すればそこに明示されるレベルのものである。プロトコルの違いは、当然、サーバ側の実装にも関係する話で、しかもAppLogSDK の情報送信先である api.applogsdk.com は、少なくともIPアドレスのレベルでは、log.friend-app.com と同一である(実際には、このIPアドレスは Amazon Web Service のElastic Load Balancer のものなので、複数のサーバからなるが、 app.tv と AppLogSDK, 名称からすれば FriendApp まで、アプリ情報処理のバックエンドは共通という、直感的には当たり前の状況と考えられる)。

これらの状況と、ミログが実働人数の少ないスタートアップであるという点を踏まえると、AppLogSDK の発表より前のある時点で、app.tv では利用者許諾のない状態での情報取得がある、ということは、ミログ内部で認識されていたと判断するのが合理的である。そうであるならば、そのような認識が生じてから 10月10日の サービス停止まで app.tv アプリが Android Market を通じて提供され続けたことは、不正指令電磁的記録供用の罪にあたると言わざるをえない。

もちろん、ミログの人間がそろってボンクラだったので分からなかった、という可能性を完全には否定できないのだが、しかし、状況からみれば、mediba との提携をすすめるにあたって利用者許諾の点が問題になり、だからこそプロトコル設計で新たに同意プロセスを明示的に組み込み、それをプレスリリースで強調したとしか思われない。これだけ、外部から見える状況証拠ではマックロな状況なのだから、証拠保全の観点から、強制捜査が行われることを強く望むものである。