Considerations for Obtaining Consent to Your Data Practices

The Global Data Protection Regulation (hereinafter “GDPR”) came into effect in Europe on May 25, 2018.  GDPR governs how personal data associated with end-users may be handled by covered parties.  GDPR contains provisions on how to obtain consent to the data practices of those covered parties from their end users.  Because covered parties can include mobile application developers, including those located in the United States, many mobile application developers took another look at their data practices to determine if they needed to comply with the GDPR.  That inquiry should include the mechanisms by which consent is obtained for data practices, which has been a relatively novel task for many application developers until now.         

This article will not help you figure out whether GDPR applies to your data practices or what, if anything, you must do to change your practices.  Nor will this article help you determine the answers to those questions when the European Union ePrivacy Regulation comes into effect (as it likely will) or California’s Consumer Privacy Act (which will go into effect on January 1, 2020).  This article addresses how mobile application developers and publishers should design mobile applications to obtain consent to their data practices considering these emerging laws respecting data practices. 

Applying U.S. Contract Laws to Consent Mechanisms

Under state contract law, a “clickwrap” is the most reliable mechanism for obtaining consent to your data practices, just as it is for your terms of use.  (For a discussion on "clickwrap" read: https://www.gamasutra.com/blogs/KimberlyCulp/20181011/328349/Game_Design_Considerations_to_Reduce_Litigation_Risk.php)  If you have determined that the various emerging data practice regimes do not apply to your mobile application, then obtaining consent consistent with contract law likely remains an acceptable approach. 

Because it is now rarely the case that a mobile application’s data practices do not implicate European privacy concerns, and because this is an ever-changing legal arena, it is prudent to consider whether you are willing to obtain a more rigorous form of consent, even if you are not currently required to do so.

Emerging E.U. Privacy Laws

GDPR

Under Article 4 of the GDPR, “consent” of the data subject means “any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement of clear affirmative action, signifies agreement to the processing of personal data relating to him or her.” 

In particular, “safeguards should ensure that the data subject knows and the extent to which consent is given.”  For at least this reason, the industry standard mechanism for obtaining consent is an in-app pop-up.  The first notable difference between obtaining consent consistent with the GDPR and U.S. contract law is that reliance on a “browsewrap” is insufficient to obtain consent under the GDPR.

Another practical impact of the GDPR is that mobile applications can no longer rely on an all-purpose consent pop-up (such as, “By clicking ‘I agree’ you consent to our terms of use and privacy policy.”).  Consent to terms of use must be unbundled from the consents required under GDPR. 

Likewise, if there is more than one purpose for obtaining consent under GDPR then the mobile application should provide separate consent opportunities for each purpose for which consent is requested.  This can be done by using separate tick boxes or separate pop-up boxes.  As a result, consent requests are now granular in nature. 

The form of consent “should be provided in an intelligible and easily accessible form, using clear and plain language and it should not contain unfair terms.”  Thus, whatever flow is chosen – tick boxes or separate pop-ups – that consent flow needs to be unambiguous.  Most applications then interpret this to mean that, amongst other things, the consent mechanism cannot rely on pre-ticked boxes.  Although the language used to request consent must be unambiguous, the industry has seen different approaches to the language used – from crisp and colloquial to lengthy and dense.  Regardless, the words used need to be unambiguous regarding what is requested and what is given.  A feature that can help establish that consent was unambiguously given is to present the end-user with an affirmation of consent screen for each type of consent that was given.

For consent to be freely given, the end user must be able to withdraw their given consent.  Many mobile applications are, therefore, notifying users during the consent process that they may withdraw their consent at any time.  Of course, a process must be built into the application to facilitate the withdrawal of consent. 

So that the consent is specific and informed, a mobile application should share a list of the partners who are processing the end-user’s personal data.  Although this is not necessarily required, it would be beneficial for a mobile application that is trying to show that consent was specific if the end-user had a further opportunity to opt-in on a per-partner basis. 

For U.S. mobile application developers and publishers, a thorough analysis of the data practices of the mobile application is required to not only determine if GDPR is at issue but, if it is, to determine if consents are required and, if so, for what purpose(s).

ePrivacy Regulation

As currently drafted, the ePrivacy Regulation will require mobile applications to obtain consent from end-users for data practices that are far broader than what is contemplated by the GDPR (e.g., metadata versus personal data).  However, at present, the mechanism for obtaining consent appears to be the same as under the GDPR.  If this persists, then the practical effect is that end-users will see more tick boxes or more pop-ups before they can reach the content of the application. 

Emerging U.S. Privacy Laws

California Consumer Privacy Act (CCPA)

The California Consumer Privacy Act will go into effect on January 1, 2020.  It has already been amended once and all expectations are that there will be further amendments or clarifications to the law (e.g. via regulation) before CCPA goes into effect.  This, obviously, makes it challenging for a mobile application developer to plan to comply with the CCPA.

Nevertheless, there are some things we know now about the law that are not expected to change with respect to obtaining consent to data practices.  The CCPA appears to favor an “opt-out” approach as opposed to “opt-in” for purposes of consent.  Thus, if you are currently addressing consent under the GDPR standard, you will likely satisfy CCPA as to your consent mechanism.  However, if you have determined that GDPR does not apply to you (and ePrivacy Regulation will not apply to you), then it is likely going to remain sufficient under CCPA to rely on a “clickwrap” for consent.  Of course, since CCPA is an opt-out regime, you will still need to consider the appropriate mechanisms for addressing the right to opt-out.

Reconciling the Regimes

The trend has been to pass laws – here in the U.S. and abroad – that offer end-users more choice and transparency into how their data is used.  This trend will likely lead to more choice and transparency – not less – including during the consent processes.  Thus, even if you are not now (or will not be) covered by any of the afore-mentioned privacy laws, it is prudent to consider how you will give choice and transparency to your end users.