Firebase Analytics: New Apple Privacy Guidelines (Fall 2020)

[aschuch]

In fall 2020, Apple will enforce new privacy guidelines for 3rd-party analytics SDK, such as Firebase Analytics.
Details are outlined in this document: https://developer.apple.com/app-store/user-privacy-and-data-use/

1. Privacy Information on the App Store

Apple will require developers to provide information about the privacy practices when submitting apps in App Store Connect.
The provided information will be used to inform users about the privacy practices of an app on the App Store.

If you use third-party code — such as advertising or analytics SDKs — you’ll also need to describe what data the third-party code collects, how the data may be used, and whether the data is used to track users.

Question

Developers need to know the exact set of data that is collected by the Firebase SDK in order to provide this information to Apple.

• Could you please share an exact list of datapoints that is currently being collected by the Firebase SDK?
• What data is optionally collected by the SDK when the user has given access to specific permissions to the encapsulating app (location, camera, photos, contacts, calendar permission)?

2. Permission to track

Apple will require apps to explicitly ask for the users permission to track them or access their device’s advertising identifier. The new AppTrackingTransparency framework needs to be used to prompt the user for permission.

According to Apple, the AppTrackingTransparency framework needs to be used to ask for permission in the following cases:

Tracking refers to the act of linking user or device data collected from your app with user or device data collected from other companies’ apps, websites, or offline properties for targeted advertising or advertising measurement purposes. Tracking also refers to sharing user or device data with data brokers.
Examples of tracking include, but are not limited to:

• Displaying targeted advertisements in your app based on user data collected from apps and websites owned by other companies.
• Sharing device location data or email lists with a data broker.
• Sharing a list of emails, advertising IDs, or other IDs with a third-party advertising network that uses that information to retarget those users in other developers’ apps or to find similar users.
• Placing a third-party SDK in your app that combines user data from your app with user data from other developers’ apps to target advertising or measure advertising efficiency, even if you don’t use the SDK for these purposes. For example, using an analytics SDK that repurposes the data it collects from your app to enable targeted advertising in other developers’ apps.

Question

Given an app that only includes Firebase Analytics (no AdMob or other advertising SDKs) and does not link to the AdSupport.framework (so that the IDFA is not used):

• Does Firebase Analytics conduct any of the activities outlined by Apple which requires developers to use the new AppTrackingTransparency framework to ask for permission?
• Do you generally recommend developers to use the new AppTrackingTransparency framework to ask for user's permission when using Firebase Analytics?

Looking forward to your interpretation of the new rules and your recommendation towards developers.

[morganchen12]

To answer your questions:

• No, Analytics will not access the ad ID if no advertising SDKs are present and AdSupport is not linked. However, SafariServices on iOS 11 imports the AdSupport framework, causing device advertisement identifier reporting. #1686 makes it so that explicit ad ID access control is required, which is something we need to add on the Firebase side.
• Yes, if you're using Analytics with an ad framework you should follow Apple's guidelines. You may not be able to submit to the App Store otherwise.

[morganchen12]

Googlers-only bug number: b/160005774

[aschuch]

Thanks for your comment, @morganchen12!

I am still missing some answers to 1. (Privacy Information on the App Store):

• Could you please provide a list of datapoints that are tracked by Firebase Analytics here or document them in the Readme?
• Does Firebase Analytics track the user's location, contacts, photos, etc in case the encapsulating app has gathered permission from the user?

Answers to those questions, will be important for all developers integrating Firebase Analytics in order to answer the privacy questions during Apple's app review process as well as inform app users about the use of data by the 3rd-party Firebase SDK.

My question in 2. (Permission to track) explicitly asked about an app that only includes Firebase Analytics (no AdMob or other advertising SDKs).
We are aware that we need to follow Apple's guidelines when submitting to the App Store, however, these guidelines are very much dependent on what data Firebase Analytics collects and if this data is used to combine user data from one app with user data from other developers’ apps to target advertising or measure advertising efficiency.

From Apple's website:

Placing a third-party SDK in your app that combines user data from your app with user data from other developers’ apps to target advertising or measure advertising efficiency, even if you don’t use the SDK for these purposes. For example, using an analytics SDK that repurposes the data it collects from your app to enable targeted advertising in other developers’ apps.

