Make WordPress Core

Opened 2 months ago

Last modified 7 weeks ago

#59445 new defect (bug)

Emoji Caching could violate GDPR / CCPA

Reported by: antmg's profile antmg Owned by:
Milestone: 6.5 Priority: normal
Severity: major Version: 6.3
Component: Emoji Keywords: close
Focuses: performance, privacy Cc:

Description

This enhancement:

https://core.trac.wordpress.org/changeset/56074

Has resulted in WordPress, by default, writing to session storage on page load, without the viewer's consent, this is a compliance issue for GDPR (Europe) / CCPA (USA) as consent has to be obtained before storing data on an end user's device (cookies, local storage, session storage and anything similar).

As a compliance issue this could result in fines for those using WordPress in live sites.

Attachments (1)

cookies-gdpr.png (121.3 KB) - added by antmg 2 months ago.
GDPR Assessment diagram

Download all attachments as: .zip

Change History (23)

This ticket was mentioned in Slack in #core-performance by peterwilsoncc. View the logs.


2 months ago

#2 @swissspidy
2 months ago

IANAL, but AFAIK essential cookies exempt from the requirement of consent. Things are definitely more nuanced.

#3 @peterwilsoncc
2 months ago

  • Focuses performance added
  • Milestone changed from Awaiting Review to 6.4

I've moved this to the 6.4 milestone for visibility although it may need to be backported to the 6.3 branch if it is a problem. I've added the performance focus as it's a follow up to #58472.

I'm aware the laws mentioned in the ticket are quite strict but am not a lawyer so can't provide any guidance

#4 in reply to: ↑ description @westonruter
2 months ago

  • Version changed from 6.3.1 to 6.3

Replying to antmg:

Has resulted in WordPress, by default, writing to session storage on page load, without the viewer's consent, this is a compliance issue for GDPR (Europe) / CCPA (USA) as consent has to be obtained before storing data on an end user's device (cookies, local storage, session storage and anything similar).

For reference, the ticket this was introduced in is #58472.

The use of sessionStorage in the emoji loader here is purely as a cache. It's to avoid re-computing expensive checks for whether a set of emoji are supported by the user's platform. So I understand it to be similar to a regular browser cache. Browser caching clearly can't be a violation of GDPR, as otherwise every single resource would have to be sent with Cache-Control: no-cache, no-store. If the concern is that sessionStorage would leak that a user had been to the site before, this can also be determined by whether page resources were cached. So I don't see what the issue is here. It does seem to fall into the realm of "essential".

I am also not a lawyer.

#5 @westonruter
2 months ago

  • Summary changed from Emoji Caching violates GDPR / CCPA to Emoji Caching could violate GDPR / CCPA

#6 @antmg
2 months ago

  • Summary changed from Emoji Caching could violate GDPR / CCPA to Emoji Caching violates GDPR / CCPA

Update: Sorry I don't know how I changed the title back whilst replying - ah, I think it's because my properties in the form were there before the title change that happened whilst I was writing

Being a cache by definition means it's not strictly necessary data, it can be recreated trivially if deleted and therefore is not required for the functionality of a site (So cannot come under the strictly necessary exception). Such storage can be used for cache, but after consent.

Here's a link and excerpt from the UK's PECR ( our split from the EU ) page covering the essential use exception:

https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guide-to-pecr/cookies-and-similar-technologies/#exemptions

There are two exemptions which apply where:

  • the cookie is for the sole purpose of carrying out the transmission of a communication over an electronic communications network; or
  • the cookie is strictly necessary to provide an ‘information society service’ (eg a service over the internet) requested by the subscriber or user. Note that it must be essential to fulfil their request – cookies that are helpful or convenient but not essential, or that are only essential for your own purposes, will still require consent.

Based upon the second exception - this stored data is not essential / strictly necessary for the functionality, but helpful / convenient as it saves some compute time, but functionality would be otherwise entirely possible without the data in session storage.

GDPR Version can be found here:

https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf ()

the cookie is “strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service”.

Similar to the PECR

Concerning browser cache being similar to session storage, The biggest difference is a site can read / update the previously written local storage on subsequent visits, whereas you can't read the browser cache on demand as a web app so it's not really a viable storage mechanism, and its much lower potential for abuse means its not a "cookie or similar technology" in terms of compliance.

