Webpage Cookies series part 1: Basics

When starting with our own webpage we have been struggling with a question: how should we do so in a compliant manner, and in particular with regards to cookies, while at the same time being a small company that wants to be:

• Privacy-friendly
• User-friendly (and yes that might be a paradox with the one above)
• Compliant
• Aware of what users want from its webpage

That by itself have proven a challenge. We were not and are not interested in advertising cookies (even if I personally can imagine advertising a leather-bound edition of GDPR), but we would like to integrate with basic plug-ins used (LinkedIn, Google Maps, Google Analytics all come to mind), that of course comes next to purely functional cookies that we will be dropping on your computer anyways.

Unsurprisingly, we have advised on implementation of cookies as part of large webpage projects that are filled with advertising, we also negotiated (for both sides) the contracts that would include integration of cookies or pixels. We have helped with wording and tag manager setup. Yet here as a small company we simply were in a take it or leave it place. If we want a LinkedIn plugin we should just implement it, and surely we are not joining IAB EU to do so? Yet the plugin providers do not clearly state what relationship the parties are or what the websites they deploy cookies on are required to do (particularly I appreciate statement of the plugin owners “you should ensure appropriate legal basis”).

We are teaming up with passionate cookie heavy weights: Signatu to explore the ins and outs of cookies.

We will kick off with some basics: The Beauty and the Beast of cookie consent, on what cookies and what are their good and bad sides.

Basics

European legislation and judgments by the European Court of Justice impose a duty on websites:
• to inform end users about their use of webpage 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, websites directed to European residents have implemented cookie consent notices.

For websites and end users, cookie consent notices represent both the beauty and the beast.

What’s a webpage 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?

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 webpage 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 webpage 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.

Beauty-beast for end users

Beauty

Cookie consent notices enable 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. This realizes the idea of control that user should have over their information and their devices.

This is true only if done lawfully, when cookies are set and scripts are loaded only after end users consent to the cookie consent notice.

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.

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 webpage cookies.

What’s the solution?

• No cookies?
• Surely not.

Many website functionalities are built with and facilitated by cookies and similar technologies, including from 3rd parties.

• Not inform and not ask for consent?
• Surely not.

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?

Let’s explore those elements in the next post in the series!