Firebase Analytics: New Apple Privacy Guidelines (Fall 2020)

aschuch commented 4 years ago

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.

dbaroncelli commented 3 years ago

It’s not fair to dump the burden of all these legal issues to the Firebase users.

I encourage you to create a document which is clear enough not to require each Firebase user to ask for individual consultancy.

Daniele

Il giorno 17 nov 2020, alle ore 09:11, Morgan Chen notifications@github.com ha scritto:

The document content we've prepared thus far covers conditional data collection for Firebase SDKs, including Analytics with and without AdSupport.

Unfortunately, our guidance discourages us from categorizing the data Firebase collects on your behalf, so I'm not able to tell you which boxes in the questionnaire you should fill out. This is not because we know all the categories behind the scenes and want to keep them a secret from you; rather, it's because Apple's definitions (though not strictly legal definitions) may have legal implications and the Firebase staff who are active on this repository, including myself, are not qualified to provide answers to legal questions. We can tell you in detail what data Firebase collects, but we cannot tell you how that data fits under Apple's definitions. With that in mind, here's the data collection bits that may be relevant to your question:

Analytics collects anonymized IP addresses https://support.google.com/analytics/answer/2763052 and uses them to approximate user location. This is how the Analytics dashboard is able to break down your user base by country. Without AdSupport, Analytics does not collect any identifiers except the Firebase Installations ID by default. I know it's not what you want to hear, but if you need to explicitly categorize the above data collection items, you will need to retain your own legal counsel.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/firebase/firebase-ios-sdk/issues/5928#issuecomment-728761900, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIS3KAVMK5XAHD3FTRRTFTSQIV2NANCNFSM4OJRFJPA.

abotkin-cpi commented 3 years ago

Unfortunately, our guidance discourages us from categorizing the data Firebase collects on your behalf, so I'm not able to tell you which boxes in the questionnaire you should fill out. This is not because we know all the categories behind the scenes and want to keep them a secret from you; rather, it's because Apple's definitions (though not strictly legal definitions) may have legal implications and the Firebase staff who are active on this repository, including myself, are not qualified to provide answers to legal questions. We can tell you in detail what data Firebase collects, but we cannot tell you how that data fits under Apple's definitions.

While I can appreciate that the Firebase developers may not be qualified to answer those questions, is Apple Developer Relations similarly telling you they can not provide guidance given the info you've provided? I would think Google's Apple Developer Relations contact would be able to assist in this situation.

morganchen12 commented 3 years ago

I unfortunately don't have visibility into the Apple-Google communications, but there's been no indication that Apple will update their wording.

It’s not fair to dump the burden of all these legal issues to the Firebase users.

I agree, but this is largely a consequence of the App Store's data collection definitions' ambiguous wording. For unambiguous legal text like GDPR and CCPA we are happy to provide exact categorizations of Firebase's behavior (see the privacy doc).

Again, we fully understand that it is extremely unpleasant to be saddled with legal responsibilities, especially for independent developers. But there's not much we can do unless Apple updates their wording and legal gives us a set of definitions based on the new wording.

funnel20 commented 3 years ago

We do plan on publishing our doc before Apple's deadline. It needs to go through a lot of review internally before that can happen, so I can't guarantee we'll succeed, but currently things are on track.

With the deadline of December 8, 2020 rapidly approaching it's time to deliver. When and where can we expect this document?

funnel20 commented 3 years ago

Unfortunately, our guidance discourages us from categorizing the data Firebase collects on your behalf, so I'm not able to tell you which boxes in the questionnaire you should fill out. This is not because we know all the categories behind the scenes and want to keep them a secret from you; rather, it's because Apple's definitions (though not strictly legal definitions) may have legal implications and the Firebase staff who are active on this repository, including myself, are not qualified to provide answers to legal questions. We can tell you in detail what data Firebase collects, but we cannot tell you how that data fits under Apple's definitions. With that in mind, here's the data collection bits that may be relevant to your question:

You're exactly pinpointing the root cause of the massive data theft and privacy invasion by companies like Facebook and Google. The minions like you, that are actually implementing all this unethical code logic have no legal background, common sense, nor responsibility to society. And are extremely well-educated in shifting responsibility, like you do now toward Apple and your customers.

As a result of your ongoing doubtful practises, Apple demands transparency:

for their users
through their developers
from you. Yes you, Google

Google engineers, like you, are the only ones who know the details of your data hunger products and inner linking. Therefor it's the responsibility of Google to publish a list that matches all your products (and combinations, like Analytics with/without AdMob, etc.) exactly on the definitions from Apple.

Because we, as customers of your products, do not have that insight. Nor have our legal counselors.

funnel20 commented 3 years ago

Other developers are perfectly capable of answering the Apple list, as this linked item resulted in a beautiful table at https://sdwebimage.github.io/DataCollection/index.html for the SDWebImage project. Here is a preview:

So Google, please follow this great example. And hurry up, as the deadline is due in 10 days.

morganchen12 commented 3 years ago

When and where can we expect this document?

We're trying to publish it as soon as possible, but cannot guarantee that it will be public before December 8. If you have a question that you need answered that has not already been answered in this thread, feel free to ask here and I'll address it so you can submit your app to the App Store.

