[wp-trac] [WordPress Trac] #42428: wp-emoji pops up privacy hanger in Firefox with privacy.resistFingerprinting turned on

[WordPress Trac]

#42428: wp-emoji pops up privacy hanger in Firefox with
privacy.resistFingerprinting turned on
-----------------------------+-----------------------------
 Reporter:  robinwhittleton  |       Owner:  (none)
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Future Release
Component:  Emoji            |     Version:  4.1.2
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+-----------------------------

Old description:

> 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?

New description:

 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?

--

Comment (by 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

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/42428#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform