【WWDC23】2024年春以降に Apple 審査を通過するために対応すべきプライバシーの変更点
WWDC23 では、プライバシーに関する新しいツールが追加されたり、今後新しく対応が必要な事項が発表されました。👮🏻
この記事では、WWDC23 の動画やドキュメント、Developer Forums の内容を調べ、実際に Xcode で試してみました。
対応が必要なアプリや SDK はそれなりにあると思うので、「ここ違うよ」「こうだと思う」などありましたら、ぜひコメントで教えていただきみなさんと知見を共有できたらとても嬉しいです。😊
何を対応すべき？
まずは要点からいきます。
ざっくりまとめると、以下がそれぞれ対応しなくてはいけないことだと理解しました！
o：必要
△：場合によって必要
x：不要
| 対応事項 | アプリ開発者 | SDK 開発者 |
|---|---|---|
| 収集するデータの定義 （Privacy Manifest内で定義） |
△ （Apple が定めるプライバシーデータを扱う場合） |
△ （Privacy-Impacting SDKs に該当する場合は必須。） |
| Required Reason API の定義と使用目的の説明 （Privacy Manifest内で定義） |
△ （Required Reason API に該当する場合） |
△ （Required Reason API に該当する場合） |
| トラッキングドメインの定義 （Privacy Manifest内で定義） |
△ （トラッキングを行う場合） |
△ （トラッキングを行う場合） |
| コード 署名 | x | △ （Privacy-Impacting SDKs に該当する場合は必須。） |
全員
- Required Reason API の使用目的を記載すること
- リストは後日公開予定
- トラッキングドメインを Privacy Manifest に定義すること
アプリ開発者
- サードパーティ SDK 開発者に Privacy Manifest を要求する
- Privacy Manifest を参照して、Nutrition Label は常に最新に保つこと
SDK 開発者
- コード 署名をすること
- Privacy Manifest を採用し、含めておくこと
※上記は Privacy-Impacting SDKs に関しては必須。そのリストは後日公開されるそうです。
いつまでに対応すべき？
2024年春までに対応が必須。 🌸
アプリレビューの基準の一つになる予定とのことです。つまりリジェクト対象となるという理解で良さそうです。
2023年秋からメールが届くようになるということ。
登場したワード
新しく登場したワードが多いので、それぞれ深堀っていきます。
Privacy Manifest
アプリやサードパーティ SDK （XCFrameworks, Swift Package, Framework Bundle）が収集したプライバシーのプロパティリスト、つまり plist のこと です。これを使って Privacy Report を生成することができます。
全てのアプリや SDK で必要というわけではなく、Apple が定める "プライバシー" のデータを扱う場合に必須という認識です。（詳細は「App privacy details on the App Store」）
Privacy Report は、App Store Connect にあるプライバシー情報欄を埋めるときに役立ちます。
ちなみにアプリでサードパーティ SDK を使っている場合は、SDK 側が Privacy Manifest を保持するので、アプリ側で新たに作る必要はないです。逆に言うと、サードパーティ SDK の開発者は必要ということですね。
具体的に定義することは以下の４つです。詳細は後述します。
- App Tracking Transparencyフレームワークの下で定義されたトラッキングのためにデータを使用するかどうか
- アプリやサードパーティSDKが接続する、トラッキングを行うインターネットドメインをリストアップした文字列の配列（つまりホスト名）
- 収集するデータの種類
- アプリやサードパーティSDKがアクセスするAPIタイプのうち、アクセスに理由が必要なAPIとして指定されているものと使用する目的
Required Reason API
Apple が提供する API のカテゴリとして、「理由が必須な API」が追加されたそうです。
名前の通り、使用する場合に 使用目的を記載する必要があります。記載する場所は、Privacy Manifest です。
対象の API は後日公表されるそうですが、Xcode 15.0 beta で見たところ、API の種類はリストで選択形式となっておりその選択肢はすでに確認できる状態でした。そこから想像できそうです。
詳しくは後述します。
トラッキングドメイン
ユーザーが意図しないトラッキングを防ぐために、 サードパーティ SDK やアプリなどでトラッキングに使用されているドメインからのネットワークアクセスを制御される ようになります。
これは Privacy Manifest にドメインを記載する ことで、ユーザーが許可しない限り、そのドメインからのアクセスを拒否するようになります。
セッションでは、トラッキングする機能もあればしない機能もあると思うので、それぞれドメインを分けて、トラッキングするドメインだけを Privacy Manifest に記載するといい と話していました。
どのドメインにアクセスしているかは、Instruments で確認可能ということです。
コード 署名
この記事で取り上げている４つのワードのうち、コード 署名だけは以前から知られているワードで今現在も Xcode が実施しています。
セッションの冒頭では、この コード 署名の概要と仕組みについて詳しく説明されました。
コード署名は、最終的に準拠したバイナリと、フレームワークの Info.plist やプライバシーマニフェストなどの関連メタデータ、あるいは特定の種類の配布ではソースコードそのものを、開発者のアイデンティティと暗号的にリンクする仕組みです。
これをすることによって 誰にも修正、改竄されていないことを保証する 目的があるそうです。
仕組みは以下のように解説されていました。
コードサイニングの仕組みは、まずコンパイルしたバイナリのCode Directoryハッシュ（CDHashとも呼ばれる）を生成します。
このハッシュを署名するために、開発者のIDを使用します。このアイデンティティは、開発者証明書によって表されます。この証明書は、コード署名に使用される秘密鍵と、署名の一部として配布される公開鍵で構成されています。この署名は、あなたのアイデンティティに結びつけることができます。このアイデンティティは、ハッシュへの署名に使用され、署名が特定の時点で生成されたことを検証するために使用される安全なタイムスタンプと組み合わせることができます。これにより、誰かがあなたのSDKを改ざんした場合、署名が無効になることが保証されます。
WWDC23 では、 Xcode 側がこの署名の検証を簡単にかつ自動で行う ことができる機能が発表されました。
具体的にはXcode のインスペクタ（右側のサイドバー）で、その署名の詳細な情報や検証のステータスを確認することができます。また検証に失敗した場合も、Xcode 上で対応することができることも開発者にとっての魅力の一つだと思います。
署名の方法や具体的な Xcode の挙動は後述します。
実際の画面
WWDC23 のセッションや公開されているドキュメントを参照して、実際の対応の仕方を調べてみました。
Privacy Manifest
Xcode の Navigator から App Privacy を選択し、追加するだけです。
plist形式で追加していくことができるので簡単です。ちなみに、ファイル名は変えないように とドキュメントに記載されていました。
キーは以下の通り。
| キー | 役割 |
|---|---|
| NSPrivacyTracking | App Tracking Transparencyフレームワークの下で定義されたトラッキングのためにデータを使用するかどうかを示すブール値。 詳しくは、「ユーザーのプライバシーとデータの使用」を参照。 |
| NSPrivacyTrackingDomains | アプリやサードパーティSDKが接続する、トラッキングを行うインターネットドメインをリストアップした文字列の配列。 ユーザーがApp Tracking Transparencyフレームワークを通じてトラッキング許可を与えていない場合、これらのドメインへのネットワークリクエストは失敗し、あなたのアプリはエラーを受け取る。 |
| NSPrivacyCollectedDataTypes | 収集するデータ型を記述した辞書の配列。 以下のリストのキーと値を使用する。 |
| NSPrivacyAccessedAPITypes | アプリやサードパーティSDKがアクセスするAPIタイプのうち、アクセスに理由が必要なAPIとして指定されているものを記述した辞書の配列。 |
収集するデータごとに定義する必要があります。
| キー | 役割 | 例 |
|---|---|---|
| NSPrivacyCollectedDataType | 収集するデータの種類の文字列。 | Name |
| NSPrivacyCollectedDataTypeLinked | そのデータをユーザーの特定にしようするかどうかを表すブール値。 |
YES or NO
|
| NSPrivacyCollectedDataTypeTracking | そのデータをトラッキングするかどうかを表すブール値。 |
YES or NO
|
| NSPrivacyCollectedDataTypePurposes | そのデータを収集する理由を列挙した文字列の配列。 | App Functionality |
NSPrivacyCollectedDataType は Name 以外にもたくさん選択肢があります。
NSPrivacyCollectedDataTypePurposesもいくつかを選択できます。
どれもこちらのドキュメントに詳しく載っているので、そちらを参照ください。
ちなみにこの２つは自分で独自のものを設定すると、正しく Privacy Report が生成されないそうなので、選択肢から選ぶ必要があります。
Privacy Report の出力は Xcode Organizer から実施します。
すると、PDF の Privacy Report がダウンロードできます。
XCFramework に Privacy Manifest を含めて Swift Package Mananger として配布し、アプリで使用するケースは、
ドキュメントにも書いている通り、アプリ側で SDK 用の Privacy Manifest を作成する必要はなく、SDK 側が保持している Privacy Manifest の定義が Report に反映されます。
Required Reason API
該当の API に関しては、理由を書くことが必須になります。リストは後日公開とのことでした。
追記：公開されたため、記述を更新しました！
リスト化すると以下の通り。
- File Timestamp
- ファイルのタイムスタンプ
- Sytem Boot Time
- システムの起動時間
- Disk Space
- 使用可能なディスク容量（セッション内で例として取り上げられていた）
- Language and Locale
- 言語とロケール
- Active Keyboards
- アクティブなキーボードのリスト
- Time Zone
- タイムゾーン
- User Defaults
- UserDefaults！？
以下のように、API の種類と使用目的を記載します。使用目的は、選択式です。
（Xcode beta 2 で確認した時は自由記述だったのでそう思っていましたが、以下のセッション内のスクショは選択式ですし、ドキュメントにもリストから選択してくださいと書いてありました。また Xcode 15.0 beta 5 では自由記述から選択式に変わったいたので間違いなさそうです。「毎回理由を考えるの大変じゃん」と思っていたので助かった・・・）
Xcode 15.0 beta 5 では理由は選択式になっていました。
ドキュメントでは、使用する API ごとに選択する理由が定義されていました。
たとえば、ファイルのタイムスタンプにアクセスする API を使用する場合、以下の３つが定義されています。また 理由によっては、DDA9.1 のように取得したデータの扱いなど注意点が書かれているのでそれに沿った使用方法にすることが推奨されると考えられます。
DDA9.1
デバイスを使用する人にファイルのタイムスタンプを表示するために、この理由を定義する。
この理由でアクセスされた情報、または派生する情報は、 デバイス外に送信してはならない。
C617.1
アプリ・コンテナ、アプリ・グループ・コンテナ、またはアプリのCloudKitコンテナ内のファイルのタイムスタンプにアクセスするには、、この理由を定義する。
3B52.1
document picker view controller を使用するなどして、ユーザが特にアクセスを許可したファイルやディレクトリのタイムスタンプにアクセスするために、この理由を定義する。
ちなみに多くの方に関わるであろう、UserDefaults に関しては、以下のように書かれています。理由は一つだけなのでこれを選択するだけでいいと思いますが、データの扱いの注意が書かれていました。
CA92.1
UserDefaults にアクセスし、アプリ自身しかアクセスできない情報を読み書きするために、この理由を定義する。
この理由は、 他のアプリやシステムによって書き込まれた情報の読み取りや、他のアプリがアクセスできる情報の書き込みを許可しません。
Xcode 15.0 beta 1 の選択肢にすでに登場していたので警戒してましたが、やっぱり UserDefaults がいますね。。😇 ということでかなりのアプリでPrivacy Manifestの準備が必要になりそうです。。（ちなみに beta の選択にはあった、Sysctl はドキュメントからは無くなっていました。）
トラッキングドメイン
トラッキングをするドメインは、以下のように、Privacy Tracking Domainsに記載します。
コード 署名
XCFramework を作成しそれに署名するところから、実際にやってみました。
まずこちらを参考に XCFramework を準備しました。
そして作成できた、XCFramework を以下の codesign コマンドで署名します。今回は Apple Developer Program の証明書を使いました。
$ codesign --timestamp -v --sign "証明書名（e.g. Apple Distribution: kamimi (TeamID)）" TestXCFramework.xcframework
すると以下のログが出力され、署名されたことがわかります。
TestXCFramework.xcframework: signed bundle [TestXCFramework]
これを Xcode に追加します。
また Xcode 15 では、ビルド時に SDK ユーザーが想定する正当な SDK を使っているかチェックしてくれる機能がつきます。
Xcode では最初に XCFramework の署名で使用された ID がプロジェクトに保存されます。
例えば XCFramework を新しいバージョンのものに置き換えた場合として、最初と異なる ID で署名された XCFramework を使ってビルドしようとした時、ビルドが失敗し、Xcode が以下のような警告を出すそうです。
これは Xcode が、SDK のユーザーが想定する正当な XCFramework を使っているかどうかをチェック してくれています。
エラーが発生した XCFramework のバージョンが、正当なものであると確信できる場合、Xcode の画面を使って Accept Change をすることでこの警告を解決することができます。
こうやって安全な SDK を使っていることを Xcode で確認することができます。
Q&A
セッションに紐づく Developer Forums を見ていたところ、勉強になる質問がけっこうありました。そこからいくつか気になるものをピックアップしました。
Required Reason API や Privacy-Impacting SDKs のドキュメントはどこにある？
どの API を使う時に Privacy Manifest へ理由の記載が必要なのか、どの SDK は Privacy Manifest や コード 署名を必須で対応しなければいけないのか、気になりますよね。
これは まだ公開されていません と Forums で Apple の方が回答されていました。
今年の後半に公開する予定とのことです。
Privacy Manifest があるのに、App Store Connect の Privacy の情報入力はまだ手入力なのか？
Privacy Manifest の登場によって、App Store Connect でプライバシー欄の入力が楽になるということだったのですが、それならばもう App Store Connect での入力を補助してくれればいいのではないかと思いました。
しかしセッション内では、「Privacy Report を参照して、App Store Connect のプライバシー情報の入力が簡単になるよ」とは言っていましたが、将来その欄がなくなったり、自動で入力するようになるような話はありませんでした。
それについて、Forums で聞いてみました。まだ回答待ちなので、わかったら更新します。 もしくはご存じ or 検討がつく方はこの記事のコメントか Forums のコメントで教えていただけるととてもありがたいです!🙏🏻
Swift Pakage Mananger で提供するサードパーティ SDK は コード 署名に関してどんな対応をすればいいのか？
WWDC の動画では、XCFramework にのみ言及されており、Swift Package Manager で提供されている SDK に関しては特に言及がありませんでした。🥲
Forums の回答を見ると、今回発表された コード 署名はバイナリに対してのみ焦点を当てている そうです。
ソースコードの保護に関しては Git の署名付きコミット（こちら）があったり、特定のコミットに対して SwiftPM を向けることができるといった環境があるよ、とのことでした。つまりソースコードの形式で提供する SDK に関しては Apple から何か保護の手段を提供することはないということなんですかね？
ということは Swift Package Manager で提供するサードパーティに関しては何もしなくもいいのか。。？というわけではない模様です。😭理由は次へ。
Xcode 15 でサードパーティの コード 署名を無効にすることはできるか？
なぜ無効にしたいのかというと、とある Swift Package Manager を使用している時に、the signature cannot be verified" and "code sign verification failed.というエラーが発生して、コンパイルができなかったからだそうです。
Swift Package Manager だから対応が不要というわけではない模様・・・内部で XCFramework を使用しているケースもあると思うので、それはそうかもしれないのですが。。
前述したように、セッションでは Swift Package Manager に関しての対応方法は示されておらず、ドキュメントも今のところなさそうです。
Apple からの公式回答がまだなので引き続きウォッチしておこうと思います。
コメントしていた方は、ビルド時のチェックを無効にできるように Feedback Assistant でフィードバックを送ったそうです。今後改善されるといいですね。。
それぞれのメリット・デメリット
最後にそれぞれのメリット・デメリットを整理してみました。
| 関係者 | メリット | デメリット |
|---|---|---|
| アプリ開発者 | ・Privacy Report によって、App Store Connect でプライバシーの情報入力が簡単になる （・エンドユーザーからのアプリへの信頼度が増すかも） |
・Privacy Manifest を作成する手間がかかる |
| SDK 開発者 | 特になし？ | ・Privacy Manifest を作成する手間がかかる ・コード 署名を行う手間がかかる |
| エンドユーザー | ・プライバシーに関する基準が厳しくなることで、より安心してアプリを使うことができるようになる | 特になし？ |
参考資料
調べるためにチェックした公式ドキュメントや動画です。
Privacy 全般の変更点
Privacy Manifest について
コード 署名について
App Store におけるプライバシー全般
さいごに
プライバシー周りはセキュリティが深く絡んでいて、セッションを理解するのも実際に試すのも私にとっては一苦労でした。😓
これを機に、XCFramework について一から学ぶために「Binary Frameworks in Swift」のセッションをみたり、実際に作ってみたりして、より理解を深めることができました。
また Forums で実際に質問して他の開発者の方々と交流することもできて個人的にとても嬉しかったです。
最初にも書きましたように、対応が必要な開発者は多いと思うので、「ここ違うよ」「こうだと思う」などありましたら、ぜひコメントで教えていただけますととても嬉しいです。😊
この記事がお役に立てれば幸いです。
Discussion