Last edited 2 months ago by antmg (previous) (diff)

#7 @JavierCasares
2 months ago

I checked the code diagonally and there is no “information” about anything in the cache, like personal / user information, so shouldn't be a problem to save data in the local storage (with or without consent).

RGPD and other laws are focused on privacy, but not on cache information. If I save a cookie like “a=1”, shouldn't be notified to the user because there is no personal or any kind of information available.

If the data in the cache / cookies is not personal / privacy-concerned / identification, shouldn't be an issue. That's the difference, for example with analytics, but not if I save something like “logged=1” that doesn't need to be informed.

If the cache is the same for everybody, and it's only something, so the website runs better, we can do it.

#8 @antmg
2 months ago

The wording doesn't allow for "reasonable use" without consent, only things that are strictly (absolutely) necessary. it doesn't matter what it's used for if it's not strictly necessary, personal data or not, it's not compliant.

The laws are pretty strict on this, and the potential consequences of non-compliance can be quite steep.

But, take the innocent example of the data in this:
{supportTests: {flag: true, emoji: true}, timestamp: 1695725880392}

This will allow me to identify uniquely visitors to the site with a pretty high precision for a week, unless 2 users managed to build the cache value at the same millisecond.

Useful is not a valid "strictly necessary" reason, nor is improved performance. It doesn't matter that it's not personal data.

if you can delete it and the site works fine, it's absolutely not "strictly necessary" and doesn't come under any valid exception to the consent rules.

Last edited 2 months ago by antmg (previous) (diff)

#9 @JavierCasares
2 months ago

There are 2 things here: Privacy (RGPD and others) and the usual "cookie-law" (so usually the banner-consent).

In this case, the privacy is focused on "direct information" that can easily show who is using the cookie or data (email, name, etc.). In this case, it doesn't apply because "an external hacker" cannot cross information with your internal data (for example, a timestamp doesn't identify a user).

About the consent for the cookies, same. You only need consent for saving information in cookies / data that can track you in any way. In this case, is not the situation because the data is only for the functionality and does not relate to anybody.

Everything saved here is anonymous, it's functionality, does not relate to anybody, and does not track anybody, so there is no problem there.

Plus
https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf

In summary, there are exceptions like:

  • access cookies (like the one WordPress uses to know if there are cookies enabled)
  • auth cookies (you are logged or not)
  • security cookies (hashes, etc.)
  • player / multimedia cookies
  • load balancer cookies (CDN, balancers, servers, but not IP)
  • interface personalization cookies (dark mode, using emojis, etc.)
  • browser and config / plugins cookies (usually device cookies only for that device)

Again, in this case, the law doesn't apply because we are not using the cookies or data "for something wrong" (tracking people, exposing personal data, etc.) so there is no concern using this method.

#10 @antmg
2 months ago

Let's take a look at the PECR (UK):

The rules on cookies are in regulation 6. The basic rule is that you must:

tell people the cookies are there;
explain what the cookies are doing and why; and
get the person’s consent to store a cookie on their device.
As long as you do this the first time you set cookies, you do not have to repeat it every time the same person visits your website. However, bear in mind that devices may be used by different people. If there is likely to be more than one user, you may want to consider repeating this process at suitable intervals.

You may also need to obtain fresh consent if your use of cookies changes over time.

And the exceptions:

There are two exemptions which apply where:

the cookie is for the sole purpose of carrying out the transmission of a communication over an electronic communications network; or
the cookie is strictly necessary to provide an ‘information society service’ (eg a service over the internet) requested by the subscriber or user. Note that it must be essential to fulfil their request – cookies that are helpful or convenient but not essential, or that are only essential for your own purposes, will still require consent.
This means you are unlikely to need consent for:

cookies used to remember the goods a user wishes to buy when they add goods to their online basket or proceed to the checkout on an internet shopping website;
session cookies providing security that is essential to comply with data protection security requirements for an online service the user has requested – eg online banking services; or
load-balancing cookies that ensure the content of your page loads quickly and effectively by distributing the workload across several computers.

Source https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guide-to-pecr/cookies-and-similar-technologies/#compliance
(The UK information commissioner office)

Theres no exception that would cover this use case.

#11 @JavierCasares
2 months ago

And, there is the exception:

