タグ

iOSとsecurityに関するimai_0707のブックマーク (4)

  • Cocoaの日々: [iOS] Keychain Services とは

    他アプリケーションが格納した Keychain Services 内の情報へのアクセス Mac OS X の場合はユーザが許可を与えれば他のアプリケーションの情報へアクセスすることができる。一方、iOS の場合、アプリケーションは自身が保存した情報のみアクセスが行える。他のアプリケーションの情報へは基的にアクセスすることができない。ただし同じプロビジョニングプロファイルを使ってビルドされたアプリは設定により情報を共有することができる(後述)。 iOS での特記事項 iOS には単一のキーチェーンのみ存在する(Mac OS X は複数)。 iOS の場合、PC接続時にストレージの内容は暗号化されたままバックアップされる。これを復号化するパスワード(keychain password)はバックアップされない(iOSデバイスの中から外に持ち出されない)。 Keychain Service はプ

    Cocoaの日々: [iOS] Keychain Services とは
  • UDIDが使えなくなる?!UDIDに代わるUUIDについて » SHINGOLOG

    AppStoreのトップカテゴリーの68%はUDIDの収集をしているそうです。UDIDとはiPhoneiPad、iPod touchに割り振られている識別番号で、プライバシーの問題からUDIDの収集については危険視されてきました。例えば、個人のGPSアプリでいえば、誰がどこにいるのかも簡単に把握できてしまいます。 iOS5からUDIDが使えなくなるわけではないですが、非推奨となるようです。今後は撤廃されて行く方向にあると思いますので、修正しておいた方がいいでしょうね。 UDIDの代わりとなるUUID UUIDとは全世界でユニークになることを目的とした識別子、とのこと。 1000000000000000000000000000000000000通りの乱数です。 多すぎですね(;´Д`) 実際に組み込み方ですが - (NSString*) getUUID { CFUUIDRef uuid

  • スマフォのリワード広告におけるUDIDに依存しない設計案 - snippets from shinichitomita’s journal

    前回のまとめ 前エントリで触れたとおり、スマートフォンのUDIDの問題点というのは、自分の把握する限り3つあった。 1. サーバとのセッションを管理するための認証に使われてしまっている 2. アプリケーションをまたがっての行動トラッキングに使われてしまっている 3. スマフォにおけるリワード広告がUDIDが取れることに依存した実装になっている。 このうち、1. に関しては代替案があり、ほぼ既存のユーザビリティを損なわない形に実装できるものなので、単に実装側の怠慢か知識不足に帰結されると感じている。今の時点でこれほど安易に使われてしまっているのは残念なことではあるかもしれないが、今後改善できる余地がある。 2. に関しては、実はデバイス固有IDであることについてはそれほどこの時点では問題ではなく、単にトラッキングされることに対してユーザの同意も拒否も介在する余地が無い、というところを問題にし

    スマフォのリワード広告におけるUDIDに依存しない設計案 - snippets from shinichitomita’s journal
  • UDIDが使えなくなりそうなので、UIIDを使えるようにしました

    ■2012/11/11追記 iOS 6より[[UIDevice currentDevice] identifierForVendor]というAPIAppleより提供され、よりプライバシーに配慮した上により安全な方法で自分の開発したアプリケーションを利用するユーザーを個別に認証することが可能になりました。それに伴い拙作のライブラリもidentifierForVendorが利用可能であればこちらを利用するように修正いたしました。今後はこのidentifierForVendor(または広告APIなどを作る場合であれば[[UIDevice sharedManager] advertisingIdentifier])が個体認識の主流になっていくと思われます。identifierForVendorとadvertisingIdentifierの仕様まとめは http://stackoverflow.c

  • 1