This question already has answers here:
Locking down Firebase DB access to specific apps
(2 answers)
Closed last month.
Is there any way to implement authentication in Xamarin Forms app towards firebase realtime database. So that there is restriction on accessing db only from my app and not allowing everyone to read and write to db?
Check out Firebase App Check, which does precisely that.
It's no guarantee though as a sufficiently motivated user can still bypass such measures, so you'll also still want to implement the necessary instructions in security rules.
Also see:
Locking down Firebase DB access to specific apps
And these other questions about only granting access to the database from your app.
Related
I am developing a Quiz Application for IOS platform. By using the number of wrong and right answers to the questions (accumulated on the device), I want to re-arrange difficulty levels for the questions. Can I directly send these anonymous statistics to my server on the cloud, or is it required to ask the users' permission on an App page?
We submitted a few apps that took user's data anonymously and did not need to ask for any permissions.
As long as it is anonymous, when setting your app for submission on App Store Connect, you can select this option which says the data you collect does not link to the user's identity:
The above is an example of Product Interaction but you can select No for the other sections as well if this is the case.
3 of these apps got accepted on the app store without issues.
Update based on Cankan's comment
Is the device language of the user, sensitive information?
I believe yes as this seems to fall under Other Diagnostic Data and Other Usage Data.
It becomes a problem if you can trace the language back to a specific user, if you collect this anonymously, my original answer applies where you can select no.
I am developing a chat app that uses CloudKit to authenticate the users, store data on the cloud and then exchange content between users.
Initially, according to the reviewer following guideline was breached when asking user to have an iCloud account setup on the device to make use of app entire set of functionality.
5.1 Privacy
5.1.1 Data collection and storage
(ii) If your app doesn’t include significant account-based features, let people use it without a log-in. Apps may not require users to enter personal information to function, except when directly relevant to the core functionality of the app or required by law.
On a phone call I explained to him the app allows the user to open it, navigate around. But wont allow the user to create chat rooms or upload/share data within the rooms as it needs CloudKit authentication to store the data to then share it between users. According paragraph (ii) that was a significant account based feature to require authentication. He was fine with that.
Then he said he would still not be able to approve the app because CloudKit should only be used if the app intends to store data on the cloud. Data like, documents, photos, etc... according to him a chat app (WhatsApp a example) that stores images and text on the cloud to then share it between users is not actually storing data on the cloud and for that reason should not be using CloudKit and would be a definitive rejection.
Designing for CloudKit documentation says:
You can represent all the persistent model objects in your app using a CloudKit schema. However, the CloudKit framework should not be used to replace model objects in your app and should not be used for storing objects locally. It is a service for moving data to and from iCloud and sharing data between users of your app.
Not seeing where is my breach when the app:
only asks the user to authenticate when a core feature of the app is
called
uses the authentication to store messages, images, etc... in
the users iCloud account
uses the authentication to exchange this data that has been stored between users
After investing huge amounts of time and money in the app it is hard to accept a permanent rejection for such an odd reason. There is no documentation to sustain his argument or stop us from investing time/money with CloudKit wrongly.
Not sure where to go from here. Anyone with similar issue when using CloudKit?
I've got a Firebase-Newbie question: While integration Firebase in an iOS application, I was asked to use Analytics'
_anonymizeIp()
from the Firebase object. Is this possible or conceptually invalid? Any hints appreciated.
Best regards,
Marcus
IP Addresses are currently anonymized by Firebase Analytics. There is no need/method to explicitly do so.
However, nothing guarantees that we anonymize these in Firebase's API design or terms of service. Given that it's just an implementation detail, you should be careful if you are trying to rely on this for any sort of legal compliance or to meet your company's privacy policies.
The docs and APIs are updated frequently and you should keep an eye on them, as well as the release notes, for changes.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I need to develop an App in which the user can pick files from their Dropbox account and initiate a transfer a Public / Crowd sourced server.
This is not a migration of cloud storage, but manually selecting files and transferring them to a server. I have seen apps which help in migration of cloud storage through an automated script. As this is not a migration, the user may not understand what he is actually doing, or the implications of it.
My question is:
Will Apple reject the app when uploaded to the App Store for such an operation?
Will this be violating User privacy, as the user might unintentionally transfer sensitive information to a public cloud / server?
Diagrammatic representation of the operation:
As per Apple's guidelines
17.1 Apps cannot transmit data about a user without obtaining the user's prior permission and providing the user with access to
information about how and where the data will be used
So basically, to answer your question
You should provide proper message to the user of what exactly your app intends to do. Lets say in the form of a cancellable alert.
Without this apple will surely reject your app.
Secondly, this
should not be the necessary condition for your app to work. Meaning
that your app should work even if the user denies to share his
images and stuff from dropbox.
Prior to sharing / uploading user should get a view of what is being shared. Without this the application will be rejected. (This is even applicable even in the simple facebook share)
You always have a quick look on the Apple's privacy policies here
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am developing the monetization model for my iOS app and need some help on related technical questions.
Current application workflow is the following: users do some actions which require heavy use of the cloud resources (for which I am paying). These resources are quite expensive so I don't want my users to load them for free. I can imagine two possible options in such situation:
The app in AppStore is free and provides very limited functionality, users must buy in-app (auto-renewable subscription in fact) to get access to cloud resources.
The app is not free and when users buy the application they get free subscription for the first e.g. 30 days - after that they must pay monthly.
I know how to implement the 1st solution, but there are problems with the second one.
How do I know that the user JUST bought my application (not re-installed it)? Is there a way to do this?
One approach to your 2nd option could be for the app to register the current device with your service upon first launch. If (and when) that device had been registered previously, deny access to cloud functionality. UIDevices identifierForVendor will be sufficient for the task.
This would still allow the user to use the free month a second time on another device he owns though, or if he switches to a new device.
As an alternative, you could require the user to set up an account with your service, but of course there would be no way to prevent a user from creating multiple accounts.
A combination of both approaches may be able to reduce missuse, but it is unlikely you'd be able to completely suppress such attempts.
If you need to rule missuse out as far as possible, you probably need to stick to your first approach. For your second option you might want to try to factor potential losses from fake accounts / secondary devices into your pricing scheme.
The bottom line answer to your question however is: You can't know for certain if a user has reinstalled your app on a device other than the one he fist installed your app on.
Edit:
Turns out I missed the fact that the value returned by identifierforVendor won't persist. Unfortunately, that means you'll either need to stick to your first approach or rely on an account system to which the user needs to register. On second thought that may be the better approach - depending on the kind of content the user will be able to store in he cloud, the user might be reluctant to use several accounts anyway since the data in the cloud is tied to the account. Thus, multiple accounts may actually be a non-issue (just like it is impractical to keep multiple dropbox accounts).
So the answer to your question is actually: You can't tell if the user is re-installing your app.