Emoji Caching could violate GDPR / CCPA

[antmg]

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.

[swissspidy]

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

[peterwilsoncc]

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

[westonruter]

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.

[antmg]

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.

[JavierCasares]

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.

[antmg]

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.

[JavierCasares]

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.

[antmg]

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.

[JavierCasares]

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/

[JavierCasares]

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.

[antmg]

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

[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

[antmg]

GDPR Assessment diagram

[antmg]

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.

[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?

[antmg]

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.

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

[antmg]

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

[nicolefurlan]

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

[peterwilsoncc]

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

[peterwilsoncc]

The advice from the project's lawyers is that the emoji detection changes aren't required to be reverted. As such, I am closing this ticket wontfix.

I'm aware this will disappoint some of the people active on this ticket but legal advice needs to take priority in this instance.

If you wish to discuss this issue further, I remind you it can continue on a closed ticket.

[swissspidy]

#60376 was marked as a duplicate.

[jankarres]

@peterwilsoncc Would it be possible for you to share the legal assessment of this case with the community in the interests of transparency, so that it can be understood on the basis of which legal argumentation chain this decision was made? It would be important to know the reasoning behind this decision so that everyone can understand it. I would appreciate this kind of transparency!

[peterwilsoncc]

Replying to jankarres:

@peterwilsoncc Would it be possible for you to share the legal assessment of this case...

In situations like this, that's not how legal advice works. Rather than seeking and receiving a detailed assessment of the question, you seek and receive an answer to the question: is it necessary to revert the commit?

The answer that came back was that it was unnecessary to do so.

[jankarres]

I take it from your answer that the legal advice only asked whether this commit needs to be reverted on the basis of the commit and the discussion of this ticket. The technical explanation and evaluation of the functionality was the responsibility of the legal advisor, without the support of a software developer.

I work in the area of consent management for EU law and, in my experience, the approach described is often not helpful, as there are very few lawyers who have a sufficient IT background to be able to evaluate the case technically themselves, which is essential for a correct legal assessment of the case.

In the following, I would like to present my legal opinion with regard to the scope of application of the EU and EEA, as well as the concrete implementation of the legislation in Germany. This statement is not legal advice, but only a statement of my legal opinion.

Technical evaluation of the process:

The commit https://core.trac.wordpress.org/changeset/56074 extends the function wpEmojiLoader() in the file trunk/src/js/_enqueues/lib/emoji-loader.js, whereby, among other things, the detection of whether Twemoji (library) needs to be loaded is to be improved. Twemoji should only be loaded in if the browser used does not support emojis, which only applies to very old browsers. The function testEmojiSupports() checks whether the browser supports emojis by addressing a functionality of the browser for rendering emojis, which only works if the browser has implemented it.

New in the commit is that after the tests have been executed, the new function setSessionSupportTests() is called, which persistently writes the test results including a UNIX timestamp of the storage time to the session storage object wpEmojiSettingsSupports on the end device.

With a further call, the getSessionSupportTests() function reads out whether test results have already been persistently saved. If these have been saved, it checks whether they are not older than one week. If they are less than a week old, the saved test results are used to decide whether Twemoji should be loaded.

The aim of data processing is to avoid having to perform the check again each time a page is called up within the browser tab (scope of validity of session storage objects) and thus save < 1 ms of website loading time.

Legal evaluation in terms of the relevant legislation in the EU and EEA

GDPR

The subject matter of the GDPR covers, among other things, the automated processing of personal data (Art. 2 GDPR; ​https://gdpr-text.com/read/article-2/).

The test result as to whether the browser used technically supports the rendering of emojis allows a vague conclusion to be drawn about the software used, but not about the concret user, which is why I do not see any personal data reference here. The UNIX timestamp of the writing of the session storage object allows a conclusion to be drawn about when the browser tab of the end device last called up the website if the time is greater than one week and when the test was last executed if the time is less than or equal to one week. A personal reference to this date cannot be established without other essential information such as the website vistors IP address. Consequently, I do not consider this to be personal data within the meaning of the legal requirement.

Consequently, I do not consider the session storage object to be within the scope of the GDPR.

ePrivacy Directive

The Directive 2002/58/EC (​https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32002L0058), amended by Directive 2009/136/EC (often called "ePrivacy Directive"; ​https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32009L0136) is a directive that must be transposed into national law by the respective nation states in order to ensure the protection of privacy in terminal equipment. In Germany, for example, Art. 25 f. TTDSG (​https://dejure.org/gesetze/TTDSG/25.html; in German) has been implemented the directive into national law. In the following, I will refer to the ePrivacy Directive in order to take into account the regulations applicable in the EU and EEA. Implementations such as in the TTDSG in Germany cover the essence of the directive.

Recital 66 of 2009/136/EC explains that the storage or reading of data from terminal equipment (including session storage) requires website visitors to be provided with "clear and comprehensive information when engaging in any activity which could result in such storage or gaining of access". In addition, the website visitor must have the right to refuse this data processing. In judgment C-673/17 (​https://curia.europa.eu/juris/liste.jsf?language=en&num=C-673/17), the ECJ clarifies that an opt-in procedure must be used for this purpose, as sufficient information must first be provided and an informed decision must then be able to be made. "Exceptions to the obligation to provide information and offer the right to refuse should be limited to those situations where the technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user." It is therefore necessary to check whether wpEmojiSettingsSupports falls under this exception.

When accessing a WordPress website, I think it should be the explicit wish of the website visitor to see its full content, which does not lead to any further data processing by third parties. I think this also includes the display of emojis, which is common in all modern applications. However, I think it is questionable whether "technical storage or access is strictly necessary", as the test as to whether the browser allows emojis can be executed again each time a page is called up without any technical obstacles. It does not burden the website visitor's end device in a way that makes it impossible to access the website (less then 1 ms calculation time).

As a result, I see an obligation under the ePrivacy Directive to obtain consent for wpEmojiSettingsSupports.

The question of whether the loading time of the website is slightly worse as a result or whether there is no technical added value in checking the emoji functionality of the browser over and over again is irrelevant for the legal regulation.

Summary of the evaluation and recommendation

I am of the legal opinion that the session storage object (cookie-like information) wpEmojiSettingsSupports can only be set in the EU and EEA with consent. Therefore, I recommend removing this function for setting the session storage object from the WordPress core so that it can be used in relation to the modified code without the need for a consent management solution.

@peterwilsoncc I hope the shared legal opinion with sources is useful to check again if the commit should be changed!

[peterwilsoncc]

As a project, WordPress will be taking the advice of our own legal advisors.

The changes in [56074] use sessionStorage which is discarded each time a user closes their browser. The data is not persistent. The date check is to ensure long running sessions do not miss WP updates.

Discussion can continue on a closed ticket, but as I said, WordPress will be following the advice of our own legal advisors.