Does Firebase use the collected data to perform such activity?

[morganchen12]

Analytics' collected data is described in this support document. Analytics will track the user's country but not their granular location and will not automatically track or log contacts, photos, or other data even if the user has given permission for the app to access that data. If you're using Analytics and want to track that data you must log it manually.

Analytics does use ad ID data to determine advertising efficiency, so this does constitute tracking under Apple's guidelines.

[elpida-v]

We’ve heard of several Apple rejections of apps in the Kids Category that use Firebase, even if they have disabled IDFA. The rejections relate to the latest Apple Review Guidelines regarding kids apps as described in section 1.3 (https://developer.apple.com/app-store/review/guidelines/#safety).

We consider using Firebase Auth and Cloud Firestore but we are reluctant to do so, in fear that Apple may reject our app even if we don’t use IDFA. We don’t plan to use analytics nor advertising. Can you give us some insight into this? Will there still be references to IDFA if we just use the above products and opt-out from IDFA?

[morganchen12]

@Poco99 for the kids' category app rejection see #5153. Using non-Analytics Firebase dependencies will not get your app auto-rejected for IDFA reasons. If you don't plan on using Analytics, you can exclude the Analytics binary entirely from your app.

[elpida-v]

@morganchen12 Thank you for the clarification.

[sipersso]

Analytics' collected data is described in this support document. Analytics will track the user's country but not their granular location and will not automatically track or log contacts, photos, or other data even if the user has given permission for the app to access that data. If you're using Analytics and want to track that data you must log it manually.

Analytics does use ad ID data to determine advertising efficiency, so this does constitute tracking under Apple's guidelines.

So this would in essence mean that I would have to show the AppTransparencyFramework dialog in order to be able to keep using Firebase Analytics? Do I understand this correctly?

[morganchen12]

Currently that is the case if the AdSupport framework is linked. You can use FirebaseAnalytics without linking AdSupport, but linking is not as explicit a control as we'd like because of issues like #1686.

Edit: This is no longer required with the latest version of Analytics. Analytics will now recognize the blank ad ID if AppTrackingTransparency consent is unavailable and continue to work correctly without ad features, even if AdSupport is linked.

[sipersso]

Thanks for the update. This is good to know. I know that there are other frameworks that currently links AdSupport too, so this is definitely something to watch out for.

[willbattel]

Will the Firebase team be providing any official guidance in the future, such as in a blog post or docs page, about how developers using the SDK can best navigate this change in policy?

There is speculation that Google will be getting rid of their GAID in a similar fashion. Regardless of whether this happens or not, it would be nice to have some concrete information compiled that developers can reference to ensure that Firebase is behaving exactly as desired.

[Gerharbo]

A blogpost or guidance in the developer documentation would even be better.

Isn’t it possible to disable the usage of a unique id? Whether it is or isn’t linked to a ad framework.

Thanks.

[morganchen12]

@kev-lam and the rest of the Analytics team are working on more comprehensive official guidance.

[Gerharbo]

@morganchen12 thanks for the quick reply and update!

[dbaroncelli]

Do we have any update on this?
In particular I would like to ask if there is a way to use Firebase Analytics and AdMob (but without targeted ads!) without requesting the IDFA and having to show the permission prompt.

[morganchen12]

You can use Firebase + AdMob and serve ads without the advertising identifier, but expect to see decreased ad revenue. The AdMob docs for iOS 14 can be found here.

[dbaroncelli]

You can use Firebase + AdMob and serve ads without the advertising identifier, but expect to see decreased ad revenue. The AdMob docs for iOS 14 can be found here.

So, can you confirm that Firebase Analytics doesn't require IDFA, and we don't need to state our app is using it when we publish to the AppStore?
And can you confirm neither Firebase Auth nor Firestore require it?

[willbattel]

You can use Firebase + AdMob and serve ads without the advertising identifier, but expect to see decreased ad revenue. The AdMob docs for iOS 14 can be found here.

Just for 100% clarity, if we do not want to use the IDFA in iOS 14, all we have to do is forgo the ATT framework and the Firebase SDK will operate with no issues other than decreased revenue and reduced attribution data?

[morganchen12]

In the latest version of Analytics, yes. Older versions aren't aware of the zeroed out IDFA and will treat it as a normal advertising identifier, which probably won't cause any issues, but is not ideal.

[Abrahanfer]

Will Firebase Analytics request ATT Authorization in future versions or Are we responsible, as developers, to request that authorization?

[morganchen12]

Analytics will never automatically request ATT authorization. It's up to you to decide whether or not access to the advertising identifier is critical to your business and request the required permissions if necessary.

[Legoless]

So, I'd also like some more insight into what data Firebase collects when only crash reporting is used. We do not use analytics as we're prohibited to do so by Apple, because we are an app made for kids. We also do not need IDFA. But we just started receiving rejections for only including the code that has references to IDFA, even if it is programatically disabled. So if the code we ship contains calls to ASIdentifierManager, we're likely to get rejected, even if that code is never executed or called. This is new on Apple's side, as before it was only a requirement that this in fact doesn't get sent anywhere, but now we need to explicitly remove the code from SDK. So I guess what I would like to confirm is: Does including Firebase/Analytics CocoaPod (or any other dependency Firebase might depend on) contain any code calls to fetching IDFA, even if it is conditionally disabled and will never be executed?

[morganchen12]

@Legoless IDFA and ASIdentifierManager are not referenced in any Firebase SDK outside of Analytics. If you only have Crashlytics installed, Crashlytics will only collect crash data (stack traces, device information) and any custom data you attach to the crash reports (by default, no custom data is attached).

[gpalouk]

@Legoless IDFA and ASIdentifierManager are not referenced in any Firebase SDK outside of Analytics. If you only have Crashlytics installed, Crashlytics will only collect crash data (stack traces, device information) and any custom data you attach to the crash reports (by default, no custom data is attached).

OK, but those Crashlytics Installation UUIDs (according official page https://firebase.google.com/support/privacy#crash-stored-info ) are not used for tracking user or his/her device by other installed apps that uses Firebase SDK (with Analytics or not) or used for some other form of identification and linking back to user or device?

In other words, we can safely define on AppStore Connect's App Privacy form that data type: Diagnostics > Crash Data are "Data Not Linked to You"?

[funnel20]

@Legoless IDFA and ASIdentifierManager are not referenced in any Firebase SDK outside of Analytics. If you only have Crashlytics installed, Crashlytics will only collect crash data (stack traces, device information) and any custom data you attach to the crash reports (by default, no custom data is attached).

OK, but those Crashlytics Installation UUIDs (according official page https://firebase.google.com/support/privacy#crash-stored-info ) are not used for tracking user or his/her device by other installed apps that uses Firebase SDK (with Analytics or not) or used for some other form of identification and linking back to user or device?

In other words, we can safely define on AppStore Connect's App Privacy form that data type: Diagnostics > Crash Data are "Data Not Linked to You"?

We have interpreted this differently, so I'm curious to the opinion from Google.

This is the Q&A flow of the App Store Privacy details regarding Diagnostics → Crash Data:

Q: Indicate how crash data collected from this app is being used by you or your third-party partners (select all that apply):
A: App Functionality (since it mentions “minimize app crashes”)

Q: Is the crash data collected from this app linked to the user’s identity?
A: Pay attention to this note from Apple:

Note: “Personal Information” and “Personal Data”, as defined under relevant privacy laws, are considered linked to the user.”

The column name of the Firebase table that mentions the Crashlytics Installation UUIDs, is called “Personal Data“ for these items.
So I observer the exact term “Personal Data“ in both Apple and Firebase privacy documents. Can there be a relation? 🤔

Q: Do you or your third-party partners use crash data for tracking purposes?
A: We have no idea. Google, are you using this to track?

[morganchen12]

In other words, we can safely define on AppStore Connect's App Privacy form that data type: Diagnostics > Crash Data are "Data Not Linked to You"?

Crashlytics crash data, including UUIDs, are not associated with any other identifiers and are not used to share data between third parties. Crash information is associated with a user if you call the setUserID: method and pass in a user identifier.

Q: Do you or your third-party partners use crash data for tracking purposes?

No.

[xanderbuck]

@morganchen12 Hi! Jumping late into this conversation. I hope its okay for me to ask a specific question pertaining to our app's situation, the above thread is a lot to process and understand.

I'm using the following Firebase pods:

pod 'Firebase/Crashlytics', '7.2.0'
pod 'Firebase/Analytics', '7.2.0'
pod 'Firebase/RemoteConfig', '7.2.0'
pod 'Firebase/Database', '7.2.0'

We use the Analytics SDK to track the following:

1. Analytics.logEvent() to track what screen the user is on, and what items on the screen they interacted with. No personal data is collected pertaining to the user, just what items they've interacted in, or what events happened in the app.
2. Analytics.setUserID() to track which user is triggering the events in the app. This id can be used to look up that user in our DB. (We are open to removing this type of tracking if need be)

My Questions:

1. Given the information above, will I need to present the AppTrackingTransparency dialog alert to the user? If yes, does removing Analytics.setUserID() then allow me to not present this dialog alert?
2. Given the information above, will I need to fill out the App Store submission questionnaire disclosing what information firebase is collecting?
3. Are we allowed to use the Analytics.setUserID() method to track which user is associated with the events we log? Does using Analytics.setUserID() force us to present AppTrackingTransparency dialog alert to the user or have any effect on the App Store submission questionnaire?

[willbattel]

@xanderbuck A Firebaser can verify this, but to my understanding:

1. No, only if you link AdSupport (which is not required for using logEvent and setUserID). AdSupport is only required for collecting detailed attribution data, and targeting ads if using AdMob.

2. Yes, but it should be pretty minimal. Since you're not using IDFA, or any other form of tracking, you simply have to disclose the fact that you collect a user identity, usage data, and crash data. For example, here is what our disclosures look like:

3. Yes you are allowed to use it. No, it does not force you to use ATT or have any effect on App Store questionnaire. ATT will only be enabled if AdSupport is linked. Without linking AdSupport, Analytics substitutes a zeroed-out IDFA in place of the actual IDFA, which limits the ability to attribute events, but does not prevent the usage of setUserID.

I'm pretty sure that this is the case- but in the event that I am wrong, anyone is welcome to correct me.

[morganchen12]

@xanderbuck Will's breakdown is correct. Do note that the user ID you're setting should not be personally identifiable information. If you're using an email, you should hash it or otherwise make it unidentifiable. Also, if you're passing a user ID to Analytics, your data collection purpose in the Identifiers category may differ from Will's screenshot above.

[ndreisg]

@willbattel @morganchen12 according to this support document Analytics collects the vendor identifier if AdSupport isn't linked.

If I do not set a UserID with Analytics.setUserID() would this mean that I need to select "Device ID" rather than "User ID" in the Data Collection questionnaire?

And is the collected data "linked to a user" if I don't set a UserID?

https://developer.apple.com/documentation/uikit/uidevice/1620059-identifierforvendor

[morganchen12]

@ndreisg collection of the two identifiers is not mutually exclusive; if you're calling setUserID(_:) it's possible both the ID you pass in and the IDFV are collected. You can disable IDFV collection by following the instructions here. If collected, the IDFV will not be linked to the identifier passed to setUserID(_:).

[morganchen12]

Hey all, thanks for your patience. Our documentation is now available here. Feel free to continue to leave feedback or questions in this thread and I will address them as they come in.

[jesko1]

Hi there, thanks for all of the information already shared.

I'm only using Analytics, Crashlytics, and RemoteConfig, and have disabled collection of the Advertising Identifier / IDFA / ad personalisation.

From what I understand, in this case in terms of identifiers Firebase is only tracking an app-instance identifier, a vendor identifier, and also the anonymised IP address.

Does anyone know if in this case this should be included in Apple's Identifiers category?

Apple's Identifiers category mentions identifiers "Such as the device's advertising identifier, or other device-level ID", so it only mentions device level identifiers rather than app level identifiers. I suppose vendor identifier would be considered a device level identifier.

[morganchen12]

It's unclear whether Apple expects every identifier to be reported or only identifiers that fit one of the two definitions Apple has provided. IDFA and IDFV are, by Apple's definitions, device-level identifiers.

[malcolm12334]

It's unclear whether Apple expects every identifier to be reported or only identifiers that fit one of the two definitions Apple has provided. IDFA and IDFV are, by Apple's definitions, device-level identifiers.

In my app I'm using Analytics & Crashlytics.
From this thread I understand that IDFA is not collected if AdSupport is not linked and IDFV could be disabled in plist, but then an app-instance ID is still collected.
Could it be possible to get rid of all ID, app-instance identifier included? So I wouldn't have to report any identifiers, just basic "usage data" and "diagnostics".
In my app, I just want to know what features of my app are the most popular, nothing more, I don't need any ID at all.
Could anyone in the same situation tell me if he was rejected/approved from the app store since dec 8th?

[meowofficial]

Currently, you can guarantee the IDFA is not collected only by removing AdSupport from your build target. Starting next year, you can prevent the collection of the advertising identifier by choosing to not present the AppTrackingTransparency permissions dialogue to your users, regardless of whether or not AdSupport is linked.

I'm using only Firebase Analytics and Firebase Crashlytics. Do I understand correctly that if I don't want to show AppTrackingTransparency dialogue, then I shouldn't use IDFA and exclude AdSupport, which means I won't be able to see Apple Search Ads as user acquisition source and other information? Will traffic from Apple Search Ads become organic for Firebase Analytics?

[morganchen12]

@A5Wali Collection of app_instance_id can be disabled with the new Consent API. See this doc for how the various consent settings enable/disable identifier collection.

@meowofficial I'm not sure about how the lack of AdSupport will affect Apple Search Ads attribution. However, starting in 2021, you can include the AdSupport framework and Analytics won't collect the IDFA unless you present the AppTrackingTransparency dialogue.

[meowofficial]

However, starting in 2021, you can include the AdSupport framework and Analytics won't collect the IDFA unless you present the AppTrackingTransparency dialogue.

I'm using Flutter. What should happen so I can understand this takes effect? January 1st or may be specific firebase_analytics version release? What should I keep an eye on?

[morganchen12]

The current version of Analytics is sufficient and you will not need to upgrade. Mechanically, what happens is once Apple starts enforcing App Tracking Transparency prompts the IDFA will be all zeroes unless the prompt is accepted. Analytics recognizes this special value and treats it as if the IDFA is not available.

[xanderbuck]

@morganchen12 You said a little earlier:

Do note that the user ID you're setting should not be personally identifiable information. If you're using an email, you should hash it or otherwise make it unidentifiable.

Using setUserID(_:), we are setting the user id we have in our DB that is of format:403cfe7c-4667-48f0-b127-41c6c1d1b4d8. We can use this Id to then look up the user, in our DB.

1. Does this count as personally identifiable information?
2. If it does count, what method do you recommend to hash this safely?

[morganchen12]

@xanderbuck what you're doing is fine.

[xanderbuck]

@morganchen12 Thanks a bunch for your help!

[herrernst]

@morganchen12 Thanks for posting the support document. I have a question about it. Mostly, it says "collect" data, but sometimes "record" instead. What's the difference between "collect" and "record", if there is any? E. g. for Messaging it says "Records the APNs token".

I am only using FirebaseMessaging without analytics, but that includes FirebaseInstanceID. I am wondering if the "FCM registration token" (is this the same as the Firebase Instance ID?) is a "User ID", "Device ID", or "Other Data" under Apple's definition?

[morganchen12]

@herrernst "collect" and "record" are used interchangeably in that document. Given its one-to-one association with the APNs token, you can probably categorize the FCM token and the APNs token identically.

[herrernst]

Thanks for your answer, but it still have questions regarding the documentation.
Under InstanceID it says:

• Generates and collects the FCM registration token [...]
• [...]
• Collects device model, language, time zone, OS version, application identifier and application version to generate the FCM registration token.

The first point would indicate that the client (App/SDK) generates the token, but the second point would indicate that device model, language etc. are sent to the server/cloud, who generates the token. Who really does?

[morganchen12]

@herrernst The token is generated server-side from the client details disclosed in the second bullet you listed. The generated token is then sent down to the client and is used/stored by both the client and the server.