[iOS]アプリケーションでFirebaseの内、CrashlyticsとAnalyticsを使用している場合でのiOS14のトラッキング対応

Firebase AnalyticsとFirebase CrashlyticsとiOS14のユーザーアクティビティのトラッキングについて
2021.02.03

iOS14からユーザートラッキングに用いられている端末の広告識別子IDFA取得のオプトイン/オプトアウトの選択をユーザーに求めることが必須になります。アプリが取得するプライバシーポリシーの提出必須化と同じく大きな変更ですが、開発中のアプリが該当するか調べる時にFirebase AnalyticsとFirebase Crashlyticsのみを使っていて広告系のSDKも利用していない場合何の対応も必要ないかが心配になったので調べていました。

App Tracking Transparency | Apple Developer Documentation

iOS14で必要になるユーザートラッキングについての対応

AppleからUser Privacy and Data Use というドキュメントが公開されました。ユーザーがアプリのプライバシーポリシーをダウンロード前に確認して、アプリが収集するデータの種類や個人などとの紐付けの有無をチェックできるようにするために、開発者は事前にプライバシーの方針について回答が必須になります。

また、iOS14では、AppTrackingTransparencyフレームワークを通じてユーザーの許可を得ない場合にトラッキングやユーザーのIDFAへのアクセスが行えないようになります。ここでいうトラッキングはドキュメントによると

  • 自分のAppで収集したユーザーやデバイスに関するデータを、ターゲット広告や広告効果測定を目的として、他社のApp、Webサイト、またはオフラインのプロパティから収集されたユーザーやデバイスに関するデータに紐付ける行為
  • ユーザーやデバイスに関するデータをデータブローカーに共有すること

とのことです。

そして以下のユースケースはトラッキングに該当しないと明示されています。

  • 自分のAppで収集したユーザーやデバイスに関するデータとサードパーティのデータとの紐付けがユーザーのデバイス上でのみ行われ、ユーザーやデバイスを特定できるような方法でデバイスの外部に送信されることがない場合。
  • データを渡す相手となるブローカーが、不正行為の検出や防止、またはセキュリティ上の目的でのみ、また当該デベロッパのためだけにデータを使用する場合。

開発者はアプリ内のすべてのコードに対して責任を負う必要があるので、自分が記述したコード以外にも、導入を決めたSDKが内部的にAppleの言うトラッキングに該当する行為を行っている場合についても開発者がその責任を負います。

IDFA

IDFAはIdentifier for Advertisersの略で、iOS端末の広告識別子のことを指します。このIDFAを使ってユーザーをトラッキングすることができて、トラッキングした情報を元により効果的な広告を配信できます。

Firebase CrashlyticsとAnalyticsのみを導入しているアプリケーションの場合

開発中のアプリでFirebase Crashlyticsを導入しています。また、Firebase Crashlyticsの導入の際にGoogle Analyticsの導入がおすすめされているので、Google Analytics用のFirebase pod もアプリに追加して有効にしています。

Firebase Analyticsも一般的な意味におけるトラッキングは行っているので何らかの対応が必要になるか念の為調べておく必要があると思ってドキュメントやissueを読んでいました。

調べた限りでは、Firebase Analyticsを使っていて、広告系のSDKを他に導入しておらずAdSupport.frameworkとリンクしていないアプリの場合はIDFAにアクセスすることがないのでAppTrackingTransparencyを使用してユーザーに明示的な許可を求める必要はないようでした。

AddSupportフレームワークはアプリに広告識別子へのアクセス方法を提供するフレームワークです。これで得られるIDFAは、各デバイスに固有の英数字の文字列で、広告にのみ使用されることが想定されています。

AddSupportフレームワークのドキュメントにも、iOS 14.5 以降と iPadOS 14.5 以降を実行しているデバイスで、advertisingIdentifier プロパティを取得する前 にAppTrackingTransparency でユーザーに許可を要求する必要があると記載があります。

