Cookie Rules Analysis

N.B. This is a constantly updating personal opinion (not a legal opinion) of what all the rules, guides, laws, opinions, guidelines and recommendations add up to. You may have different views and may take a more/less conservative approach in your organisation.

Product Summary

  • Google Analytics – 1) Requires opt-out (Legitimate Interest) if the service is anonymised, or prior consent. 2) Requires prior consent if not anonymised (as per the default).
  • Google AdSense/Ads – 1) Requires prior consent for displaying non-personalised ads (Consent is for the operational aspect of the ad service, such as for fraud prevention and measurement. This is lower risk, so arguably permitted as a condition of using the website), 2) Requires prior consent for displaying personalised/targeted ads.
  • Mixpanel – This is the same as Google Analytics, with Mixpanel acting as a Data Processor for the controller. In reality, Mixpanel is almost always used to collect personal data, which means prior consent would be required.

General Principles and Scope

  • Cookies should not be solely judged on their content, but on the purposes of processing, who is setting them and the privacy risks they carry.
  • Much of the rules on cookies stem from the ePrivacy Directive. Whilst the ePD speaks of “cookies”, according to the WP29, its meaning “applies to all types of information stored or accessed” (WP29 04/2012), and so should include other technologies such as scripts and trackers.
  • Persistent cookie storage is often not expected (i.e. maintaining the data between sessions). Therefore consent is usually required for persistent cookie storage (security cookies may be an exemption to this)
  • Indirect controller set cookies are rarely strictly necessary since they are there to serve the interests of a data controller you didn’t explicitly request, e.g. you visited acme.com and received a facebook.com cookie.

Scenarios Requiring Consent

  • Persistent UI customisation / session content / login – all require consent, e.g. for persistent login a “remember me” checkbox would provide consent.
  • Targeted advertising – uses personal data to target the user.
  • Advertising by an indirect controller – consent is required even if this is anonymous (see specific example of Google Ads) since this is functionality not explicitly requested by the user.
  • Analytics involving personal data – from a direct or indirect controller (i.e. not anonymised)
  • Indirect controller analytics – any analytics would require consent.
  • Mixed Dual use – exemptions to consent requirements only apply when all of the cookie’s functions are exempt. So a dual purpose authentication cookie that keeps a user logged in and also provides targeted advertising would not be eligible for a consent exemption.
  • Social plug-ins – these almost always are dual use, providing a function for the Direct Controller but also for the Indirect Controller, e.g. Facebook, which entails unrequested tracking.

Exemptions to Consent Requirements

Cookies and trackers that don’t need consent:

  • In general – you request the functionality and it’s needed to provide that functionality.
  • User Input cookies – keeping track of the content of a user’s current session, e.g. what they have in their cart or what data they have put into forms.
  • Authentication cookies – keeping you logged into a service for the duration of the session.
  • Security cookies – providing security functions such as brute force login prevention and bot detection for the website requested.
  • Multimedia session cookies – keeping track of a user’s progress within a media player during their session (not persistent across sessions).
  • Load balancing/content delivery cookies – providing optimal delivery of the service to the user.
  • UI customisation session cookies – remembering a user’s choice for how a website should look or behave, e.g. preferred language (not persistent across sessions).
  • Direct controller anonymised analytics – an opt-out could suffice if the privacy risk is low.

1st Party versus 3rd Party

Almost universally cookies have been categorises as either first party or third party, based on the domain of the company that sets them. If you browse to acme.com and acme.com sets the cookie then it is known as a “First Party” cookie. If a cookie is set by a different domain, e.g. acme.co.uk, then this cookie is known as a “Third Party” cookie. (In Chrome you can block third party cookies by browsing to chrome://settings/content/cookies.

Block Third Party Cookies in Chrome

However, the terms first party and third party make little sense for the modern Internet, so I recommend you do not use them. The terms originated from the principle that if a cookie comes from a different domain name then it should be trusted less. But many services legitimately host components on different domains that they manage themselves as a Data Controller or via a Data Processor that they specifically control, e.g. a CDN or analytics provider. So there is nothing odd about acme.com storing some website components on acme.net, or even on acme.cdn.com. In 2012 the WP29 recognised this in its “Opinion 04/2012 on Cookie Consent Exemption” in section 2.3, and took a different approach, following the Data Protection Directive (and now GDPR) use of “third party” to mean an entity that isn’t under the data subject or under direct controller of the controller. This would mean that a first party can actually be any domain that provides cookies for the service you directly requested (i.e. controller and their data processors). So as long as acme.co.uk and acme.cdn.com are the controller or its data processor, they still count as a first party. A third party would therefore be any other data controller (e.g. Facebook with a Facebook pixel) that sets cookies that your direct data controller doesn’t control.

The Alternative Terms

Since we’re all trying to comply with Data Protection and ePrivacy rules here, the WP29/GDPR definitions seem more sensible. But since 99% of the world, including Data Protection regulators such as the ICO, use the term ” third party” in the original sense (based on a different domain name), it’s mightily confusing if we decide them to mean something else. Therefore, my recommendation is to not use the terms first party or third party at all. Instead, I propose the terms “Direct Controller” and “Indirect Controller” cookies, using the same understanding as the WP29 but with different naming.

  • “Direct Controller” – Set by the data controller or on its behalf by a data processor it controls, e.g. acme.com, acme.co.uk, acme.cdn.com
  • “Indirect Controller” – Set by a different data controller representing a service you didn’t request and therefore not under the direct control of the requested data controller, e.g. facebook.com.

Throughout this website I’ll refer to Direct Controller and Indirect Controller cookies, rather than first or third party. And when reading information online, be careful of the first/third party terms and what the author is meaning. Anything super technical or privacy focused might be using the WP29/GDPR meaning.

Detailed Analysis

A deeper dive into this will be released shortly….

Conditionality

As highlighted by WP29 in several Opinions, consent can only be valid if the data subject is able to exercise a real choice, and there is no risk of deception, intimidation, coercion or significant negative consequences (e.g. substantial extra costs) if he/she does not consent. Consent will not be free in cases where there is any element of compulsion, pressure or inability to exercise free will.


WP29 Guidelines on consent under Regulation 2016/679 28/11/2017 section 3.1.1

===========================================
Images in this post have been kindly provided by:

unsplash-logoMark Duffel

Carl Gottlieb

Carl Gottlieb is a Data Protection Officer and his consultancy company Cognition provides a range of Data Protection Services including virtual Data Protection Officers.