23 | 8月 | 2011 | HMDT Blog

カテゴリー : 2011年 8月23日

UIDeviceのuniqueIdentifierがdeprecatedに


iOS 5 beta 6で、UIDeviceクラスのuniqueIdentifierプロパティが非推奨(deprecated)になった。将来なくなるってこと。んな、beta 6まで進んだこのタイミングで言われても、という気はする。

uniqueIdentifierプロパティは、デバイス個体のID(UUID)を取得するためのメソッド。これを使うと個体を識別できる。値自体は特に秘密ではなくて、iPhoneをMacにつないで、iTunesを使って確認できる。個体識別番号っていうと、ちょっとでもIT系のニュースを聞きかじっている人なら、即セキュリティやプライバシーの問題を思い浮かべるよね。実際、UUIDを許可無しに流出させるアプリがあるってニュースもあったし、穴はふさいどけ、ってことなんでしょう。

開発側からすると、別にプライバシーを暴くためでもなんでもなくて、UUIDを使いたいっていうケースは存在する。それは実行環境の識別を行いたいから。もっと細かく言うと、デバイスの個体識別と、ユーザ識別がある。

デバイスの個体識別は、ユーザがアプリを複数のデバイス(たとえばiPhoneとiPad)で使っているとき、いまどっちのデバイスで動いているの?というのを知りたいとき。これをやるには、デバイスのUUIDが不可欠なんだよね。これが取れないとなると、MACアドレスを使うか、そもそも個体識別が必要ないように仕様を変えるしかない。

ユーザ識別は、いま使っているユーザを他のユーザと区別したいとき。これをやるにはUUIDは完全ではないんだけど、手軽なソリューションだった。

ユーザ識別をしたいときってのはIn App Purchaseが絡むときが多いので、そのAPIを使うこともできる。でも、あれを使うとユーザにApple IDの入力を頼むことになるんで、警戒されるんだよね。

まぁ、どっちにしろUUID以外のきちんとしたソリューションは考えておかなくちゃいけなかった訳で。今回は先延ばしにしていたものに対して、尻を叩かれたかって感じだ。 the domain shops

iPhoneアプリでUDIDを使いたいケースその1


iOS 5からUDID取得APIがdeprecatedになるぞ、ってのを受けて、どんなときにUDIDを使いたくて、その代替策はどうなるかというケーススタディ。

まずは、機能を制限解除型で購入するアプリ。あるアプリをダウンロードして、一部の機能に制限がかかっている。In App Purchaseで購入することで、その制限を解除することができる。これをどうやってアプリで管理する?または、悪意あるユーザのクラックからどうやって守る?

いちばん簡単なのは、NSUserDefaultsにフラグを設定すること。

[[NSUserDefaults standardUserDefaults] setBool:YES forKey:@"purchased"];

って感じでね。簡単だけど、初期設定のplistを書き換えることで、簡単に破られてしまう。

じゃあってんで、何らかの固定文字列のハッシュ値を書き込むようにしたらどうだ?これなら、もとの固定文字列がばれない限り破られない。これは、一度だけ誰かが購入して、そのplistをコピーすれば破られてしまう。CFUUIDでUUID作っても、同じ。そのもとのUUIDをどこに保存するの?ってことになる。

そこで、UDID登場。UDID + 固定文字列のハッシュ値を使うようにする。これならこの値が流出しても、同じUDIDを持つデバイスでしか使えない。少しまともになった。

この手法の問題点は、機種変更すると使えなくなってしまうこと。フューチャーフォンとは違い、iPhoneでは機種変更したら前のアプリが使えなくなってしまう、というふざけたことは許されない。これは、In App Purchaseを使っているときは、リストアすることで対応できる。

別の手法を検討してみる。キーチェーンを使う方法。キーチェーンの中に、購入済みフラグを設定する。いまのところ、これは使える。

問題点は、キーチェーンの中に保存した情報は、アプリを削除しても残ること。制限解除キーが永遠に残るのは気持ち悪い。あと、キーチェーンって基本的には、ネットワークサービスのパスワードのように、ユーザが何度も入力するのが面倒な情報を保存しておくものだ。つまり、ユーザがすでに知っている情報が保存されているっていうのが前提。制限解除キーみたいに、ユーザから隠したい情報を入れておくのってどうなのよ、という気はする。もしかすると、将来AppleがiPhone版のキーチェーンアクセスみたいなものを出してきて、キーチェーンの中の情報を自由に見れるようにするかもしれない。そうなると、お手上げ。

また別の方法を。今回はIn App Purchaseで購入するというのが前提なので、購入したかどうかの判断をStore Kitを使って行うことができる。iTunesのサーバにアクセスして、購入履歴をリストアすることで判断する。

これの問題点は、ネットワークアクセスが必要になることと、毎回ユーザにApple IDの入力を求めることになること。これはめんどくさい。また、Store Kitへのアクセスをユーザの操作無しに行うと、アプリ申請時にリジェクトされる恐れがある。Store Kitのアクセスは、アプリを削除して新規インストールした、バックアップもなくしちゃいました、というときに留めておくのが無難。

ということで制限解除の許可には、ユーザを識別できて、かつ書き換え不可能なIDが必要なわけで、それにはUDIDは手軽な手段だったんだよね。そういったIDは、他にはApple IDがあるけど、これアプリからは全うな手段では取得できないし。ユーザからアクセス不可な領域ってことでキーチェーンを使うってことになるんだろうけど、なんか不安があるんだよな。