https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guide-to-pecr/guidance-on-the-use-of-cookies-and-similar-technologies/what-are-the-rules-on-cookies-and-similar-technologies/#rules10

What activities are likely to meet the ‘strictly necessary’ exemption?

Activities likely to fall within the ‘strictly necessary’ exemption include those that relate to the specific functionality of your service – ie, without them, the user would be unable to undertake certain activities. Cookies that don’t relate to what is strictly necessary would need consent.

Common examples include:

Cookies that help ensure that the content of a page loads quickly and effectively by distributing the workload across numerous computers (this is often referred to as ‘load balancing’ or ‘reverse proxying’)

This is a cache thing, so it's a "communication" thing. This information is used to improve the user-experience and nothing more, so it shouldn't have any problem to be used.

Usually legal people don't fit all the possibilities, but in this case is clear to me. This data is to improve the performance of the communications (and reduce the load) so you don't need the consent.

This conversation relates with this session:
https://make.wordpress.org/summit/2023/09/04/community-summit-discussion-notes-open-source-participation-in-global-legislation/

#12 @JavierCasares
2 months ago

Also, maybe what we need is some hook / filter / action the allows to load/not-load the cookie so plugins can access that and disable the information.

I think this is a plugin-territory thing, and the software should allow disabling the cache.

#13 @antmg
2 months ago

Remembering some data calculated client side that can be recalculated easily client side can not be compared to load balancing (necessary to keep a service live, or more likely to make sure people stay on the same server for the duration of their session for non clustered architectures).

At best it's not clear, at worst many wordpress users are breaking laws unknowingly.

Given the potential issues (potential is used as your interpretation is that it's covered potentially by the exceptions) vs the benefit, this should be off by default, and the user should be able to enable it in the admin pages if they understand what it does and the relevant laws in their countries.

I think the only way to validate for sure would be to point the ICO and EU + USA equivalents at some wordpress.com sites but I don't think that would stop at them finding it non compliant without issuing fines so that's not really an option.

In the face of lack of a lawyer able to interpret all the relevant laws for each and every country I'd assume it's not compliant somewhere as that's the safest option and users having to choose to enable it passes the risk and liability / responsibility on to the individual responsible for that specific instance as it's their admins choice to enable it vs a wordpress project default

Last edited 2 months ago by antmg (previous) (diff)

#14 @jorbin
2 months ago

  • Keywords close added
  • Summary changed from Emoji Caching violates GDPR / CCPA to Emoji Caching could violate GDPR / CCPA

In the face of lack of a lawyer able to interpret all the relevant laws for each and every country, I'd assume that this performance feature doesn't impact user privacy.

I suggest that it is closed as wontfix

@antmg
2 months ago

GDPR Assessment diagram

#15 @antmg
2 months ago

Replying to jorbin:

In the face of lack of a lawyer able to interpret all the relevant laws for each and every country, I'd assume that this performance feature doesn't impact user privacy.

I suggest that it is closed as wontfix

My meaning was if unsure of anything you should take the cautious route especially if the consequences of a misjudgement can be significant. I'm actually trying to help protect WordPress and its users from a (potentially) costly oversight. Perhaps it's an abundance of caution, Safe(r) defaults are simply good practice harm no-one.

I've attached the Information Commisioner's Office flow chart for assessing if you should be getting consent and if you should be protecting the data. Source: https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guide-to-pecr/guidance-on-the-use-of-cookies-and-similar-technologies/how-do-the-cookie-rules-relate-to-the-gdpr/

Following the chart with the answers:-

Are you using cookies or similar technologies: yes (session storage)
Is the cookie STRICTLY necessary for the transmission of the communication - no

We get to consent _IS_ required (plus PECR and Regulation 6 applies)

Following further and answering that there is no personal data involved that chart tells us that we don't need to take any special steps to protect that data / handle it according to the GDPR.

In this case it's not what's stored, it's about getting consent to store _anything_ on the user's machine that's not absolutely necessary for the site to function. (That's covered by the PECR, which applies whether or not personal data is involved)

PECR requirements are separate from, and different to, those of the UK GDPR.
Guidance produced by European data protection authorities on how the
ePrivacy Directive relates to the UK GDPR clarifies that, if consent is required 
under the cookie rules:

"the controller cannot rely on the full range of possible lawful grounds provided 
by article 6 of the UK GDPR".

