GDPR in native Apps — Guide through legal requirements and technical challenges
For sure you will remember the first time when you opened a web page back in 2020, and you were greeted with a big consent management layer aka switch hell to make your choice whom to provide your data for what, when using the service.
Since the GDPR was put into place 2018 to protect the unify data protection for individuals within the EU, you can see this layer on all websites, ensuring user’s legal rights for privacy.
Meanwhile there are straight-forward solutions, so called Consent Management Platforms (CMP), to be applied on web pages, the application of GDPR in native apps is a different animal.
In this article, you will read about the different approaches you need to consider to conform to GDPR law, depending on the implementation of your app and the SDKs or services you have integrated in your iOS or Android app.
But before jumping into the native app details, some hints about the GDPR.
If you prefer to bypass the legal details (much like many of us skip the CMP layer by clicking the “For god’s sake: TRACK ME!” button in annoyance), feel free to skip the next chapter and proceed directly to the practical implementation hints!
General Data Protection Regulation
DSGVO (Datenschutz-Grundverordnung) is the German abbreviation for GDPR (General Data Protection Regulation), which is a comprehensive data protection regulation implemented by the European Union (EU) to strengthen and unify data protection for individuals within the EU and the European Economic Area (EEA).
The GDPR came into effect on May 25, 2018, replacing the Data Protection Directive 95/46/EC. Additionally you should familiarize yourself with Directive eprivacy 2002/58/EG, that in combination enforces the displayment of the CMP layer.
Thanks for hint about 2002/58/EG, Matthias!
Here is a summary of key aspects of the DSGVO/GDPR:
- Scope and Territorial Application
— The GDPR applies to the processing of personal data of individuals within the EU and EEA, regardless of where the data processing takes place.
— It also applies to organizations outside the EU/EEA that offer goods or services to, or monitor the behavior of, individuals within the EU/EEA. - Data Subject Rights
— Individuals (data subjects) have various rights, including the right to access, rectification, erasure, data portability, and the right to object to processing.
— Consent for data processing must be freely given, specific, informed, and unambiguous. - Lawful Basis for Processing
— Data processing must have a lawful basis, such as consent, contractual necessity, legal obligation, vital interests, public task, or legitimate interests pursued by the data controller or a third party. - Data Protection Officer (DPO)
— Some organizations are required to appoint a Data Protection Officer to ensure compliance with the GDPR. - Data Breach Notification
— Organizations must notify the relevant supervisory authority of a data breach within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to individuals’ rights and freedoms. - Privacy by Design and Default
— Data protection considerations should be integrated into the design and implementation of systems and processes from the outset (Privacy by Design), and only necessary personal data should be processed (Privacy by Default). - Data Transfers
— Transfers of personal data to countries outside the EU/EEA are subject to restrictions unless the receiving country ensures an adequate level of data protection. - Sanctions and Fines
— The GDPR empowers supervisory authorities to impose fines for non-compliance, with penalties that can be substantial. - Accountability
— Data controllers are responsible for demonstrating compliance with the GDPR and must keep records of their processing activities - Supervisory Authorities
— Each EU member state has one or more supervisory authorities responsible for enforcing the GDPR.
It’s important for organizations to understand and comply with the GDPR to protect individuals’ privacy and avoid potential legal consequences.
Legal disclaimer
The following information is neither guaranteed to be neither 100% complete nor 100% legally safe — but you will find best practices what to pay attention to, when you are trying to make your app GDPR-compliant.
Practical implementation in iOS and Android Apps
Alright, after reading and understanding that — or after months of discussions with your local legal consultant — how can you practically ensure that your native app implementation complies with the requirements of the GDPR?
In difference to the web you can access 3rd party vendor services from within in a native app in many different manners.
- Vendor provides a Transparency & Consent Framework (TCF) compliant SDK and ensures it listens to the consent signal from the integrated CMP.
- A custom vendor offers a custom implementation to be explicitly called after consent is given.
- A service that itself attaches various 3rd party services (e.g. Tag Manager) and requires information about consent for different sub-vendors.
- A web page is displayed within the app inside a WebView.
- A web page is shown within an integrated In-App Browser.
Already feeling a bit apprehensive about reading on? You probably should be!
But let’s start with the easy ones…
TCF Compliant Vendor and In-App Browser
When collaborating with TCF-compliant vendors, integrating your CMP solution should generally put you in a secure position, as the vendor is expected to respond to the CMP signal. The CMP typically triggers the CMP layer as necessary, such as during the initial launch or a change of vendors, and ensures that consent is written to a local file:
- Android: Shared Preferences
- iOS: User Defaults
The TCF-compliant vendor then reads this file and adheres to the indications provided regarding user consent. This process helps in maintaining compliance with privacy regulations.
A little real-life hint: Don’t trust any 3rd party provider!
Even if they think they are TCF-compliant, you should check all outgoing connection with a proxy (e.g. Charles or Proxyman)!
When utilizing an In-App Browser that is distinctly separated from the app (e.g., SFSafariViewController), you should generally be in a secure position. However, it could be beneficial to display a brief notice to the user before opening the In-App Browser for added transparency.
Next level: Service with sub-vendors
When employing services with sub-vendors, such as Tag Manager, you may need to undertake additional steps. Essentially, you should transmit the consent status of each sub-vendor to the main service. This allows the main service to make the decision on enabling or disabling each sub-service separately, based on its specific consent status.
Oembeds in WebViews
According to GDPR, it is not advisable to load third-party web pages directly in a WebView within your app.
Instead, prior to doing so, it is recommended to check and request user consent. You can identify the vendor of the app page by its URL and verify the CMP consent for this specific vendor. If consent has been granted, you can proceed to display the web page.
If no consent was given or consent was not set yet, you could either show a fallback hint or, even more user-friendly, present a server-generated screenshot of the web page. This screenshot can provide users with an idea of what to expect once consent is given.
End boss: Custom vendors
As the earlier integrations were relatively straightforward, the true challenge arises when dealing with custom vendors.
- Initially, engage in a conversation with the vendor and thoroughly review their documentation.
- Pay particular attention to the initialization code: certain vendors should not be initiated without consent and should be disabled by default.
- Whether you’ve followed their documentation or refrained from initializing the third-party SDK, it’s essential to double-check using a proxy to ensure that no unexpected requests are being triggered!
Are We There Yet?!
Ok, an amazing lot of work lies behind us, covering the different cases. Are we done now?!
Well almost…
App Tracking Transparency (ATT)
Hopefully your selected CMP solution integrates Apple’s ATT correctly. Otherwise you need to make sure to integrate the ATT according to Apple’s guidelines or you won’t pass the App Review, besides being legally GDPR-compliant!
Duplicate CMP-Layer
Hey, didn’t I just give my consent?!
Even if user gave consent to your services, the user might still see an additional consent layer in WebViews, even if you display a theoretically already consented service.
Origin of the second CMP-layer trigger will then be the web page CMP-layer being shown, because it has no reference about the consent give in the native app.
Maybe future TCF standard will include a possibility about how to pass consent given in native apps to a web page running in a WebView…
Privacy compliance monitoring
Once the CMP has been successfully implemented, ongoing compliance monitoring is essential to ensure long-term compliance and minimize the risk of violations. You also have to take in consideration, that you don’t have everything under control, that you are displaying inside your app. Just think about Advertisements beeing displayed in a WebView, that might fire their own requests…
Since such monitoring is very resource-intensive, a technical and automated solution is definitely recommended. Tools like Privacy Watch automatically scan apps and websites for GDPR violations and will let you know in case vendors are tracking your users without consent.
If you would like to hear more about it, please contact our Privacy Products unit privacy-watch@axelspringer.com for a demo.
Final words
Achieving GDPR compliance for native apps is a complex task. While the information presented encompasses many best practices and draws from real-world experience, it’s important to note that the provided information is not guaranteed to be 100% comprehensive or legally secure. Therefore, seeking legal advice is recommended to ensure full compliance and be on the safe side.
May the GDPR be with you, my friend!
