Remove Emojis (GDPR friendly)

[discobot]

Removes the extra code bloat used to add support for emoji’s in older browsers

---

Read-only archive: Issues · ClassicPress/ClassicPress · GitHub

Author: ribeiroeder

Vote count: 126

Status: planned

Our roadmap for v2 is to move features into “core plugins” that can be disabled or deleted as needed: ClassicPress | Stable. Lightweight. Instantly Familiar.

Emoji support is a great candidate for this effort. We need to build a plugin directory first though.

~ posted by James Nylen

Tags:

• request-modify-feature
• request-remove-feature

---

Comments

Agreed. This means that we should enable STRICT_ALL_TABLES in MySQL because the fact that WP does not do this is what led to the insertion of emojis in the first place (apparently as some sort of cover for adding esoteric security).

~ posted by KTS915

I think this proposal and STRICT_ALL_TABLES are two separate issues.

I am not in favor of this one. On my computer one of the only places I get nice-looking emoji rendering is on WP sites, because I’m running a version of Linux which does not have support for this by default.

Also, what is the connection to GDPR here?

~ posted by James Nylen

Here is the proposal for STRICT_ALL_TABLES:
Issues · ClassicPress/ClassicPress · GitHub

~ posted by Wade Striebel

@James Nylen: Embedding emoji-images (or any other data) from external servers like s.w.org without notice and approval to/by the user voids GDPR, it allows tracking of users via their IP address (IP address is considered personal data in GDPR).

~ posted by Dora D.

The possibility of tracking is not enough to void GDPR. It depends on what the server actually does with the IP addresses.

~ posted by James Nylen

@James Nylen: That’s why you have to notify the user and tell him/her what exactly does or does not happen with the IP and have them approve it. And to be able to know what happens, you need detailed information from the external server provider.

Do you know what exactly s.w.org does with the IP addresses collected from the emoji images server? GDPR requires a full postal address and a named contact person for these requests. None of this exists at wordpress.org

~ posted by Dora D.

Yep, I definitely agree we can do better there. Probably the easiest option for now would be to serve the emoji images from the individual site directly.

My overall point with jumping into this discussion is that the emoji feature was introduced for good reasons: not all platforms support emoji display, and they don’t display consistently on the platforms that do support them. Something we should consider before deciding to remove it.

~ posted by James Nylen

Agree. Serving emoji images from local site would be fine in terms of GDPR.

~ posted by Dora D.

I think emojis are another candidate for being moved to a core plugin.

~ posted by invisnet

I thought that emojis where a “mere” by-product of allowing multibyte characters or something like that?

~ posted by Pieter Bos

I think we are talking about two different things here. One is multi-byte character storage in the database (which was obfuscated and conflated with emoji support) and the other is emoji support in the front-end.

I don’t think we should remove front-end emoji support, but adding an option to disable it would certainly be fine.

I don’t know enough about the multi-byte character storage issue to have an opinion yet.

~ posted by James Nylen

@KTS915 covered the issue in his first comment.

I don’t like the why the Emojis bloat my source code in the first place. Yes I’d like to see it removed from core, but maybe as an optional ClassicPress plugin (and eventually a well controlled plugin under a ClassicPress library).

~ posted by Avrom

I don’t agree too.
People with various browsers that not support them will have issues because there is no alert and will complain about wrong rendering to the webites owners and later to us as project.
There is Disable Emojis (GDPR friendly) – WordPress plugin | WordPress.org that remove that and for gdpr remove only the autofetch of the dns.
Maybe we can plan instead of a plugin to add a constant for wp-config that disable them.

For gdpr we can do another constant that globally change this behaviour also in other stuff (if there are).

~ posted by Daniele Scasciafratte

Remove.

~ posted by Neal Umphred

Definitely I am pro on removing them and have them as a side plugin

~ posted by Chris Chiotis

I’ve been getting into emojis more lately, but feel they’re plugin territory.

~ posted by John

I’m also for removing and make them available as a plugin for people that want to use ClassicPress as a blog (assuming that most company sites don’t need funny faces).

~ posted by Pieter Bos

+1 on moving it to plugin land.

~ posted by Pedro de Carvalho

Plugin

~ posted by Ashley Goodman

Emojis should definitely be plugin-land. Emojis are nice and cool and I’d love to be able to install a plugin and use them in a GDPR-friendly way, but they have no right to bloat business installs and run random javascript on the front end, and they certainly shouldn’t be pinging random servers (ironic, given wordpress’s general fear of CDN integration for things like JQuery).

~ posted by Greg Schoppe

Emoji added as security flaw update …

https://poststatus.com/the-trojan-emoji/

~ posted by Glenn Tate

