oEmbed two click / local emoji scripts

[yoursql719]

Hi,

the first beta release 4.9.6 has a few optimziations due to the GDPR, but I think, WordPress is missing two very relevant features. With the latest beta release, WordPress would not be legal for use within the EU - except you´re using WordPress as private notepad!

1) oEmbed two click solution: similar to the shariff plugin, all embedded items via the core WordPress oEmbed function need a two click privacy. Only when the user first clicks on the embedded item, the scripts should be active and the user can view / listen to the embedded item.

2) The emoji script is loaded from Automaticc. There is no possibility to disable this behaviour or the best would be: load all scripts locally. This is one of the relevant of GDPR: you cannot tell your users or lawyers, why it is relevant for using your site, when specific scripts like emoji are loaded from a CDN. There is no need for a CDN.

It would be great, if you could still imagine to implement those both things, because they are rather important than a general privacy policy page, which the most users of WordPress had already created as a single page. And I think not all related core features needs an extra plugin, when it´s time to develop the core further. WordPress should go ahead and implement more features to the core than letting even more plugins used for a proper website.

Thanks and regards,

[swissspidy]

The emoji script is loaded from Automaticc

The emoji stuff is loaded from the WordPress.org CDN. It has nothing to do with the company Automattic.

As for the suggestions: IANAL, but I don't think these steps are necessary for GDPR compliance. But I leave that for the experts to decide.

[yoursql719]

Replying to swissspidy:

The emoji script is loaded from Automaticc

The emoji stuff is loaded from the WordPress.org CDN. It has nothing to do with the company Automattic.

Thanks for clarification. Even loading a script from a CDN must be clarified, if this CDN stores any user cookies / informations. Till now there is no information about what infos are stored to the wordpress servers everytime this script is loaded.

As for the suggestions: IANAL, but I don't think these steps are necessary for GDPR compliance. But I leave that for the experts to decide.

I can show you several posts about this problem and it is very relevant and one of the main parts of the GDPR: youtube and other providers stores cookies, when an user is accessing your site. Therefore it is not enough only to tell the user, that you´re doing this. You need the user to have a choise, wether he would like the see the video or not. It should NOT be loaded whithout any kind of opt in.
This is especially a german jurisdiction problem and yes if affects the e-privacy law partly, which comes with 2019, but some parts will be relevant on the may 25th.

[TimothyBlynJacobs]

See also #43713

[yoursql719]

Replying to TimothyBlynJacobs:

See also #43713

Thanks. It´s a similar topic, but removing makes no sense. A two click option would be the best: what should happen to already embedded content? Disabling oEmbed in backend would be the worst solution ever.

[desrosj]

Moving to the new Privacy component.

[desrosj]

Removing the GDPR keyword. This has been replaced by the new Privacy component and privacy focuses in Trac.

[garrett-eclipse]

The emoji script loaded via s.w.org was flagged again recently in #46343 and discussed a little in #core-privacy. We agree it should be bundled so it's loaded locally rather than from the external call.

If that is the direction things move for V2 of the privacy roadmap then there'd be no need to prefetch the domain which is raised a couple times;
#40426
#37788

Serve emoji image fallbacks from the local site instead of the external CDN at s.w.org.

When a page contains emoji the visitor's OS can't render natively, WordPress loads the PNG/SVG fallback from s.w.org, sending the visitor's IP and request headers to a third party without consent.

Image assets (Twemoji) are bundled locally under 72x72 and svg.

Trac ticket: https://core.trac.wordpress.org/ticket/44001

## Use of AI Tools

AI assistance: Yes
Tool(s): GitHub Copilot
Model(s): Claude Opus 4.8
Used for: Writing this pull request description only.

[masteradhoc]

Hey everyone,

I’ve picked this long-standing topic back up after some time away. For GDPR / privacy reasons im in favor of serving emoji assets locally in WordPress core instead of fetching them from s.w.org.

The main trade-off is clear: bundling the emoji images increases both file count and overall package size. That’s worth evaluating carefully — but it’s also consistent with several existing precedents in core, for example:

• Smilies — classic text emoticons (:), :(, etc.) are already converted to images that ship locally in wp-includes/images/smilies/. This is essentially the same mechanism we’re discussing here.
• Dashicons — the admin icon font is bundled in wp-includes/fonts/.
• Bundled JS libraries — libraries like jQuery, Backbone, Underscore, Lodash are all shipped with core rather than loaded from a CDN.
• The emoji loader itself — the Twemoji script (wp-emoji-release.min.js) is already served locally. Currently only the image assets are loaded from s.w.org.

There is a draft PR here:
​https://github.com/WordPress/wordpress-develop/pull/12252

Happy to iterate based on feedback and get this ready for proper review.

Pinging a few folks from other related core trac tickets: @gemonon @antmg @burnuser @sabernhardt @hlunter

[kimjiwoon]

I agree with the goal here: a visitor's IP and headers should not go to a third party just because a page contains an emoji. I would question the way ​PR #12252 gets there, though, for three reasons.

1. Emoji are text. The fallback replaces Unicode text with <img> elements. Bundling the image sets moves that representation into every WordPress install: the draft adds about 8,000 files (72x72 PNGs and SVGs), and each Twemoji or Unicode update would mean re-shipping thousands of binaries in Core.

2. Much of today's fallback comes from a detection bug. Since [61134] the Emoji 17 support test draws a malformed string, so browsers that support Emoji 17 are reported as not supporting it, and every emoji is replaced with images rather than only what is actually missing (#66104, patch in ​PR #13515). On Windows 11 with Chromium 152, trunk reports { flag: false, emoji: false }; with the fix it reports { flag: false, emoji: true }, so only country flags would still need a fallback there. I have only measured that browser, but it suggests fixing #66104 first and then measuring what really still needs a fallback, before deciding how much to bundle.

3. Self-hosting is already possible. The emoji_url and emoji_svg_url filters let a site serve these images from its own host today, without every install carrying the files by default.

If a local fallback is still wanted, another option keeps emoji as text: a locally hosted emoji font, limited with unicode-range to what the browser is missing (flags, for example), placed in the fallback font stack. The browser keeps rendering Unicode, and only the glyphs it lacks load, from the site itself. For Core to use a font that way, it has to know that a Font Library family is an emoji font, and today nothing can declare that: the field is removed along the way. That metadata is proposed in ​Gutenberg issue #82848. Colour-font support across browsers would need checking before that becomes a recommendation, so I am raising it as a direction rather than a replacement patch.

[kimjiwoon]

Replying to masteradhoc:

For GDPR / privacy reasons im in favor of serving emoji assets locally in WordPress core instead of fetching them from s.w.org.

I agree that the fallback assets should be served locally. I opened #66144 and draft ​PR 13618 as a smaller way to bundle them than #12252: one reproducibly built Twemoji COLRv1 WOFF2 of 657 KB, in wp-includes/fonts/ next to Dashicons, instead of the PNG and SVG image sets. In Edge it renders all 3,944 fully-qualified RGI emoji as one glyph each.

The draft only adds the font and its build provenance. It does not load the font or change the fallback yet; how the font is applied is a separate design question in #66144.

Two corrections to my comment:17:

• The Emoji 17 detection fix (#66104) is now in trunk ([63755]). In the Windows/Chromium case I measured, only flags still need a fallback.
• I suggested an emoji font in the fallback font stack, limited with unicode-range. The built font maps digits, space, and text-presentation characters such as ©, which keycaps need, so it cannot sit in a text font stack. It has to be applied only by a renderer that wraps sequences known to need fallback for the browser's capability profile.