How to properly ask for consent is an evolving issue. Your general consent flow is very common, but I don't think it's entirely compliant.
Legal background on consent
Consent is one of the Art 6 GDPR legal bases for processing. The ePrivacy directive (ePD) also mandates consent for accessing information on a user's device, where such access is not strictly necessary for a service explicitly requested by the user. For example, this means that analytics cookies require consent.
Consent is defined in Art 4(11) as:
any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her
Further conditions for consent are given in Art 7, such as that “It shall be as easy to withdraw as to give consent”.
The EDPB guidelines 05/2020 on consent provide extensive interpretation of the GDPR that should be considered as effectively binding.
First layer: accept / change preferences
The first consent layer provides general information about the purposes that consent is being sought for. This seems to be mostly compliant, but I have some doubts.
Consent must be freely given, and withdrawing consent must be as easy as giving it. I would therefore recommend having a “continue without consenting” option that is given roughly equal prominence to the alternatives.
Consent must be informed. Even in the first layer, you must give basic information. In the EDPB guidelines, the following items are identified:
- controller's identity
- purposes of processing
- what type of data will be collected
- existence of the right to withdraw consent
- if relevant: that the data will be used for profiling/automated decision making
- if relevant: possible risks if international data transfers are made under Art 49(1)(a)
I think this makes it difficult to collected an “agree to all” style consent that covers all purposes. It would be better to clearly distinguish between the analytics and advertising purposes even in your first layer.
Consent must be specific to a purpose. You try to make this possible via a second layer where granular choices can be made. This isn't entirely bad, since you also need to make the consent flow simple enough as to avoid click fatigue. But since you only have two processing purposes, it would be better to show them separately on the first layer.
You cannot generally make access to the app conditional on unrelated consent. The statement “This app uses tracking identifiers” suggests that there is no choice. It would be better to make it clear that the user can voluntarily consent to such processing.
Together, this would mean that a design like the following could be more compliant. Text in [brackets] indicates buttons or links.
Your privacy choices
To support and improve this app, you can choose to give us access for the following purposes:
Analytics: understanding how you use this app
We would like to collect information on how you interact with the app, and store cookies on your device for this purpose.
[more information] [decline / agree]
More relevant advertising
We will always show ads, but if you want we can build an interest profile to show you more relevant ads.
[more information] [decline / agree]
You can always change your choices in the app settings, but past use of your data remains legal after withdrawing consent.
ExampleApp is provided by ExampleDeveloper Ltd. [full privacy notice]
[continue]
Second layer: detailed information about all services
Your second layer sounds good, as it provides granular controls and more detailed information. As already mentioned, I would move some of this to the first layer.
But one of your questions pertains to the defaults on this screen:
It is OK if I set all of the options to enabled the first time that the user goes to the preference screen (enabled by default) ?
No, this is not OK. Consent means opt-in, and requires an affirmative action by the user. You cannot have pre-checked checkboxes. The default is that no consent was given. If you have an “enable all” button, I would also expect a “disable all” button. Else, consent might not have been given freely.
You also cannot rely on the consent until consent has been actually given. So you must not start collecting analytics in the background while the user is still on the consent choice screen. In addition to being non-compliant by itself, loading pre-ticked checkboxes increases the risk that your application accidentally considers the consent as already being given, which could easily lead to illegal processing if there's a bug in your app.
You might have processing purposes that are based on a legitimate interest instead of consent. These can be enabled by default, but you generally have to make it possible for the user to object.
Your relationship with third parties
When using third party services, it is crucial to understand if they are a processor who is contractually bound to only use the data on your behalf, or a separate processor.
You must disclose processors (or at least categories of processors) in your privacy notice, but not really during the consent flow. The GDPR does not distinguishing between doing processing activities yourself versus outsourcing them to a processor. In both cases, you are the controller, and only you are asking for consent. Thus, it's also superfluous to show third party privacy notices. It's your obligation as the controller to provide all necessary information.
If you are collecting consent for other controllers with whom you have joint processing activities, you must make this much more prominently. You would have to disclose in the first layer that you are sharing the data with other controllers who can use the data for their own purposes. This sharing is part of the processing purpose.
This is quite tricky to do correctly when it comes to ad networks, since ad networks generally won't be your data processor and can have many intransparent members.
Demonstrating consent
As the data controller, it is your obligation to be able to demonstrate that valid consent has been given. This implies process-level obligations such as being able to show that your consent flow is non-coercive and makes it possible to decline consent. This also implies individual-level obligations such as being able to show when a given user has given or withdrawn consent for which purpose. If you have a backend anyway, it could be sensible to store information there about consent/withdraw events. When the user returns to the consent management screen through the app settings, you could show a timestamp like “you consented to this purpose on 2021-08-22 17:14:23”. I have recently written a more detailed discussion about demonstrating consent.
