Removing Emojis as GDPR trap

[burnuser]

As reported there: ​https://github.com/WordPress/gutenberg/issues/48767 and advised to report it here.

Inserting Emojis in the WordPress backend by every post author is very easy. With a few keystrokes to create a traditional smiley or inserting an Emoji with Windows On-Screen Keyboard.

But when inserted, WordPress breaks a GDPR PRIVACY rule in the webpage frontend out of the box and loads the Emojis as SVG images from s.w.org Server.

So, loading resources from an external (USA) server without user consent, the website owner can be sued in Europe!

The only solution at the moment is using a Plugin like ​https://wordpress.org/plugins/disable-emojis/ to cut the unwanted external server connection.

Without any drawback in result, because any modern browser can display Emojis out of the box!

But adding a "Disable Emojis" plugin to every WordPress website in Europe, only to be conform with GDPR is not a very lean solution. And most website owners are even not aware of the - eventually high price - problem of a simple, single inserted Emoji!

One of the following solutions would be much better:
A) Deactivating Emoji server fetching out of the box in WordPress
B) Make Emoji server fetching optional (default = NOT) with a simple switch box in Settings => Reading
C) Save and load Emojis locally (= from the same server of the WordPress installation)

[audrasjb]

Hello and thank you for opening this ticket,

So, loading resources from an external (USA) server without user consent, the website owner can be sued in Europe!

Could you please add references/sources for this assertion?

Thank you!

[jonoaldersonwp]

Let's not go round and round on this again; we have a general consensus that loading resources from third-party domains is generally a concern for GDPR and similar legislation/etc (as the user's IP is personal information in many territories), and that the current emoji mechanism is a specific concern in this regard (as well as a performance concern).

This is the same narrative that's more broadly affecting the web when it comes to, e.g., website owners being sued for using Google Fonts (which has incentivised us to progress our Fonts API), and member EU states declaring Google Analytics to be illegal (due to cross-broader data sharing).

This is indeed a problem.

[burnuser]

An explanation for similar problem with Google Fonts from Google Servers:
​https://meetanshi.com/blog/google-fonts-gdpr-compliant/

[ocean90]

Marking as a duplicate of #54530 to keep any discussions in one place. While already closed you're invited to add any further input to such tickets.

[audrasjb]

Replying to burnuser:

An explanation for similar problem with Google Fonts from Google Servers:
​https://meetanshi.com/blog/google-fonts-gdpr-compliant/

The issue with Google Fonts was a known issue (I worked on #55985 and reviewed a ​6.2 devnote about this change), but I'm unsure to understand why the Emoji detection script from w.org technically is a similar issue, if no data is stored on w.org servers.

[audrasjb]

By the way, yes: let's discuss this in #54530.

[jonoaldersonwp]

Personal data (the user's IP address) is transmitted to another server (in another country) without their consent.

[Otto42]

Duplicate of #54530.

[sabernhardt]

#54530 fits for option A.

Option C (serving locally) is part of #44001, though making changes for both embed and emoji on the same ticket is quite impractical.

[burnuser]

Maybe I'm to dumb to understand the principle of a bug tracker, but in my opinion:

1.) "Duplicate" means the same problem. And the referenced https://core.trac.wordpress.org/ticket/54530 does not even mention GDPR or privacy problems connected to the transfer of user IP without consent to a foreign server.
(It could be referenced as another aspect to keep in mind, but it is NOT the same problem!)

2.) An open bug means, something has to be solved. => Visible for all users who are checking open bugs.
A closed bug means, nothing more to do. (And nobody has to check back for it.)

But yes, from an efficiency point of view, ... congratulations. Closing the - for millions of people in Europe very serious - report by a wrong "duplication" mark, referencing an already closed bug, is the quickest way to get the whole problem off the table.

[hlunter]

Replying to burnuser:

Maybe I'm to dumb to understand the principle of a bug tracker, but in my opinion:

1.) "Duplicate" means the same problem. And the referenced https://core.trac.wordpress.org/ticket/54530 does not even mention GDPR or privacy problems connected to the transfer of user IP without consent to a foreign server.
(It could be referenced as another aspect to keep in mind, but it is NOT the same problem!)

2.) An open bug means, something has to be solved. => Visible for all users who are checking open bugs.
A closed bug means, nothing more to do. (And nobody has to check back for it.)

But yes, from an efficiency point of view, ... congratulations. Closing the - for millions of people in Europe very serious - report by a wrong "duplication" mark, referencing an already closed bug, is the quickest way to get the whole problem off the table.

I agree, this ticket should be reopened. WordPress should be GDPR complaint by default.

[audrasjb]

For what it's worth, here is an interesting reading from the European Commission website (published on July 10, 2023):

​Data Protection: European Commission adopts new adequacy decision for safe and trusted EU-US data flows