We are teaming up with passionate White Label Consultancy to explore the ins and outs of cookies.
1. Basics
European legislation and judgments by the European Court of Justice impose a duty on websites:
- to inform end users about their use of cookies or similar technologies (hereafter “cookies”), and
- to request and receive end users’ active consent prior to setting cookies on end users’ devices.
The reasoning being that if an end terminal (read computer, mobile device) should store a cookie the user must be made aware of that fact and should be able to make an informed choice in the matter.
Hence, many websites have implemented cookie consent notices.
For websites and end users, cookie consent notices represent both the beauty and the beast.
2. What’s a cookie? What’s the function of a cookie?
Before we go on, here’s an explanation of What’s a cookie? and What’s the function of a cookie? and Can a website control requests? and Must websites make their cookies’ intended use explicit?
HTTP information, cookies and personal data
All HTTP communications contain IP addresses and browser strings, which in most cases are considered as personal data.
That means that all web page views (HTTP requests and responses) transmit personal data.
On A's first-time visit to B's website, A's browser sends a HTTP request to B's server, and B's server sends a HTTP response to A's browser together with a cookie. The cookie has a key=value pair along with a number of attributes which do not in themselves contain personal data. However, if A can be singled out directly or indirectly by connecting the cookie with A's IP address and browser string, then also the cookie can be considered as personal data.
If A re-visits B's website, then A's browser will also send the cookie that B previously sent to and set in A's browser (if the cookie has not expired) to B's server. If that cookie has stored A's personal information, e.g. A's preferences, or if the cookie value is combined with other identifiers specific to A, then that cookie use can be considered as personal data.
What are first-party and third-party cookies?
When A re-visits website B, cookies may be present for 1) website B (“first-party cookies”) and 2) other domains (“third-party cookies”). The same cookie can be either “first-party” or “third-party” depending on which site A currently visits.
What are same site and cross site requests?
If A requests to see website C, and website C uses content (code samples, maps, blog posts, videos) directly from website B, then A's request to see website C will also trigger a request to website B and attach and send the associated cookies along with the cross-site request.
(“Site” is the combination of the domain suffix and the part of the domain just before it.)
When does a website want to send cookies in a third-party context?
Website C may not only want to use iFrames to show to A content delivered directly from website B, but also use other functionalities such as payments, social buttons, measure website traffic etc.
Also, on a website, third parties can load remote resources, such as tags and pixels that trace A's activities or personalise content to A. Such remote resources can rely on cookies to be sent with a request.
Can a website control requests?
If website C does not validate requests from A, then website B could trigger unwanted actions on website C and track A's activities on website C.
With the SameSite attribute (defined in RFC6265 available at https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00), a website can allow its website server to assert that a cookie ought not to be sent along with cross-site requests.
The SameSite attribute provides three different ways for websites to control requests:
- SameSite Strict: By default, SameSite Strict does not send cookies if the site for the cookie does not match the site currently shown in the browser's URL bar.
- SameSite Lax: An exception to SameSite Strict is SameSite Lax that allows to send same-site cookies along with cross-site requests only if they are top-level navigations which use a "safe" (in the [RFC7231 available here) HTTP method.
- SameSite None: A website can specify SameSite to no values to clearly express that the intention is to send cookies in a third-party context. If a website has embedded third party content, advertising, sign-in across multiple sites etc then SameSite None would express the intention to send cookies in a third-party context.
IETF proposal SameSite
The IETF proposal, Incrementally Better Cookies (available at: https://tools.ietf.org/html/draft-west-cookie-incrementalism-00) proposes two changes to cookies:
- Cookies should be treated as "SameSite=Lax" by default.
- Cookies that explicitly assert "SameSite=None" in order to enable cross-site delivery should also be marked as "Secure".
Should/must websites make their cookies’ intended use explicit?
Yes!
Why? Because:
- several browsers (Chrome, Firefox, Edge) have announced that they will implement the IETF proposal to be their default behaviour.
- cookie notices then can make cookies’ intended use explicit in the notice.
This means that:
- the browser per default will restrict cookies to first party contexts except if the cookies have a SameSite attribute.
- cookies for cross-site usage will not enable to send cookies in a third-party context except if the cookies specify SameSite=None; Secure.
NB! Some browser versions are known to be incompatible with the `SameSite=None` attribute. Have a look here.
Cookie Audit and Update cookies
Websites need to:
- audit where they set and use cookies for same-site and cross-site use.
- understand in which situations SameSite Strict or SameSite Lax or SameSite None is a good choice.
- transition to Strict, Lax and None.
- make their cookies’ intended use explicit as required by the IETF proposal and as required by the ePrivacy Directive and the GDPR.
With Signatu’s Trackerdetect, you can audit your website for cookies, remote resources and javascript.
3. Beauty-beast for end users
Beauty
If done lawfully, cookies are set and scripts are loaded only after end users consent to the cookie consent notice.
This enables end users to control whether a cookie will store information on or collect information from cookies already stored on their devices, including possible subsequent cookie id matching, use of their personal data etc.
Beast
Cookie consent notices interrupt end users’ initial interaction with websites, invade end users’ field of vision, distract end users’ focus to interact with website content, demand attention and are often difficult to understand.
Hence, cookie consent notices often motivate end users to not interact with the cookie consent notice or choose to click accept or refuse to remove the interrupting notice without making an informed choice.
4. Beauty-beast for websites
Beauty
If cookies are set and scripts are loaded only after end users consent to the cookie consent notice, websites clearly signal that they are honest and respect end users’ choices.
This might enable websites to earn end users’ trust.
Also, if the cookie consent notice is understandable and consent is requested at the right place and time for purposes and functionalities that benefit end users, websites are likely to increase end users’ consent rates.
Beast
Cookie consent notices are often poorly designed and difficult to provide at times relevant for end users.
Poor cookie consent notice design and timing can lead to low end user consent rates/high end user consent refusal rates and/or high end user consent withdrawal rates.
In turn, such consent (refusal) rates will disadvantage websites in relation to the technical and commercial benefits of using cookies.
5. What’s the beauty-beast solution?
No cookies?
No, surely not. Many website functionalities are built with and facilitated by cookies and similar technologies, including from 3rd parties.
Not inform and ask for consent?
No, surely not.
Design of notice?
Yes, partly.
Position of notice?
Yes, partly.
Understandable content?
Yes, partly.
Timing for provision of notice?
Yes, partly.
Context for provision of notice?
Yes, partly.
Other solutions?
Yes, definitely!
In order to create cookie consent notices that are usable for end users as well as websites, we will ask and answer: What motivates end users to (not) interact with cookie consent notices? What influences end users’ interaction with cookie consent notices?
Cookie consent notices, part 2, will soon be published.