wp-emoji pops up privacy hanger in Firefox with privacy.resistFingerprinting turned on

[robinwhittleton]

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?

[robinwhittleton]

Screenshot of the hanger in current Firefox Nightly

[pento]

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.

[robinwhittleton]

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.

[pento]

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.

[pento]

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

​https://bugzilla.mozilla.org/show_bug.cgi?id=1413182#c8

I'll update here if there are any changes.

[pento]

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

[superpoincare]

Just wondering. Can fontfaceobserver be used for this?

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

[pento]

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

[ocean90]

#43264 was marked as a duplicate.

[seanking2919]

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.

[pento]

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

[pento]

#44247 was marked as a duplicate.

[nzflagmaven]

Thank you for the schooling, pento. I readily admit that I am often a dim bulb.

Granted it is not a bona fide privacy issue, but for those not privy to WordPress forums it bears a resemblance to one, and that in itself is arguably a problem.

Until Tor Browser learns to recognize WordPress's legitimate and apparently sole use of canvas data, and given that not all WordPress websites have any use for emojis, is a settings 'off' switch out of the question?

Just as many websites now request permission to send cookies, might WordPress websites that do use emojis have a settings option to politely ask before probing canvas data, thereby both educating their visitors and allaying any misplaced privacy concerns?

Otherwise users like myself will be forced to continue to edit the formatting.php file after each WordPress update with bluetouff's ticket #32138 solution of three years ago:

remove_action( 'wp_head', 'print_emoji_detection_script', 7 );

[seanking2919]

Yeah. I definitely think having an emojis core turned on/off solution would be best, especially right now. In the near future, I think having talks with Tor Browser devs (and maybe even Brave devs because they block emoji rendering if you have the "Block all fingerprinting" option enabled) about this would help so that we can understand the privacy concerns about using Canvas API to render emojis. Another thing I think we need to do is look into other ways to render emojis without the need for Canvas API.

[seanking2919]

Interesting. This is what the Font Face Observer dev says about rendering emojis: ​https://github.com/bramstein/fontfaceobserver/issues/113

Maybe we should give it at least a try and see if it works better than using Canvas API.

[peterwilsoncc]

Replying to seanking2919:

Interesting. This is what the Font Face Observer dev says about rendering emojis: ​https://github.com/bramstein/fontfaceobserver/issues/113

Thanks @seanking2919, I'll see if the WP script can use a width based approach for checking and reach out if needs be.

[peterwilsoncc]

As a rough start, I have ​https://jsbin.com/norotob/6/edit?js,output

• For tests to work, the element needs to be appended to the DOM
• I've tested both width and height to reduce the risk of chance matches
• In Font Face Observer there is some code to deal with Safari and widths, I need to check that out

[nzflagmaven]

Replying to peterwilsoncc and to seanking2919:

A post entitled "Using Font Face Observer to optimise font-loading in a WordPress site" might be of interest to you. It can be found at:

​https://www.kirstencassidy.com/using-font-face-observer-to-optimise-font-loading-in-wordpress-theme/.

Several days ago I sent Ms.Cassidy an e-mail from her site, asking her to consider weighing in on this discussion thread, but thus far no go.

[superpoincare]

Hi @peterwilsoncc,

I am getting this on Chrome 66, Windows 8.1

So the first test needs some modification, since I don't think the emoji is supported on it.

[seanking2919]

Interesting @peterwilsoncc. Running the latest version of Brave on Windows 7, this is what I get:
​https://kek.gg/i/7ZCWtF.png
​https://kek.gg/i/6Vkp8K.png

On Firefox 60.0.2 for Windows 7:
​https://kek.gg/i/3HSr3s.png
​https://kek.gg/i/7ZJKLc.png