そして、Firebaseでは一部のアナリティクスの機能を使用するためにこのAdSupport frameworkを有効にする必要があり、AdSupportフレームワークを手動でプロジェクトに追加した場合、デバイスの広告識別子を自動的にレポートします。

IDFAの使用ガイドラインは以下です。

ここまで読むとFirebase Analyticsの導入でAdSupportフレームワークをリンクしていない場合はAppTrackingTransparencyによる権限確認は不要そうです。

しかし、iOS 11 では、システムフレームワークの SafariServices が AdSupport フレームワークを動的にロードするため、AdSupport フレームワークをプロジェクトに明示的に追加しなくても Firebase がデバイスの広告識別子をレポートしているようでした。この問題に関するissueは以下になります。

このissueにより、明示的な広告IDアクセス制御が必要になり、Firebase側で追加する必要があると案内されていました。具体的にはInfo.plistのGOOGLE_ANALYTICS_DEFAULT_ALLOW_AD_PERSONALIZATION_SIGNALSの値をNOにすることです。このフラグについてはFirebaseの以下のドキュメントに記載があります。

開発者の方は、最新版のAnalyticsでは近い将来AppTrackingTransparencyの同意が強制になって、かつユーザーから許可が得られない場合、Analyticsは空白の広告IDを認識するようになり、AdSupportがリンクされていても、広告に関する機能なしで正常に動作し続けるようになるとして、この対応が不要になるとコメントされていました。

また、この問題に関連して、子供向けのアプリがIDFAを無効にして審査に提出した所リジェクトされたというissueが立てられていました。

これに対する開発者の方から以下のように指摘がありました。

FirebaseAnalytics only collects IDFA if the AdSupport framework is linked (source) The class and methods used to conditionally access IDFA had names that overlapped with AdSupport's class and method names, which caused App Store reviewers to misclassify applications. The next version of FirebaseAnalytics uses different class and method names, which should solve this issue.

issueでのやりとりの結果としてIDFAにアクセスするためのクラスとメソッドの命名がAdSupportのクラスとメソッドの命名と重複していたことでAppStoreのレビュー担当者が誤って分類したことが原因と判断されて、FirebaseAnalytics 6.6.2で命名の変更が行われました。

このことから、少なくとも上記issueと同じ理由でのリジェクトを回避するために、Firebase Analyticsのバージョンを6.6.2以上にする必要がありそうです。

アプリ実行時にアプリにAdSupportフレームワークがリンクされていないかについてはアプリターゲットのLink Binary with LibrariesのBuild Phasesから確認するか、実行時にNSClassFromStringで確認できます。

print(NSClassFromString("ASIdentifierManager") != nil)

アプリ内でのデータ使用に関する情報開示が必要になるFirebase iOS SDKの挙動について

Appleの新しいプライバシーポリシーとFirebase AnalyticsでのIDFAについての議論はここまでに紹介したissueと主に以下のissueで行われていました。

これらのissueのやり取りの中で、Appleからの要請により開示が必要になる可能性のあるFirebase iOS SDKの動作について記述した包括的なドキュメントが公開されました。

また、このドキュメントと挙動が一致することを担保するためにFirebase iOS SDKの最新バージョンを常に使用することが推奨されています。

まとめ

Appleのガイドライン改定により、開発中のアプリで特別な対応になるかもしれないと思い調べた内容を残したものです。現状、開発中のアプリでは、SDKのバージョンアップデートと元々必須のプライバシー方針に関する回答は行うもののAppTrackingTransparencyを使用したユーザーへの許可確認は行わなくて良いと想定しています。

ドキュメントの読み間違いや認識に誤りなどで、ここまで書いた内容におかしなところがあるかもしれません。なにかお気づきの際にはブログのコメントかTwitterにてご連絡頂けるとありがたいです。

参照したドキュメント

ここまでで紹介していないものの、AppTrackingTransparencyについて調べる際に参考にした記事があるので最後に列挙します。