Make WordPress Core

Opened 12 months ago

Closed 12 months ago

Last modified 8 months ago

#57880 closed defect (bug) (duplicate)

Removing Emojis as GDPR trap

Reported by: burnuser's profile burnuser Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Emoji Keywords:
Focuses: privacy Cc:

Description

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.

https://user-images.githubusercontent.com/32030147/223041982-4a3c8731-8fc2-425b-8420-647d4b8d4bce.png

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.

https://user-images.githubusercontent.com/32030147/223042679-a5f92469-7df8-48c7-885a-6c47279e30c0.png

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.

https://user-images.githubusercontent.com/32030147/223043468-32c0bf3f-2a9f-42e0-9f10-9541ef2fc43e.png

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)

Change History (12)

#1 @audrasjb
12 months ago

  • Keywords reporter-feedback added
  • Version 6.1.1 deleted

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!

#2 @jonoaldersonwp
12 months ago

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.

#3 follow-up: @burnuser
12 months ago

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

#4 @ocean90
12 months ago

  • Component changed from External Libraries to Emoji
  • Keywords reporter-feedback removed
  • Milestone Awaiting Review deleted

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.

#5 in reply to: ↑ 3 @audrasjb
12 months ago

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.

#6 @audrasjb
12 months ago

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

#7 @jonoaldersonwp
12 months ago

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

#8 @Otto42
12 months ago

  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #54530.

#9 @sabernhardt
12 months ago

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

Last edited 8 months ago by sabernhardt (previous) (diff)

#10 follow-up: @burnuser
12 months ago

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.

#11 in reply to: ↑ 10 @hlunter
8 months ago

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.

#12 @audrasjb
8 months ago

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

Note: See TracTickets for help on using tickets.