You are free to not use embeds or emojis if you wish, but there’s no legal obligation for you to do so.

As for the emojis, the included code that references the w.org CDN is a fallback for older browsers only. Newer browsers have emoji support built into them, and thus do not use that code. Emojis are already supported by core in this respect.

Emojis are served from w.s.org which includes trackers, but it’s actually pretty dumb to serve them that way because it results in additional http requests when virtually every modern browser has color emoji libraries.

Unfortunately WordPress makes no attempt to determine if the browser is capable of of its own emojis, it uses the w.s.org emojis even with modern browsers, but there is a solution.

You can use https://www.ads-software.com/plugins/disable-emojis/ and instead of using the remote svg emojis the browser will use it’s own emoji – thus zero tracking issues *and* fewer http requests.

Emojis are served from w.s.org which includes trackers, but it’s actually pretty dumb to serve them that way because it results in additional http requests when virtually every modern browser has color emoji libraries.

Actually, WordPress includes a browser detection script. If the emojis are supported by the browser, then it does not get them from s.w.org (which is our CDN). It only uses those image files as a fallback when the browser can’t show them. Also, the CDN does not “include trackers”. It sends image files, not javascript.

Unfortunately WordPress makes no attempt to determine if the browser is capable of of its own emojis

See, it does, actually. The script is called “wp-emoji-release.min.js”, and it’s compiled from three other scripts, which are wp-emoji.js, twemoji.js, and wp-emoji-loader.js. You can find all of these in the /wp-includes/js/ folder.

I would recommend looking at wp-emoji-loader.js specifically, as that shows the tests that it runs to determine support in the browser. While all modern browsers have some level of support, the level of support varies greatly, and so fallbacks like these are still often needed.

Standard latest version FireFox on 64 bit linux – it uses s.w.org for emoticons. When I use the plugin to disable s.w.org – then browser emojis are used for emoticons.

I suppose it is possible the scripts are testing for specific emojis not natively supported by firefox and chromium (for chromium on Linux it seems to use a combination of Symbola falling back to DejaVu when Symbola doesn’t have it. FireFox ships with its own color emoji font and falls back to Symbola when their color emoji font doesn’t have it)

Well there are other issues with FireFox, but the emojis work.

It’s kind of funny.

Twice I have recommended features that are not eye candy and needed in core – ability to build a webfont string that allows the sysadmin to specify the server, and a PSR-4 autoloader – and have been told that belong as plugins and not in core even though they really need to be in core because of script load issues.

But a purely eye candy feature like emoji fallback that would work just fine as a plugin, that’s in core.

I don’t understand.