Do mobile apps use cookies?
Generally speaking, the answer is no. The usage of cookies is generally restricted to browser-based activities on mobile phones. Mobile apps, however, may use technologies that require consent from the users before activation. These technologies are so-called 3rd party SDKs (Software Development Kit) that watch, track, analyse and send information to 3rd party servers.
Our Mobile Solution allows our clients to ask for consent and enable only those services that the end-user agreed to.
My app is behind a log-in, do I still need the consent pop-up?
If you track or transfer private data to third parties then we would highly recommend that you have a consent pop-up implemented.
How long does it take to set up our product?
We believe that it should take less than one day to implement the MCS depending on the individual setup.
Do we support Android or Apple TV?
We currently do not support any TV platforms.
Is the SDK compatible with React Native apps?
Both Android and iOS SDKs are compatible with React Native. We do not, however, provide a React native wrapper, it is up to the customer to create one. If there is a demand for it, we can consider making our own React Native wrapper in the future.
Is the SDK compatible with Flutter and Xamarin apps?
Both Android and iOS SDKs are compatible with Flutter and Xamarin. We do not, however, provide a wrapper, it is up to the customer to create one. Should there be a demand for it, we can consider making our own Flutter and/or Xamarin wrapper.
What is the minimum iOS/Android version supported by the SDK?
iOS 11+
Android v6+
Does the SDK support offline mode?
Currently, offline mode is not supported. We will be able to consider this in future as a feature of the Mobile Consent Solution.
Can I change the text in the consent solution without re-releasing the app?
All texts are provided by the platform and can be changed at any time without redeploying the app. If you want to update the SDK in your apps that will, however, require re-deployment.
How can I see that a mobile app's CMP is blocking trackers correctly?
Unlike webpages, mobile apps don't load their source code from a server, they are instead installed on a mobile device's internal storage in a so-called binary package. In layman's terms, the original source code was converted by a program called a compiler into machine language (the famous ones and zeros).
This also means that there is no need for a browser or any other program to show these apps - they are self-contained and have everything they need to run inside their package. Both Apple and Google are committed to privacy and app security, and therefore don't allow any other app to access the data that was saved by a different app. On a vanilla device with an app downloaded from AppStore or PlayStore you won't be able to check if the trackers are being blocked or not.
To verify the CMPs blocking function you need to prepare a little more elaborate setup with the following components:
A mobile device (do not use your personal phone, as some settings will compromise the security of the phone)
A computer running a debugging proxy server (Proxyman or CharlesProxy or Fiddler are popular choices)
Self-signed root certificate installed and trusted on the target device (proxy servers usually explain how to do it)
The target device needs to be on the same network as the computer and in the network settings the proxy address needs to point to the computers ip/hostname
After verifying that the target device is tunnelling data through the proxy, you need to start the app that is being tested, and without consenting to anything but necessary use the app for a few seconds and observe if any of the outgoing traffic contains web addresses that are suspicious. If you find suspicious addresses, it is possible to enable so-called "SSL" proxying that enables the intermediary (the proxy server) to swap the SSL certificate of each request on the fly and use its own certificate which allows us to read the contents of network calls that would otherwise be encrypted (HTTPS).
Do I need the Mobile Consent Solution SDK in my iOS app if I already use the App Transparency Framework?
You must use the App Tracking Transparency framework (ATT) if your app collects data about end users and shares it with other companies for purposes of tracking across apps and websites. The App Tracking Transparency framework presents an app-tracking authorization request to the user and provides the tracking authorization status.
The ATT, however, only covers one part of the equation and does not make you GDPR compliant. The ATT and MCS go hand in hand together to cover you both legally (MCS - GDPR) and technically (ATT - Apple's requirement, not a legal one).
By not allowing cross-app tracking in ATT, iOS won't allow you to use the device’s advertising identifier. This is a unique ID that can be used to collect user behaviour across apps even if the user is not logged in. It is primarily used by advertisers to profile users and deliver personalised ads.
Since both ATT and MCS are invoked by the developer, it is in their hand to handle the flow correctly, such as:
Present the MCS to the user first.
Only if they agree to the analytics or marketing categories* can you invoke the ATT dialogue. The ATT requires that the developer sets the NSUserTrackingUsageDescription key in the apps Info.plist otherwise invoking it will make the app crash and will be rejected from the App Store.
Notes:
It might be confusing how and which framework to use, so here's a little cheat sheet:
Case 1: User consents to tracking in MCS -> invoke ATT dialogue -> user agrees to cross-app tracking -> track all you want
Case 2: User consents to tracking in MCS -> invoke ATT dialogue -> user does not agree to cross-app tracking -> you can track, but you cannot use the device’s advertising identifier.
Case 3: User does not consent to tracking in MCS -> you cannot invoke ATT and cannot track any personally identifiable data (the system will still share crash reports with the developer if the user allowed it during the iPhone onboarding)