19 February 2020
By passing the EU General Data Protection Regulation (GDPR), the European Union is seeking to bring individuals greater privacy, security, and control over their personal data.
Implementing the GDPR's requirements has been a major challenge for many companies. Compliance is important for everyone. And because of the types of information mobile apps can gather, app developers and publisher must be especially careful.
A lot of misleading information is circulating about the GDPR, and a lot of businesses are treating it as an inconvenience rather than an opportunity. Getting a handle on how to implement the principles and requirements of the GDPR is essential.
Let's take a look at the implications of the law on mobile apps.
As people's lives move more and more online, businesses and governments have access to increasingly detailed information about them. Mobile technology takes these details to a whole new level.
People willingly (or sometimes unthinkingly) engage with devices that can monitor their movements, track their sleep patterns, and record their speech. Needless to say, this sort of personal data must be treated with the utmost respect.
The primary purpose of the GDPR is to regulate the processing of personal data. But what does this mean in practice?
Personal data is a very broad term, and every time the EU defines it, it seems to get broader.
Many people would think of "personal data" as information like a person's name or social security number. This is correct, but it's only the tip of the iceberg.
"Personal data" as defined at Article 4 of the GDPR also includes any information that can be associated with an "identifiable person." This extends to their address and phone number. It even extends to their IP address and browsing history.
"Processing" means doing basically anything to that personal data; from collecting it, to storing it or sharing it.
The GDPR applies to all individuals and companies who process personal data in the EU, so long as they either:
"Monitoring behavior" includes the use of technologies such as tracking cookies and other behavioral marketing tools.
According to Article 3, this also applies to non-EU companies, even those without any presence in the EU. So, if your app is made available to people in the EU, you need to comply with the GDPR.
Mobile apps can process a lot of personal data. For example, they can:
The GDPR regulates the ways in which an app developer can process personal data via an app. But it doesn't provide a list of rules about what apps can and can't do. It governs the processing of personal data by:
Here's how you apply these three concepts when designing your app.
The GDPR requires that you have a lawful basis for all processing of personal data. This means that you cannot collect, store or use someone's personal data without a valid legal reason.
Here are the six lawful bases under Article 6:
One common misconception about the GDPR is that it requires you to earn a person's consent for every act of data processing.
It's true that consent is an extremely important concept in the GDPR. But it's also important not to ask for consent in certain situations. There are five other lawful bases, and sometimes another one of these might be more appropriate.
When considering whether to seek consent for a particular act of data processing, you have to consider both the law and your agreements with other third parties.
Here's what Apple has to say about seeking permission to collect user data in its App Store Review Guidelines:
Apple states that apps must obtain consent for collecting user data. However, it also states that collecting data under the lawful basis of "legitimate interests" (point "f" in the list of lawful bases, above) is possible where it is done in compliance with the GDPR.
And from the perspective of EU law, here's what the European Union Agency for Network and Information Security (ENISA) has to say in its study on mobile apps and the GDPR about relying on legitimate interests when providing a mobile app (at page 17 of the linked PDF):
The key takeaways from this passage are:
Here's an example of how ensuring security might constitute a legitimate interest. If you can establish a legitimate interest for a particular act of data processing, you don't have to ask for consent for it.
Let's say your app has been exploited by a distributed denial of service (DDoS) attack. This happened to over 300 apps in the Google Play Store in August 2017.
You've determined that you must log your users' IP addresses to help determine the source of the attack. IP addresses, even dynamic IP addresses, are considered personal data under EU law. Therefore, you require a lawful basis to do this.
You could ask your users for consent to log their IP addresses. But what would happen if they all said no? This could mean that you were unable to protect the security of your app.
To rely on legitimate interests instead, you need to conduct a Legitimate Interests Assessment. You can use a three-part test for this.
If you can satisfy this three-part test in relation to a specific act of data processing, you have a legitimate interest, and you don't need to ask for consent to process personal data for that purpose.
There are some things you'll definitely need to seek consent for, primarily:
The GDPR's model of consent requires that you obtain it in a very specific way. It has no concept of "implied" consent. Consent must be:
Although processing personal data for marketing doesn't require consent in all contexts under the GDPR, remember that you also need to consider your agreements with third parties.
For example, Google's EU User Consent Policy applies to anyone whose app serves ads to users in the European Economic Area (the EU plus Iceland, Lichtenstein, and Norway). It applies to use of various Google products, including AdMob.
The policy takes a strict interpretation of the EU's consent requirements under both the GDPR and the ePrivacy Directive (another EU law, also known as the "Cookies Directive"). However, it can also result in some problematic implementations under these laws, as we'll see later.
According to a Googles help document, you must obtain consent for both personalized and non-personalized ads. This is because even their non-personalized ads use frequency-capping and ad-measurement cookies.
Here's how it looks used in the Wallpaper Setter app:
MoPub also offers a consent solution, and you're required to use it if you serve MoPub ads to EU users:
Permissions are a way to use your app's architecture to request consent for processing personal data. They are used when your app needs to interact with the functions (e.g. camera, microphone) or storage on your users' device.
Apple offers some guidance on which types of personal data require permission to collect in iOS apps:
And here's that important section again of Apple's App Store Review Guidelines that we looked at earlier:
This relates to the requirement in the GDPR that consent is "freely given." Recital 42 says:
"Consent should not be regarded as freely given if the data subject has no genuine or free choice or is unable to refuse or withdraw consent without detriment."
Permissions can be requested at runtime. This is how that looks in the Video Wallpaper Android app:
There are other important contexts in which to make permission requests. For example, here's how the Galaxy Wearable app requests permission to download additional apps which collect personal data from a wearable device:
Make sure to familiarize yourself with what permissions you need to request and how you need to make the request.
Running through the GDPR are six privacy principles:
A seventh principle of accountability is also sometimes included in the list of principles.
Let's take a brief look at how three of these principles apply to mobile app development.
You must take every opportunity to present this policy to your users. For example, it should be available in your app's "settings" or "about" menu. Here's an example from BBC Sounds:
And here's how Microsoft Office Lens does this:
Enter your email address where you'd like your policy sent, select translation versions and click "Generate."
The principle of data minimization is crucial when developing your app. Don't collect any personal data you don't need.
Here's some advice from Apple on limiting the number of permission requests in your apps:
Your app may require people to share personal data. But it must not be used to "harvest" personal data.
Here's a relevant section of Apple's App Store Review Guidelines:
It notes that "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."
Personal data must always be processed securely.
Appropriate security measures, such as pseudonymization and encryption, should be built into your app. This also relates to the GDPR's concepts of "privacy by design and by default."
The UK's National Cyber Security Centre offers some guidance on implementing technical measures to achieve secure data store in your iOS app. It recommends, for example, that developers do not store sensitive data in iCloud.
Here's an excerpt from the guidance:
This guidance addresses issues of security including storage, passcodes and handling sensitive information in a secure way.
The GDPR grants individuals with eight rights over their personal data. It's your duty to facilitate these rights on request.
These include the right to:
In its settings menu, WhatsApp allows users to exercise their rights to access, data portability, and erasure (the right to be forgotten). It's a lot simpler than it sounds.
Selecting "Request account info" leads to this screen:
If properly executed by WhatsApp, this should satisfy the right to access and the right to data portability.
Selecting "Delete my account" leads to this screen:
This should satisfy the right to erasure.
You don't need to provide the function as part of the architecture of your app. You can simply carry out your obligations after receiving a request from a user via email. But WhatsApp provides a great example of how it's possible to give greater control to your users.
It will be a challenge to create a consent solution that will fulfill the requirements of the GDPR and your advertising partners, whilst still allowing you to make money from ads.
Let's look at an example - the Speedtest Android app by Ookla. We'll see how it meets up to the requirements of Google and the GDPR.
Here's how the Speedtest app explains the permissions it requires:
This appears to comply with the recommended best practices on requesting permissions from Google, particularly the highlighted sections:
Explaining the reason that permission is required in each case also satisfies the GDPR's requirement that consent is "informed."
The Speedtest app then makes a request to share anonymized data with third parties:
Anonymized data technically falls outside of the GDPR. However, there is no reason not to ask for consent for this act of processing. This also satisfies the requirement GDPR's that consent is "specific."
Here's how the Speedtest app requests consent for ads:
The user has a choice:
This fulfills Google's requirement to obtain consent for both personalized and non-personalized ads.
However, it is questionable whether this meets GDPR's requirement that consent is "freely given." Here, the refusal of consent requires the user to pay money or uninstall the app.
Here's how the Speedtest app allows the user to withdraw consent for personalized ads and network scanning:
Clicking on "remove ads" reveals this screen:
Consent must be "easy to withdraw." Article 7 of the GDPR says that "it shall be as easy to withdraw as to give consent." When it comes to personalized ads, this mechanism certainly seems to fulfill this requirement.
We've looked at how you can implement three core parts of the GDPR into your mobile app.