Make WordPress Core

Opened 4 years ago

Last modified 3 years ago

#42428 new defect (bug)

wp-emoji pops up privacy hanger in Firefox with privacy.resistFingerprinting turned on — at Version 10

Reported by: robinwhittleton Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.1.2
Component: Emoji Keywords:
Focuses: Cc:

Description (last modified by pento)

This isn’t really a bug, but worth reporting anyway.

wp-emoji uses a technique that’s often used by trackers for fingerprinting clients: reading canvas pixel data. For them, differences in OS and graphics drivers can lead to subtle differences when text is rendered to a canvas. This means that when they hash data read out of the canvas with text on they have another datapoint to identify a client.

To work around this, Firefox has recently uplifted a technique from TOR Browser. If you visit a site that tries to do this it’ll pop open a hanger asking for the user’s permission. You can test this by downloading a copy of Firefox Nightly, going to about:config and setting privacy.resistFingerprinting to true. Which brings us on to WordPress…

Unfortunately the default wp-emoji package also uses this technnique, which triggers a browser warning on a large number of sites I visit on a daily basis. While I doubt that Wordpress is using this for user tracking, it means that sites that are being nefarious get lost in the Wordpress noise. This is a shame, but also I would imagine that it would be hard for Firefox to turn this on by default given the number of sites out there using Wordpress.

What I’d like to suggest is that:
1) wp-emoji is reviewed to see whether this technique is necessary for its functionlity. Can it be updated to use some other technique?
2) wp-emoji is considered for removal by default. According to the docs wp-emoji ‘will convert the often greyscale Emoji characters to colored image files.‘ Is this really a problem with the current set of browsers?

Change History (11)

4 years ago

Screenshot of the hanger in current Firefox Nightly

#1 @pento
4 years ago

  • Keywords reporter-feedback added
  • Version trunk deleted

Hi @robinwhittleton, thank you for the report!

We had a similar bug report for the Tor Browser (#32138), but were unfortunately unable to resolve it, as there was no way to determine whether the browser would cause a popup for this detection technique.

Unfortunately, we haven't been able to find an alternative method of detecting browser emoji rendering support, so the technique itself is here to stay. If there were an appropriate flag we could check for before running the emoji check, we could certainly short circuit it. Tor doesn't have such a flag, do you know if Firefox does?

I don't expect the emoji compatibility script to be deprecated. Browsers can only render the emoji that the OS they're installed on knows about, so as new emoji are released, browsers have to wait for OSes to catch up. In the mean time, we usually update our emoji library well ahead of OSes, so folks can start using the new emoji immediately.

#2 @robinwhittleton
4 years ago

Is there a case to always replace emoji with images? That would work around the issue by removing the check, but keep the support required for the latest.

Alternatively, is there merit to this suggestion on the TOR issue you linked to? It feels reasonable as a solution to missing emoji, although doesn’t solve the black+white case. https://core.trac.wordpress.org/ticket/32138#comment:11

Looking at gs.statcounter.com (and guessing at Windows less than 8.1 as the major remaining non-colour holdout) it looks like 18-19% of users’ activity worldwide doesn’t have colour support. That’s more than I would have guessed, so I can see why just removing this is a non-option (assuming the value in colour emoji).

Anyway, thanks for the quick reply.

#3 @pento
4 years ago

The idea is to provide a consistent experience, so, emoji tries one of three options:

  • Use native emoji, so that people see the emoji characters they're used to, and use less bandwidth.
  • Use native emoji except for flags, because some native implementations support everything except for the full flag set.
  • Use images for all emoji.

I don't think the font test would work - because emoji glyphs can be made up of several emoji joined together. For example, "🤷" is an emoji made up of a single character. "🤷🏻‍♂️", however, is made up of three emoji characters joined together - "🤷", "🏻", and "♂️". Platforms that don't support "🤷🏻‍♂️" will render it as "🤷 🏻 ♂️". There are many instances like this, where system fonts will still render the emoji, they'll just do it incorrectly.

#4 @pento
4 years ago

  • Keywords reporter-feedback removed
  • Milestone changed from Awaiting Review to Future Release
  • Version set to 4.1.2

For anyone else following along here, I've commented on a relevant Firefox ticket:


I'll update here if there are any changes.

#5 @pento
4 years ago

Previous Firefox ticket was closed, here's the new ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1414989

#6 @superpoincare
4 years ago

Just wondering. Can fontfaceobserver be used for this?

The author seems to think it can: https://github.com/bramstein/fontfaceobserver/issues/113#issuecomment-348240721

#7 @pento
4 years ago

I'm not sure that would work, for the reasons mentioned in comment 3.

#8 @ocean90
4 years ago

#43264 was marked as a duplicate.

#9 @seanking2919
4 years ago

I definitely think this is an issue that needs to be addressed with current WordPress versions. Personally, I think just using images for emojis might be best in order to best protect the privacy of users.

#10 @pento
4 years ago

  • Description modified (diff)

There's an ongoing discussion to add an appropriate flag to the permissions API. Firefox will hopefully be implementing this flag.

Note: See TracTickets for help on using tickets.