Airpush ... エンベロップをプッシュする

少し前に、Airpushを利用しているAndroidアプリをいくつか偶然見つけました。Airpushは、デベロッパーが収入を得るために自分が開発したアプリに追加することができるという広告SDKです。開発したアプリを通して広告が1000回表示される度に、デベロッパーは謝礼として数ドルを手に入れることができます。Airpushの場合、広告はモバイルフォンのシステム トレイにプッシュ通知されます。つまり、広告はアプリ自体には表示されませんが、システム レベルでは通常は表示されます。これによって、広告が読まれたりクリックされたりする可能性が増えますが、多くのエンドユーザはこのシステムはあまりにも押し付けがましいとクレームを付けています。

左の画像をご覧ください。これはAirPushのデモアプリです。AirPush広告は、Androidシステム トレイの一番上に表示されます。画像をクリックして拡大してみてください。

こうした状況を受けて、Airpushは広告に対してオプトイン方式での許諾を必須にすることを決定しました。こうすれば、エンドユーザは、広告が自分のデバイスにプッシュ通知される前に広告を受け取るかどうかの同意を明示的に求められることになります。少なくとも、私はこの方式を気に入っています。

しかし、AirpushのFAQを見て私は非常に怒りを感じました。

職場の同僚なら、私の怒りの発端がどこかを容易に想像したと思います。「MD5を使用してIMEIが暗号化されている」という点です。彼らは、私がMD5を嫌いなことを知っています。

  1. MD5はハッシュ関数です。少々神経質かもしれませんが、MD5は何も"暗号化"しません。ただダイジェスト、またはハッシュするだけです。
  2. ひとつの当該IMEIに関しては、ハッシュ値は常に同じです。それゆえ、だれでも私のIMEIの代わりに私のIMEIハッシュ値を追跡できるのです。これは全く個人情報を保護していません。
  3. MD5は既に破られており、時代遅れになっています。どうしてこれがIMEIのセキュリティを守ることができるのでしょうか。Airpushが"個人情報"を本当に大切にしているとすれば、MD5は決して利用しなかったでしょう。

皆さんがオンラインのMD5リバージング エンジンを幸運にも知っていれば、ハッシュ値に変換されたIMEIを再現することは、いとも簡単です。私はAndroid Emulatorの偽のIMEI (000000000000000)を数秒で再現しました。

本物のIMEIなら、時間がかかるかもしれませんが、IMEIは厳格なフォーマット(15桁または16桁の最初の数桁は有効値の可能性がほとんどわずかなTAC(Type Allocation Code))に従っているため、再現できます。

加えて、Airpushの問題はAirpushが使用しているもう1つの個人情報「マイロケーション」について触れていないことです。確かに、いくつかのAirpushアプリはACCESS_COARSE_LOCATIONおよびACCESS_FINE_LOCATIONのパーミッションを要求します。AirpushのSDKインストールガイドによると、こうしたパーミッションは「オプションですが、収入源を増やすには強く推奨されます」としています。Airpushが保存している個人情報の一部としてFAQで記述すべきではないでしょうか。実際、AirpushはdataPrefs.xmlという名前のファイルに、私のデバイス(電話機のモデル、通信業者、製造業者、IMEI)およびロケーション(経度、緯度)の膨大な情報を記憶します。

Airpushが配信する様々な種類の広告に対しても不安を感じており、ユーザに警戒することを強くお勧めします。Airpushは、いくつかの"配信レシーバ"を実装しています。エンドユーザが広告をクリックしたら配信レシーバが動く仕組みになっているようです。AirpushはWeb配信レシーバ、マーケット配信レシーバ、フォン配信レシーバおよびSMS配信レシーバを実装しています。各配信レシーバは一連のパラメータに付属しており、広告をクリックしたら場合によって使用されます。
 たとえば、Web配信レシーバで、広告はURLにアタッチされます。広告をクリックしたら、URLが自動的に開きます。"フィッシング"に関して、これで安全でしょうか。フォン配信レシーバで、広告をクリックした時Airpushは自動的に指定の電話番号にかかるのではないでしょうか。また、SMS配信レシーバで、自動的にSMSを送信するのではないでしょうか。こうした広告を受け取っていないので確定はできませんが、確かに危険性があります。


Airpush SMS配信レシーバのDalvik逆アセンブル

最後に、Airpush広告にはオプトイン方式が最適だと思いますが、未だ徹底されていないようです。彼らはどうやってオプトイン方式の徹底を強化するつもりだろうかと思っています。実際のところ、興味深いパラメータを含んでいるdialogPref.xmlという名前のファイルを見つけました。

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
 <boolean name="ShowAd" value="true" />
 <boolean name="ShowDialog" value="true" />
</map>

ShowDialogパラメータはオプトイン ダイアログを参照し、ユーザに対して広告を受け取る許可を求めています。このようにShowDialogを使うことは、アプリにとってオプトイン ダイアログを無効にしたり(ShowDialogをfalseに)、ユーザの同意なしに広告(ShowAs =True)をプッシュ通知するのはあまりにも簡単なように思われます。