5

I'm trying to figure out the best way to gather user consent to use third-party services in a mobile app for users under the GDPR. Let's say that I have an app that uses third party services (analytics, ads...) which collects personal identifiable information.

In the first app launch a dialog would be presented to the user:

This app uses tracking identifiers

We use tracking identifiers to collect information about how you interact with our app. We use this information in order to improve your experience, for analytics purposes and advertising. You can find out more about our use of cookies in our Privacy Policy and change your preferences below.

BUTTON: Accept

BUTTON: Change preferences

I offer a link to my Privacy Policy here.

If the user accepts, everything is set up normally.

If the user clicks on the change preferences button, it is directed to a privacy preferences screen:

Preferences screen

I don't have the exact texts, but here I would basically present a list of each third party service I work with, their privacy policy, how do they use the user's data, and a checkbox to enable/disable the data collection

For the ads, here I state that if the user does not consent, the app will continue to show ads but no personalization will be done on them.

The app would also allow the user to change their preferences at any time in the future.


My questions regarding this implementation are:

  1. Is this overall approach correct, and fully compliant with the law?
  2. 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) ?
4
  • 14
    We are about to find out. The activists from noyb.eu have launched lawsuits against websites that use this precise method, since they argue that denying consent must not be more difficult than giving it. noyb.eu/en/…
    – user9838
    Aug 22, 2021 at 16:03
  • There is a related discussion on r/gdpr.
    – amon
    Aug 22, 2021 at 17:19
  • What happened is that when GDPR first dropped, websites had anything between long long lists of pre checked boxes you could only uncheck one at a time up to a nice "no to everything" button on the initial popup. Once the fines started, they had to cut it out so for a while it was bearable. Now it is back to the same but under "legitimate" interest - some let you just click away by default, others have you "object" every single line, while the "generic" stuff is now all opt in. so I am hoping this second wave of hand slapping will accomplish something Aug 23, 2021 at 13:59
  • Instead of asking yourself if it's valid by law, ask yourself if it is conventient and safe for the customer. GDPR is user centric. Don't circumvent that. Considering that, your approach is bad. Give the option to "deny" without extra steps.
    – Daniel W.
    Aug 23, 2021 at 16:57

1 Answer 1

11

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.

4
  • Thank you very much for your detailed response, I would like to ask you a few things if you don't mind: - I have more than 2 third parties on my behalf, that's why I wanted a 1st layer as a summary, if I do that, and if I add a 'reject all' button, it is ok to then add the 'accept all' button? - I work with some third parties that are crucial to my business, it is OK if I force the user to accept their data processing? - How can I store the consent done if I can't identify the user? My third parties uses PII but I don't do it.
    – svprdga
    Aug 22, 2021 at 20:37
  • 6
    @svprdga "Crucial to your business" in terms of "they pay me money for customer data", or "Crucial to your business" in terms of "their APIs need to receive certain data as part of the core functioning of my App's primary purpose, otherwise it's just a waste of storage space"? GDPR treats those two things very differently. Aug 23, 2021 at 0:41
  • @Chronocidal, I work with a third party that helps me to process payments in my app. When a customer wants to purchase something, they help me to retrieve the price, and other things. It could be done in other ways, but I choose them to help me with that subject, so, crucial in that sense.
    – svprdga
    Aug 23, 2021 at 7:30
  • 2
    @svprdga It sounds like a payment processor would be necessary for fulfilling your contract with the user. Then Art 6(1)(b) would be an appropriate legal basis, not Art 6(1)(a) consent. GDPR doesn't require you to obtain consent for everything. First determine your purposes of processing, then select an appropriate legal basis for each purpose. Consent is often the legal basis of last resort.
    – amon
    Aug 23, 2021 at 8:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .