Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: Do I need this for Firebase Authentication / Crashlytics / Google Maps? #45

Closed
martin-braun opened this issue Jul 11, 2023 · 5 comments

Comments

@martin-braun
Copy link

martin-braun commented Jul 11, 2023

I'd like to avoid using this plugin, however I do leverage Firebase Authentication (OTP) / Crashlytics and Google Maps.

  • I embed the Google Maps widget to display map data.
  • I call FirebaseAuth.instance.verifyPhoneNumber(...) and await FirebaseAuth.instance.signInWithCredential(...) to verify a phone number via SMS, which results in a phone account at Google Firebase.
  • I also call await FirebaseCrashlytics.instance.setCrashlyticsCollectionEnabled(true) to catch crashes of my app.

Since this is Google, I do believe the data is used by Google to track my users, it's not? Apple blocks my app by saying:

The app privacy information you provided in App Store Connect indicates you collect data in order to track the user, including Crash Data, Precise Location, Phone Number, Performance Data, and Coarse Location. However, you do not use App Tracking Transparency to request the user's permission before tracking their activity.

I could bypass the requirement for AppTrackingTransparency if I don't declare the data to be used for tracking, but I fear the legal repercussions. I don't look for legal advice, but I would appreciate your opinions about that anyways. I'm also confused by the fact how I am supposed to use OTP sign-in, if the user can reject the dialog.

We already get permission through a dialog to use those services, but we obviously can't prevent Crashlytics from connecting on initial app load.

Please help me. Any advice will help.

@deniza
Copy link
Owner

deniza commented Jul 12, 2023

Apple's App Tracking Transparency (ATT) framework gives users the option to opt out of advertiser tracking. This is done by asking users whether they want to allow apps to track them across other apps. If a user chooses "No," their IDFA, a unique device identifier, is set to zero. This means that advertisers can no longer track that user between different apps through ads. So by definition its usage is mainly about advertising.

I can tell you that Firebase Crashlytics does not depend on or use IDFA. I also highly doubt that OTP sign-in frameworks use IDFA.

I suspect that Google Maps may be using IDFA to track users, but it should not be mandatory.

@martin-braun
Copy link
Author

martin-braun commented Jul 14, 2023

@deniza First of all, thank you for your response, this really confirms what I was reading about ATT, that it's only about the IDFA being accessible or not. I'm pretty sure the Maps widget won't access the IDFA either, because not even the Google Maps app does that.

Here is the thing though: As soon as I declare anything being "Tracked" and not just "Collected", Apple will reject our app with the quoted message about as reason for the reject.

The funny part is, that the very same app settings form doesn't allow me to declare the IDFA being accessed or not. So I don't understand why they enforce such rule.

Since we have an own consent dialog, we proceeded to declare nothing as being "Shared", but it feels wrong.

Do you maybe know why we are facing this issue and what can be done about it?

In their words:

Starting with iOS 14.5, apps on the App Store need to receive the user’s permission through the AppTrackingTransparency framework before collecting data used to track them. This requirement protects the privacy of App Store users.

@martin-braun
Copy link
Author

martin-braun commented Jul 14, 2023

Since we have more than one app in review facing the very same issue, I just responded on another app (that still has "Tracking" declared of above listed data) with:

The AppTrackingTransparency framework was designed by Apple to prevent the access to the IDFA that can be used to track a user across different apps. However, the services that we use are not accessing the IDFA, so the implementation of the AppTrackingTransparency should not be necessary.

On top of that we do provide a consent dialog that the user explicitly has to accept in order to use the app. Prior given consent, the app will not share any data and will only collect the necessary amount to operate (i.e. IP addresses etc.).

We do value our users privacy and do not try to harm or infringe on laws. We give our users the ability to erase their accounts and don't store any data for longer than necessary. We do not track the user across multiple apps and our third party services are implemented under legitimate interest such as fraud prevention, account management and performance optimization.

Thank you.

I'm keen to see what they will respond on that.

@ofiTech
Copy link

ofiTech commented Jul 26, 2023

Since we have more than one app in review facing the very same issue, I just responded on another app (that still has "Tracking" declared of above listed data) with:

The AppTrackingTransparency framework was designed by Apple to prevent the access to the IDFA that can be used to track a user across different apps. However, the services that we use are not accessing the IDFA, so the implementation of the AppTrackingTransparency should not be necessary.
On top of that we do provide a consent dialog that the user explicitly has to accept in order to use the app. Prior given consent, the app will not share any data and will only collect the necessary amount to operate (i.e. IP addresses etc.).
We do value our users privacy and do not try to harm or infringe on laws. We give our users the ability to erase their accounts and don't store any data for longer than necessary. We do not track the user across multiple apps and our third party services are implemented under legitimate interest such as fraud prevention, account management and performance optimization.
Thank you.

I'm keen to see what they will respond on that.

Did they answer?

@martin-braun
Copy link
Author

martin-braun commented Jul 30, 2023

@ofiTech We have multiple apps in the review process at the moment. They did not really comment on my statement, but they moved on to the next issue of our app. Since we haven't passed the review process so far, I cannot tell what will happen next.

We decided to not specify any tracking in all of our other apps, as we'd think that it would cause the same discussion over and over again. We have our consent dialog and nothing is tracked prior. Apple should just keep shut and let us do our business on our own risk.

On several apps, this seem to raise no concern on Apples side, on one app though, they responded with:

  1. Is the data collected by your app shared with any third-party data brokers?
  2. Is the data collected by your app linked with third-party data for marketing or advertising purposes?
  3. When users access web content in your app, are cookies collected for tracking purposes on iOS?

This is a farce and I get it now. They clearly have working force that is partly un-educated and I'm willing to talk about that publicly now. They somehow confuse their ATT with tracking in general. Normally, I should be able to define the trackers (because it will happen sometime in the app) and Apple should acknowledge our consent dialog. The problem is their lack of clear guidelines for the staff, it seems to depend on who is looking at your app and who not.

We are really frustrated with this company and their inconsistent rules, which we can proof to ourself, since all those apps are literally the same with different brandings. We thus know they have no strong rules, otherwise they should complain about the same things when reviewing our apps. They do not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants