iOSでのUDID規制からの端末IDへの再認識とAndroidでの現状と今後（特にリワード広告業界）

AppleでUDIDを取り扱っているアプリがAppStoreからリジェクトされるといった規制の声が囁かれ、リワード業界を始めとした広告業界に大きな波紋を呼びました。あのニュース発表以降、UDIDから別のユニークIDにするといった動きが多くみられています。あるところでは、以前もこのブログに書いたようにUDIDの代わりにUUID＋KeyChainを利用したり、海外最大手のリワード広告会社では、いいか悪いかは別にしてニュース発表後UDIDからMacアドレスをハッシュ化して使う（*1）と発表したりしていました（現在ではMACアドレスとOpenUDIDを選択できるようです *2）。

国内外で本格化してきています。では、端末IDと呼ばれるIDがなんなのか、何故使ってはいけないかを簡単に説明したいと思います。単純に端末IDといっても様々で、よく対象となるのが次のIDになります。

・UDID（Unique Device Identifier）
主にiOSで端末を識別するユニークなID。工場出荷時に各端末に割り当てられ、割り振られたUDIDは端末を特定できる一意な識別番号。Appleの意向によりアプリで使用することは基本的にNG。

・IMEI（International Mobile Equipment Identity）
携帯電話端末に付与される識別番号。携帯電話のバッテリを外すと書いてあることが多い。また電話番号入力画面で「*#06#」 と入力すれば表示することも可能。

・IMSI（International Mobile Subscriber Identity）
携帯電話内のSIMカードに格納されており契約者単位に割り当てられている一意な識別番号。

・MACアドレス（Media Access Control address）
LANカードなどのネットワーク機器のハードウェアに一意に割り当てられる物理アドレス。スマートフォンの場合、Wi-Fiが標準で搭載されているのでハードウェア一意な識別番号となる。

また、JailBreak（*3）を行なうとこれらのIDは変更（厳密にいうと偽装）することができますが、その辺は割愛します。リワード広告ではSDK内部でJailBreak対策を行い、成果の対象としないのが一般的です。

「UUID＋KeyChain（UIID）でも同様の端末IDになりうるのではないか」とか質問をいただいたのですが、リワード広告で使用しているUIIDの場合、アプリ毎に生成されるユニークIDで、かつ成果を発生させたか否かの認証の目的のみに使用しています。なので、一ユーザがアプリaとアプリbをインストールした場合、それぞれのUIIDが生成されるため、対象となるユーザがどのアプリをインストールしたかは特定できません。簡単な例が以下です。

端末IDを取得することによってアプリ単位ではなく、（広告掲載面のメディアを横断した）どのユーザが、どのアプリをインストールしたといった情報が特定できてしまうことに問題があると考えています。

iOSではApple側の規制があり、多くのリワード会社やデベロッパーはこういった端末IDを扱うところは（少なくとも国内は）なってきています。これはアプリを提供するプラットフォーム＝Appleの意向であり、ルール違反をするところはどんどん淘汰されていくでしょう。

では、Androidではどうなのか？この辺の議論が特にリワード業界では曖昧になっているような気がしていて、多くのリワード広告会社がIMEIを使用しているのが現状だと思ってます（私の所属する会社ではUDID・IMEIは一切使用しないリワードSDKを提供しています）。

技術的な観点からみると単純にiOSのKeyChainのようにアプリをアンインストールしても引き継がれる保管場所がなかったり、端末依存の問題もあるのかと思っています。そういったことからIMEIをハッシュ化して認証目的のみに使用しているのがほとんどではないでしょうか。この辺は捉え方によるのですが、端末IDをハッシュ化・暗号化して使っているといっても所詮は端末IDをベースとした文字列になるので基本は一緒だと思います。

しかしながら、こういった状況はiOSと同様に規制される方向に変化していくものと考えています。

理由として端末IDに対する国や企業の考え方が変わりつつあるというのと、Androidの場合iOSとは異なり、端末IDを取得しているアプリの特定は容易に行えます。アプリのインストール時にGooglePlay（旧Android Market）に「端末ステータスと端末IDの読み込み」といったように取得する旨が表示されます（右図参照）。

これはアプリ実装時に「android.permission.READ_PHONE_STATE」といった設定を行わなければならず、必ずインストール時にユーザの目に触れるようになっています。しかしながらこの注意メッセージもユーザはなんのために使用するかなどが記載されておらず、ほとんど意味をなしていないのではと思ってます。

こういった端末IDを扱う場合アプリを提供する側としては、何のためにこの情報を取得しており、どのように使っているのか、また、どのような管理を行っているかなどをしっかり明記しておく必要があると思います。また、そういった情報をユーザの目に留められるような仕組みであったりも必要になっていくと思います。例えばデベロッパーとしてアプリを登録する際、こういったパーミッション情報をどんな目的で使っているかの登録フォームがあって登録していくとダウンロードするユーザの目に留められるなど技術者レベルでも実装時に取得することがどういったことなのかをよく考え、取得しなくてもいい方法がないかやなどをもっとオープンに議論していくべきだと考えています。

また、リワード広告の場合、前にも書きましたがこの端末IDでユニーク判定しているのがほとんでで、JailBreakによるユニークIDの偽装によってそもそもの認証の概念が崩れてしまうことが大いに予想されます。そういったことの予防策としても端末IDに依存するのではなく、別アプローチからの考えというのもリワード広告をやっている技術者として常に模索いきたいと思ってます。

*1 Tapjoy SDK Update | Tapjoy
http://blog.tapjoy.com/for-developers/tapjoy-sdk-update/
Tapjoy is confident that this update and the use of MAC address is part of a workable solution, and we will remain vigilant in responding to the business needs of our developers and user community.

*2 Tapjoy Pushes OpenUDID SDK Live | Tapjoy
http://blog.tapjoy.com/company-updates/tapjoy-pushes-openudid-sdk-live/
As part of Tapjoy’s ongoing commitment to respect consumer privacy, we will continue to protect user information and provide consumers with transparent disclosures and choice. To that end, OpenUDID allows consumers the choice to opt-out of the process.

*3 Jailbreak（脱獄）とは
ユーザー権限に制限を設けているAppleの端末に対して、セキュリティホールを突くなどして、その制限を取り除き、意図しない方法でソフトウェアを動作できるようにすること。Appleの認可を受けていないソフトウェア（App Storeで流通していないアプリ）を動作可能にすることができます。日本語で脱獄とも呼ばれています。