I am building a native social app in Android and iOS
I am using contacts from users phonebook to determine if his target friends are on our app or not and send the events accordingly
I recently came across this news that Apple is banning apps to send contacts to the server, which is the backbone of my app in order to function
How should I approach this problem? How do apps like WhatsApp which sync contacts (whole phonebook) to their server manage through this?
Do I need apple review of the app to access phonebook permission?
From This article I quote
But the phone maker didn’t publicly mention updated App Store Review
Guidelines that now bar developers from making databases of address
book information they gather from iPhone users. Sharing and selling
that database with third parties is also now forbidden. And an app
can’t get a user’s contact list, say it’s being used for one thing,
and then use it for something else -- unless the developer gets
consent again. Anyone caught breaking the rules may be banned.
Since the question is quite general let's dive into it a bit.
Looking into the App Store Review Guidelines there are three places mentioning that users' contacts should not be collected.
First and second, users should not be forced to provide their address book in exchange for app functionality (paying with contacts; highlights were added, a similar phrase is used for app subscriptions):
Apps should allow a user to get what they’ve paid for without performing additional tasks, such as posting on social media, uploading contacts, […]
Third, uploading and/or storing contacts to/on a server has an impact on users' privacy and is prohibited for the following use-cases:
Do not use information from Contacts, Photos, or other APIs that access user data to build a contact database for your own use or for sale/distribution to third parties, and don’t collect information about which other apps are installed on a user’s device for the purposes of analytics or advertising/marketing.
This does not exclude using contacts for creating a social graph for the benefit of your users. However, collecting all contacts might violate the principle of data minimization. So Instead of just uploading all contacts, Apple recommends to use a contact picker (see ContactsUI), where the app only gets access to the contacts the user selected:
Data Minimization: Apps should only request access to data relevant to the core functionality of the app and should only collect and use data that is required to accomplish the relevant task. Where possible, use the out-of-process picker or a share sheet rather than requesting full access to protected resources like Photos or Contacts.
The Art. 32 of the GDPR requires you to take the
[…] the state of the art, the costs of implementation and the nature, scope, context and purposes of processing […]
into account.
I think that the process has to be made transparent (as in comprehensibly explained to the user):
The user should have control over which contacts are used for discovery. All would be a valid choice – selected contacts (through the contact picker) or manually entering contact information (phone number, email – whatever is used for your contact discovery process) would be valid choices as well.
The app should function even if the user denies access to the contacts. In that case you can still offer a contact picker, or manual entering.
You must describe the process, including what information is used and for what purpose, in your privacy policy.
You should at least hash the processed values, as you do not need the actual phone numbers or email addresses for contact discovery and hashing comes without much effort and cost. However, be aware that hashing of personally identifiable information is not sufficient for "anonymising" these values – which is a common misconception.
For more advanced protection, you can take a look at the blog post by the authors of the Signal app, where they describe technical details on how they protect their contact discovery process.
Related
I'm developing an iOS app, and ideally I would like to include Google Analytics and AdMob (through Firebase).
I would also like to avoid showing consent forms if it's not necessary - potentially by not accessing the iOS Advertising Identifier (IDFA). But I can't find any clear answers as to whether consent is necessary in that case.
I know that:
We must ask for Analytics consent on a web page accessed by someone in the EU, because the ePrivacy Directive requires consent for the cookies used. An iOS app doesn't use cookies, but the same law applies for other types of local storage. (Source: gdpr.eu)
We must ask for consent to show personalized ads to a user in the EEA or UK, because the IDFA is required and this counts as personal data under GDPR. We must also ask for consent to show non-personalized ads, because Google also uses the IDFA for these. (Source: Google AdMob policy document)
Google's own policy requires we ask EEA/UK users for consent for the use of cookies and local storage, and for the use of personal data to provide personalized ads, in order to use Google's services. (Source: Google EU user consent policy)
The only other relevant question I found was this one which suggests I can just put this information in my privacy policy, but that answer is from 2015 which is before GDPR came into effect.
So my questions are:
Does Google/Firebase Analytics on iOS use local storage? Does it collect anything the GDPR would call "personally identifiable information" like IP address? And if the answer is yes to either of these, am I right in thinking I need to get explicit consent from EEA/UK users to use analytics?
Does AdMob only require consent from EEA/UK users because of its use of the IDFA? If so, can I just not include the AdSupport framework (thus disabling the IDFA) and so not have to obtain consent?
Is there anything in the App Store policies that require consent to be given before analytics or non-personalized ads are used?
To be clear, I'm not trying to hide anything from my users. If personal data has to be sent to provide these services and there's no way around that, then I'll happily show the consent form. I'd rather not send any identifying data off of my users' devices, but I need to be able to show some form of ads to support the app, and I'd like to be able to view simple analytics.
Good questions.
There is no such thing as "personally identifiable information" in GDPR. The term is "personal data", and it is not limited to data that is identifying, officially:
any information relating to an identified or identifiable natural person
For example the colour red by itself is just data, not at all personal, and the GDPR doesn't care what you do with it. However, if you store it as a specific person's "favourite colour", it then becomes personal data in the GDPR sense.
Part of the reason for that is that individual fields may not be identifying, but they may become so when used in combination with other (possibly also non-identifying) fields. For example, John Smith in London, is probably insufficient to identify a specific individual, but John Smith in Greenland probably wouldn't be too hard to track down. This of course becomes easier the more fields are involved, no matter how innocuous & anonymous they may appear individually. This is the entire basis for browser fingerprinting, common in bad ad tech.
The ePD and GDPR don't contain rules about cookies that you can work around by using other technologies (e.g. local storage, as you note); if they achieve the same end, they qualify as things that would typically need the same level of consent.
In the wake of the Schrems II judgement and the entirely expected collapse of Privacy Shield, you effectively can't use any of Google or Facebook's services from the EU. Both of them have issued statements about using SCCs in place of Privacy Shield, however, they misrepresent what the ECJ found (SCCs are valid in general, but can't be used in jurisdictions that don't provide sufficient protection, which includes the US), and those policies will not survive. The proverbial hasn't hit the fan on this in court yet, but it will happen, and soon. For example the UK is likely to lose GDPR adequacy status in January 2021 over their onerous surveillance laws and lack of GDPR enforcement, on top of the complications caused by brexit.
You can avoid wider problems with google analytics by using a self-hosted analytics system like Matomo, where you can be absolutely certain of where your data is going.
Contextual ad services without behavioural tracking do exist, and they're generally not much less effective than the nastier bits of ad tech, despite what the ad networks will try to tell you!
Remember that consent is the basis of last resort in GDPR; if you can use another basis, such as contract, then you should use that in preference. This means for example that you don't need consent to process someone's data that has created an account on your system, so long as the administration of that account is all that the data is used for. If you want to use that same data for marketing though, that does require consent (that's ePD, not GDPR). Also remember that you can't contract out of fundamental rights, though consent can be stretched quite a long way in practice. This also means you can't just wriggle out of obligations by hiding something in a privacy policy. A privacy policy is not in any way binding on the user – they can't "agree" to it like a contract; it is there to inform them how you handle their data. A good check to do on a policy is to look at all uses of the work "may", as it often hides a multitude of sins. If you can't explicitly name all third parties a user's data will be shared with, you shouldn't be using those services.
Now while I've said quite a bit here, I don't actually know enough about how Apple uses data in the IDFA to be more help on that specific case, however, the background is all the same, so I hope some of this helps.
The key legislation here is the EU's ePrivacy Directive and its national laws. The most important article is 5(3) which was amended in 2009. It says:
"Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information, in accordance with Directive 95/46/EC, inter alia, about the purposes of the processing. This shall not prevent any technical storage or access for the sole purpose of carrying out the transmission of a communication over an electronic communications network, or as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service.’;
You'll notice that it does not mention cookies as the scope of the applicability is much wider. It applies in 2 scenarios:
When you (or the 3rd parties you use) store 'information' (e.g. cookie) on your end users' end terminals (e.g. a mobile phone); or
When you (or the 3rd parties you use) gain access to information already stored in the end terminal.
Please note that this article applies even if your activities does not involve the processing of personal data. If you also process personal data, then the GDPR applies as well.
So answer to your 1st question is: You need consent under the ePrivacy Directive for Google Firebase. The information it collects is also personal data so you'll need to comply with GDPR obligations as well (privacy notices, data subject rights, transfers to 3rd countries etc.)
The answer to your 2nd question is: You are likely to need consent anyways as you are 'storing' AdMob SDK (as information) to your end users' end terminals and it reads information from these end terminals (gains access to information already stored...).
The answer for your 3rd question: Haven't read those policies in a while, but they are likely to require you to be compliant with applicable legislation. This includes the ePrivacy and GDPR among other laws.
The final poit is that likely you won't find too many iOS / Android apps that would be fully compliant with the ePrivacy as the European authorities have not enforced it despite the above mentioned consent requirement been applicable since 2011!
I am currently in the process of bringing an app to the iOS app store. It's just a small app I made in my free time. It is workout-related, so the app requires access to location and health data from the user. The data, however, is only stored on user devices. My app does not send this data anywhere (except for iCloud sync), no login is required, and I also do not implement any tracking frameworks except for the built-in Apple one that you have to agree to when setting up iOS.
Now the app store requires me to link to a privacy policy (probably because health data is potentially sensitive information). I searched for privacy policy generators online, but all I could find just seem to assume that you collect personal data. They include statements such as:
We collect several different types of information for various purposes to provide and improve our Service to you.
or
Your information, including Personal Data, may be transferred to — and maintained on — computers located outside of your state, province, country or other governmental jurisdiction where the data protection laws may differ than those from your jurisdiction.
I am afraid this might confuse users, since I explicitly state on my app store description that the data is not stored on my servers. Should I keep this in the policy nonetheless to be on the safe side legally? Or can anyone point me into the right direction what I need to include in my policy if I actually do not collect personal user data?
You collect + use personal data (location data + health data) in your app, regardless of the method of storage: on your own servers, locally on user's device, and so on. The only difference is that you do not send the collected data anywhere else (except iCloud sync).
If you don't use the collected data, simply disclose it in your Privacy Policy. Disclose that the data you collect is not store outside the user's device (except for iCloud).
Ecquire has an example of Privacy Policy for "no collection of data":
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'm developing iOS app, friends of mine suggested me to use some tracking system, to find out how "really" people are using my app, analyze result. And pivot if needed.
I decked to use Mixpanel system. Do I need to to ask user about permission ? I just wonder that somebody could be offended by tracking. On the other hand data is anonymous.
What Apple says about tracking ?
Can I easily disable Mixpanels's track method (https://mixpanel.com/site_media/doctyl/uploads/iPhone-spec/Classes/Mixpanel/index.html#//apple_ref/occ/instm/Mixpanel/track:properties:) or I need to check some flags myself ?
PS:
I also have some doubts about the fact, that my app don't use network connection at all (besides buying in app purchases). And I wonder that user could be not aware that I track his behaviour and send it to the serwer (using network conneciton)
According to the App Store Review Guidelines, you may not transmit data about a user without permission:
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
There is even a more specific guideline regarding collection information on minors:
17.4 Apps that collect, transmit, or have the capability to share personal information (e.g. name, address, email, location, photos, videos, drawings, the ability to chat, other personal data, or persistent identifiers used in combination with any of the above) from a minor must comply with applicable children's privacy statutes, and must include a privacy policy
I suspect this isn't the case here, but if you include location information, you must request permission for that, too:
4.1 Apps that do not notify and obtain user consent before collecting, transmitting, or using location data will be rejected
Whether you can collect non-identifying information (e.g. anonymous app usage information), is less clear. If you collect anything, though, your app should disclose its privacy policy regarding both identifying and non-identifying information.
I have an app that I did as a proof of concept and put on the app store just to gain experience going through the process but it turns out, it gets quite a few downloads, probably 30 a week. No Angry Birds but the app is very specific on the data it provides. It's a free app and what I would like to do now is gather some data on the users - how often they use it, where they are, what information they are searching and saving. I have no intention of touching personal data but I'd like to be able to aggregate what all the users are doing and see if there's any value in that.
Is this permitted in an iOS app? I see reports where apps are gathering more data than that (like Path pulling all your contacts) and I would think what I am looking to do is pretty standard.
Any advice is appreciated.
Check the App Store approval guidelines. That is the best resource you have.
https://developer.apple.com/appstore/resources/approval/guidelines.html
A few excerpts that may be relevant to you:
Location
4.1 Apps that do not notify and obtain user consent before collecting, transmitting, or using location data will be rejected
4.2 Apps that use location-based APIs for automatic or autonomous control of vehicles, aircraft, or other devices will be rejected
4.3 Apps that use location-based APIs for dispatch, fleet management, or emergency services will be rejected
4.4 Location data can only be used when directly relevant to the features and services provided by the App to the user or to support
approved advertising uses
Privacy
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
17.2 Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected
17.3 Apps that target minors for data collection will be rejected
Independent of what the guideline says, you should be mindful of your users privacy. As long as you don't pin the information you collect to individual users, I guess you might be fine.
Regarding location data, the guideline states you can't collect for analytical purposes if it is not relevant to the app's usage. However, it is referring to the gps data. You can obtain location for analytical purposes through network access information.