- プライバシーマニフェスト対応
- PrivacyInfoファイルを作成し、完成させる
- PrivacyAccessedAPITypesについて記載する
- SDK開発者がPrivacyManifestを作成しているか確認する
- AppStoreConnectにも同様の確認項目があるので確認する
- リリース後
- 終わりに
- 2024/4/3時点での追加対応
※この記事は2023/10/24に初回を作成しています。2024/4/3、Appleへの審査回答で新たな進展があったのでページの下部に追記・更新しています。
プライバシーマニフェスト対応
iOSエンジニアの入江です。 WWDC2023年で発表されたプライバシーマニフェストですが、2024年の春以降は対応が必須になり、未対応のアプリはリジェクトされてしまいます。 今回、このプライバシーマニフェスト対応を行い、審査に出した結果、無事Appleの審査を通過したので、具体的に何を行ったのか書こうと思います。
まだ春まではだいぶあるので、Appleも本腰を入れて審査したわけではないかもしれませんが、前倒しで対応しておきたい、という方にとって少しでも役に立てば光栄です。
プライバシーマニフェストとは何か
〜とは何か、ということを知りたい場合は公式のドキュメントを熟読するのが一番です。プライバシーマニフェストについてのApple公式のドキュメントが用意されています。
プライバシーマニフェストについてのApple様の方針や概念の理解はほどほどに、具体的に何をすればいいかを書いていきます。
PrivacyInfoファイルを作成し、完成させる
Xcode15以降、PrivacyInfoファイルというファイルを生成できます。このファイルに指定の情報を埋めていく必要があり、今回の対応の中で最も大きな作業です。
ファイルの構成は以下のようになっています。
- NSPrivacyTracking
- NSPrivacyTrackingDomains
- NSPrivacyCollectedDataTypes
- NSPrivacyCollectedDataType
- NSPrivacyCollectedDataTypeLinked
- NSPrivacyCollectedDataTypeTracking
- NSPrivacyCollectedDataTypePurposes
- NSPrivacyAccessedAPITypes
- NSPrivacyAccessedAPIType
- NSPrivacyAccessedAPITypeReasons
NSPrivacyTrackingについて記載する
A Boolean that indicates whether your app or third-party SDK uses data for tracking as defined under the App Tracking Transparency framework.
と書いてある通り、App Tracking Transparency frameworkを使用しているかのBool値になります。使用していればYES、使用していなければNOを入れます。
NSPrivacyTrackingDomainsについて記載する
トラッキングに使用しているドメインを指定します。これを設定した場合、ATT許可がない場合は、対象のドメインへのアクセスが失敗しエラーが返ってくるようになります。 元々、ATT許可がないとトラッキング目的のドメインにはアクセスできないですが、アプリやSDKの作りによっては抜け道ができてしまう可能性を考慮しています。
NSPrivacyCollectedDataTypesについて記載する
トラッキングの有無に関わらず、アプリで収集しているすべてのデータに関しての種類や収集目的の記載が必要です（サードパーティSDKを除く）。そして、以下の4つについての項目を埋める必要があります。また、当然、機能追加や仕様変更によって新しいDataTypeが追加されたりCollection Purposesが変更になる可能性は十分あります。そのため、これらを継続的に管理できるような工夫が必要だと思っています。私たちは管理用のスプレッドシートを作成しました。
| DataType | Linked to User | Used for Tracking | Collection Purposes |
|---|---|---|---|
| データの種類 | ユーザーのアイデンティティに結びつくかどうか | トラッキングに使用しているか | 収集の目的 |
DataType
ドキュメントに記載の通り、記載が必要なデータタイプは決まっているので、これらすべてのデータタイプに目を通し、アプリで収集しているものがあれば追加します。
Linked to User
該当したDataTypeについて、ユーザーのアイデンティティと結びつくかどうかをBoolで入力します。
こちらの公式ドキュメントに、ユーザーのアイデンティティと結びつくデータの定義が説明されています。ちょっと抽象的でわかりにくいですね・・。
AppStoreConnectのプライバシー設定画面でもヒントがありました。
データ収集の前に、次のように特定のプライバシー保護が適用され匿名化されない限りは、アプリから収集されるデータは通常、ユーザの個人情報に関連付けられます： (中略) 注意：関連する個人情報保護法で定義される「個人情報」および「個人データ」は、ユーザに関連づけられているものとみなされます。
個人情報保護法で定義される「個人情報」および「個人データ」は、Linked to Userをtrueにしなければいけないということですね。
例えばDataTypeがメールアドレスの場合、個人情報保護委員会の見解では、メールアドレスのユーザー名及びドメイン名から特定の個人を識別することができる場合、個人情報に該当する、と書かれています。ユーザーのメールアドレスに名前を入れないようにこちらから制御することはできないので、Linked to UserにはYESを入れておくべきでしょう。
Used for Tracking
トラッキング目的に使用しているかどうか。トラッキングの定義については、ドキュメントに記載があります。どこまでをトラッキングとするかは判断が難しいケースもあるので、慎重な判断が必要でしょう。
Collection Purposes
収集の目的です。例えば認証機能に使用しているなら、App Functionalityが該当しますし、収集したデータ利用して社内で何らかの分析をしているならAnalyticsが該当します。複数該当するなら、複数のCollection Purposesを入力する必要があります。
目的の一覧と定義はドキュメントに記載があります。
PrivacyAccessedAPITypesについて記載する
まずはプライバシーマニフェストに記載が必要なAPIを自分たちが使用しているか確認（サードパーティSDKを除く）。
記載が必要なAPIは、こちらに掲載されているので、該当するAPIを使用していないかチェックします。私は地道にgrepしましたが、他に何かいいやり方があるのだろうか・・（せめて使用しているコードにWarning出るとかならわかりやすいのに、と思い、試しにFileAttributeKey.creationDateを実装し、ビルドしましたが何も出ませんでした。残念）
おそらく多くのアプリは、UserDefaultsが該当するのではないでしょうか。
NSPrivacyAccessedAPITypeを追加する
UserDefaultsが該当した前提で進めます。PrivacyInfoファイルから、Privacy Accessed API Typesキーを追加し、Privacy Accessed API Typeキーを追加し、そのValueとしてUser Defaultsを選択します。
Privacy Accessed API Reasonsを追加する
NSPrivacyAccessedAPITypeに応じて、選択できるPrivacy Accessed API Reasonsの選択肢は決まっています。Privacy Accessed API Reasonsの選択肢はドキュメントに記載されています。
User Defaultsの場合、選択肢はCA92.1: Access info from same app, per documentationしかないので、ためらうことなくこれを選びましょう。
SDK開発者がPrivacyManifestを作成しているか確認する
これまでの作業はすべて、SDKを除くアプリ本体を対象にしたものです。SDKのPrivacyInfoファイルはアプリの開発者ではなく、SDKの開発者が作成する必要があります。 今時点で、自分たちが使用している主要なSDKのパッケージにPrivacyManifestが追加されているものはぱっと見なさそうでした。対応必須になるのは春以降ですから、そのうち追加されるのでしょうか。
AppStoreConnectにも同様の確認項目があるので確認する
AppStoreConnectのアプリのプライバシーページに、PrivacyInfoファイルの内容と同様のチェック項目があります。内容重複感があるので、PrivacyInfoファイルが必須になったらこれらはなくなると期待したいですが、現状はこれらの項目とPrivacyInfoファイルの内容に矛盾がないように留意する必要があります。
リリース後
ご察しの通り、PrivacyInfoファイルの内容には、機能追加や仕様変更で簡単に変わりうる項目があります。そのため、現状の実態に対してPrivacyInfoファイルの内容が正しく書かれているかを継続的に管理していく必要があります。
記載が必要なDataTypeは33個もあります。
例えば、Search historyというDataTypeは、アプリ内での検索履歴データが該当するので、検索履歴データを収集するような機能追加があった時にPrivacyInfoファイルに追加することを認識しておかないといけません。
どう管理していくかは各開発元の判断に委ねられるところですが、33個もあるDataTypeを常に頭の中でウォッチしておくのはほぼ不可能なので、厳密にやるのであればリリースフローに組み込むなどの仕組みが必要かもしれません。
まあ元々は収集するDataTypeに関する項目はAppStoreConnectのプライバシー設定に存在していたので、そちらを普段からしっかり管理していれば、収集するDataTypeについていえば、全く新しいこと、というわけではありません。
終わりに
どこかのブログで、今回の対応について「The Dark Horse of WWDC 2023」って言われてて、確かにダークホースすぎると思いました・・。今後もメンテナンスを続けていく必要があるので、継続的な業務が1つ増えたことになります。 Appleとしては「それがブラウザとアプリの違いです」ということを打ち出したいのかもしれませんが・・。
2024/4/3時点での追加対応
2024/4/3時点での申請は、審査は通ったものの、Appleから、下記のようなメールが届きました。
Your app’s code in the “OpenWork” file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryFileTimestamp. While no action is required at this time, starting May 1, 2024, when you upload a new app or app update, you must include a NSPrivacyAccessedAPITypes array in your app’s privacy manifest to provide approved reasons for these APIs used by your app’s code.
アプリのコードは全て対応済なので、おそらくSDK分が引っかかっているのでしょう。 すでにGoogleSignIn、Kingfisher、Alamofire、facebook-ios-sdk など、メジャーなSDKは対応バージョンをリリースしているので、この辺のSDKはアップデートさせてしまいました。 全てのライブラリのリポジトリ上でgrepをかけていけばどのライブラリで引っかかっているかわかるのですが、とりあえず対応済みのSDKは脳死でアップデートをかけ、それでもまだ審査に引っかかるようなら具体的に残りのSDKのリポジトリ1つ1つにgrepをかけていき、どのSDKが要対応なのに未対応なのか、特定していこうかなと思います。
オープンワークでは一緒に開発をしていただけるエンジニアを募集中です。ご興味があればぜひ求人を見てみてください。 www.openwork.co.jp