We are talking about the fact, that you can protect the database even without showing fancy smileys on the front-end even if a business site simply does not need poop emojis or whatsoever (with extra code that has nothing to do with security to render those smileys).
Maybe if the Fart Co still needs those emojis…well in that case they can install a plugin for that purpose.

~ posted by Peter B

@Peter B, there are plenty of legitimate businesses that use emojis in their marketing. There is no need to belittle those that find this feature useful, just to communicate that you don’t.

The important question is not “Are emojis ‘professional’?”, it’s “Do emojis belong in core?”. To my mind the answer is no.

As long as we maintain utf8_mb4 support, we retain the security ‘fix’, and if we simply render the emojis in the system font, by default, we have a reasonable level of core functionality.

Those people who want to use a standard cross-platform emoji icon-set are wanting a very specific feature set that fundamentally goes beyond what emojis are designed to be. Emojis are designed to trigger device-specific rendering. So, it seems beyond the base level of support to offer a custom wordpress emoji glyph-set, and it also seems counter to the web-standards-first approach to features that I would prefer to see in CP.

All that said, it would obviously be useful as a well-supported core-maintained plugin, similar to the direction I imagine we will eventually want to take with embeds.

~ posted by Greg Schoppe

When speaking of bloat I’d like to know how much code is involved and if it actually impacts the speed of the site.

~ posted by Glenn Tate

WP emoji support adds two kilobytes of additional javascript in the head of every page, and an additional four kilobytes of minified JS that gets loaded asynchronously.

In addition, it parses the entire page on every change of ready state to look for any emoji characters, and rather than rendering them using the system font or a default browser implementation (as intended for emojis), it makes an external call to an address at s.w.org to pull in image files.

s.w.org is wordpress.org’s CDN, so there is also some concern over the privacy/GDPR impact of making requests to an external server whose privacy policy is not available to the site admin or the general public, as well as concern for having features of CP that rely on the WP website to function.

~ posted by Greg Schoppe

WP emoji support adds two kilobytes of additional javascript in the head of every page, and an additional four kilobytes of minified JS that gets loaded asynchronously.

It also has its hooks into the grunt-based build process. If I recall correctly, it scans every source file looking for a regex which appears in one single file, and does a replacement. Not a huge problem but it would be good to get rid of this too.

s.w.org is wordpress.org’s CDN, so there is also some concern over the privacy/GDPR impact of making requests to an external server whose privacy policy is not available to the site admin or the general public, as well as concern for having features of CP that rely on the WP website to function.

We are planning to remove this callout and host emoji locally for v1. We have started, and planned an approach that we think will work, but there is still a good bit left to do: Host emojis on ClassicPress servers by senlin · Pull Request #212 · ClassicPress/ClassicPress · GitHub

After v1, the front-end emoji features would be a good candidate to move out into a core plugin.

~ posted by James Nylen

I don’t know if the GDPR is the best argument for this topic (though admittedly valid) since, let’s be honest, it is almost impossible to be fully compliant (and “compliance” is very subjective anyway; ask any attorney).

That said, I think it should be a checkbox in Settings, disabled by default. I have seen significantly more sites that do not use or have no use for emojis than those that do, yet nearly all of them have the useless extra code in the page head. You can slap some GDPR help text on the checkbox, as desired.

However, I certainly wouldn’t complain if it was removed entirely. That sort of rubbish should be added by a plugin, not be part of core. WordPress has some notable missing elements/issues (host header injection, anyone?), yet they decided that shoving emoji down everyones pipe was important. 0_o

~ posted by Daniel Hendricks

I would not miss emojis at all. Happy to have them removed, or enabled by checkbox in Settings as mentioned above.

~ posted by Alan Coggins

Since I last commented here, we’ve published our roadmap for version 2, in which lesser-used or less-wanted features will be moved out into “core plugins” that are enabled by default but can be disabled or deleted entirely. You can read more here: ClassicPress | Stable. Lightweight. Instantly Familiar.

This is currently the top petition by number of votes ( Issues · ClassicPress/ClassicPress · GitHub ), so it seems like a good place to start, and I’m marking this petition as Planned. We “just” have to build a plugin directory first.

~ posted by James Nylen

The Plugin Directory will take a long time to fully develop. Getting rid of built-in Emoji’s would be far less work and a faster timeline to accomplish IMO. As others mentioned, a checkbox and disabled by default would be great.

~ posted by Avrom

[ozfiddler]

Emojis look like they are on the way to being a core plugin…

Core plugins discussion

Thanks, @MattyRob! Great work. I see in the repo we have the following core plugins (for anyone interested): Customizer XML-RPC REST API Emoji Embed API @james what would be the next logical step to try to push this forward?

So this petition could be marked as actioned?

[viktor]

The progress on the core plugin will be tracked here:

Core Plugin: Emojis