The simplest way to understand it is that if your cookies require consent
under PECR, then you cannot use one of the alternative lawful bases from
the GDPR to set them. If you’re setting cookies, this is why you need to look
to PECR first and comply with its specific rules, before considering any of the
general rules in the UK GDPR.
It is important to note that cookies may not always be classed as personal data.
However, PECR applies whether or not the storage of or access to information 
on user devices involves processing personal data.

Source for both the above citations: https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guide-to-pecr/guidance-on-the-use-of-cookies-and-similar-technologies/how-do-the-cookie-rules-relate-to-the-gdpr/ (same source as the diagram)

Based on your reply I think I might need to mention that I'm really not trying to pick a fight or be awkward, this really is important, consent is required before doing this, and the consequences of doing it without consent can be huge.

Last edited 2 months ago by antmg (previous) (diff)

#16 follow-up: @samiamnot
2 months ago

Are you using cookies or similar data: yes

@antmg , I am not sure why this would be cookie-like information. Every single user would get the exact same info. There is nothing identifying in it, with no way to track sessions. Does your browser cache static images on a page? Of course. Why would this be different?

#17 in reply to: ↑ 16 @antmg
2 months ago

Replying to samiamnot:

Are you using cookies or similar data: yes

@antmg , I am not sure why this would be cookie-like information. Every single user would get the exact same info. There is nothing identifying in it, with no way to track sessions. Does your browser cache static images on a page? Of course. Why would this be different?

That's a mistake, see the diagram for the correct text - I'll correct it - It was meant to say "Are you using cookies or similar technologies". Which is to say data storing mechanisms on the client side machine (this covers cookies, local storage and session storage), which it is, apologies for the confusion there.

Re the difference, can your website read my browser cache when I view it, or write values to it through JS? That's the real difference. Sites are expected to comply with the PECR when using read/write data storage mechanisms on users machines. When it refers to cookies, it's referring to any read-write store on the visitor's side, and again, it doesn't discriminate between personal data and "cache-like" data (see the last post's last code block - which is a citation from the ICO - the relevant UK governing body).

I'm not vouching for the law's reasonableness, practicality, nor its effectiveness in achieving its goal and its requirements are not in my powers to change, but I can point out it exists and that it is saying we can't use a client side read-write store for anything but _strictly_ necessary values without consent.

Last edited 2 months ago by antmg (previous) (diff)

This ticket was mentioned in Slack in #core-performance by mukeshpanchal27. View the logs.


2 months ago

#19 follow-up: @peterwilsoncc
2 months ago

I've asked for project leadership to check in with a privacy lawyer for guidance. I'll follow up once I hear back and proceed based on the lawyer's recommendation.

#20 in reply to: ↑ 19 @antmg
2 months ago

Replying to peterwilsoncc:

I've asked for project leadership to check in with a privacy lawyer for guidance. I'll follow up once I hear back and proceed based on the lawyer's recommendation.

It's specifically the PECR in the UK not the GDPR, relating to not storing things (in cookie like technologies - Cookies, LocalStorage and SessionStorage) that are not absolutely necessary (or we have consent for). (And since this data can be rebuilt, it cannot be considered necessary)

Apologies for just lumping PECR in with the GDPR - my employer groups it all together when referring to it during design sprints compliance training and cookie audits - I think that led to some crossed wires. One of the other engineers in the department didn't realise to tie some code that touched local storage into the compliance settings (also nothing considered personal / PII) and it was a priority one incident to roll it back out of production. Just to clarify, my employer doesn't and won't be using Wordpress, that's just me, I mention them as that's where this stuff is being drilled into my head - they're very risk averse / aware.

Thanks for looking into it

Last edited 2 months ago by antmg (previous) (diff)

#21 @nicolefurlan
7 weeks ago

@peterwilsoncc do we think that this will be addressed within the 6.4 release cycle? With 6.4 RC1 just over a week away, I'm wondering if this should be moved to Future Release.

#22 @peterwilsoncc
7 weeks ago

  • Milestone changed from 6.4 to 6.5

@nicolefurlan I've bumped it to the 6.5 cycle for now. If the legal folks advise that the recent changes need to be reverted it may be necessary to bring it back on to the milestone.

Note: See TracTickets for help on using tickets.