@funnel20 while I appreciate your passion on this subject, frustration alone is not sufficient for Google's legal staff to overturn their guidance, and I don't really have anything to effectively push back on their decision either. If you would like to elicit real change for user privacy, there are certainly more productive ways to channel your frustration than accusing the maintainers of this repository of having no common sense or responsibility. SDWebImage is obviously outdoing us in terms of docs--though I imagine our legal staff would be much more willing to publish explicitly categorized data collection items if we could simply answer "no data collected" for every question. :)

In the past, we haven't forbade users from venting their frustration on our GitHub issues, but if you choose to do so please avoid ad hominem attacks on the maintainers or other contributors and note that on longer threads your comments may be hidden to improve thread readability.

funnel20 commented 3 years ago

@morganchen12 With "maintainers of this repository" you make the impression that a bunch of geeks spend all their free time in a great product for their community. Please let me remind you that Firebase is part of Google and that Google is a NASDAQ registered multinational that earns billions of dollars, primarily by selling targeted advertisement based on data that this community collects through Firebase.

I do not intent to start a Twitter fight here, like your soon to be ex-president. I'm just using facts and demand that Google acts responsible by delivering the required privacy details on time:

If Google would have acted responsibly, we wouldn't have this discussion now. Then all requested documentation would be available. Because Apple announced this in June 2020 and this thread is started by a community member in the same month. So it's not something that fell from the sky last week. 5 months have passed now and all Google can deliver is some vague promise that there will be some document around December 8. As "maintainers of this repository" it's your responsibility to escalate internally when all community posts here indicate that things are getting critical. This has not been done, as developers are struggling 1 week before the Apple deadline with no information.
Shifting responsibility to thousands of Firebase users (very conservative estimation) to hire legal counselors, proofs a lack of common sense. As well as dismissing fair criticism as frustration. Google creates an inability for all their users to take effective action, also known as helplessness. Can't you sense this and help us?

When you operate in the front line, don't complain that you're being criticised. Especially when those operations are controversial, as indicated by the most recent US Senate subpoena.

Koshub commented 3 years ago

@funnel20 There is a way just to cut out the Firebase integration, as I decided for now, for some projects where possible legal implications may produce more risks. Not sure that the pressure here is a way to achieve some valuable results

PawlikMichal25 commented 3 years ago

@morganchen12 According to this https://support.google.com/firebase/answer/6318039?hl=en if the app is not using AdSupport, Firebase SDK will be using Vendor Identifier.

Is this Vendor Identifier used for tracking?

Where by tracking I mean:

Tracking:
Tracking is linking data collected from your app about a particular end-user or device, such as a user ID, device ID, or profile, with Third-Party Data for targeted advertising or advertising measurement purposes. It also refers to sharing data collected from your app about a particular end-user or device with a data broker.

Tracking does not apply in the following situations:

When the data is linked solely on the end-user's device and is not sent off the device in a way that can identify the end-user or device
When the data broker uses the data shared with them solely for fraud detection or prevention or security purposes, and solely on your behalf

Third-Party Data:
Third-Party Data is any data about a particular end-user or device collected from the apps, websites, or offline properties not owned by you, the developer.

Examples:
To help put tracking into context, here are a few examples:

- 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 a login SDK that repurposes the data it collects from your app to enable targeted advertising in other developers' apps.

morganchen12 commented 3 years ago

The vendor ID is not linked to third-party data for targeted advertising or ad measurement purposes (to do so is explicitly forbidden by Apple in this document).

obigu commented 3 years ago

legal staff would be much more willing to publish explicitly categorized data collection items if we could simply answer "no data collected" for every question. :)

This is IronSource for example (https://developers.ironsrc.com/ironsource-mobile/ios/apples-privacy-questionnaire-answers-ironsource/) if you need examples of companies that do collect personal data.

The fact that more answers are "yes" in the case of Firebase is no excuse. As shown, there are other companies that don't try to transfer their legal responsibilities to developers and are transparent on exactly what data does their SDK use.

dbaroncelli commented 3 years ago

Well said Obigu!

It's ashaming the way the Firebase team is trying to avoid transparency.

It can be so simple. It doesn't take much. Just the willingness, which the Firebase team is clearly lacking.

On Tue, 1 Dec 2020, 02:39 obigu, notifications@github.com wrote:

legal staff would be much more willing to publish explicitly categorized data collection items if we could simply answer "no data collected" for every question. :)

This is IronSource for example ( https://developers.ironsrc.com/ironsource-mobile/ios/apples-privacy-questionnaire-answers-ironsource/) if you need examples of companies that do collect personal data.

[image: image] https://user-images.githubusercontent.com/1794492/100685641-0e5f7e80-337d-11eb-9b13-5772454dacce.png

The fact that more answers are "yes" in the case of Firebase is no excuse. As shown, there are other companies that don't try to derive legal responsibilities on developers and are transparent on exactly what data does their SDK use.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/firebase/firebase-ios-sdk/issues/5928#issuecomment-736160134, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIS3KA4B4JDUZTCS6J47WTSSRCMLANCNFSM4OJRFJPA .

Legoless commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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:

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.
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:

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?
Given the information above, will I need to fill out the App Store submission questionnaire disclosing what information firebase is collecting?
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 commented 3 years ago

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

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.
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:

Capture

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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.

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

morganchen12 commented 3 years ago

@xanderbuck what you're doing is fine.

xanderbuck commented 3 years ago

@morganchen12 Thanks a bunch for your help!

herrernst commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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.

firebase / firebase-ios-sdk