Created attachment 8923802 [details] Screen Shot 2017-10-31 at 13.36.35.png User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20100101 Steps to reproduce: 1. Turned on new privacy.resistFingerprinting in about:config 2. Visited blog.mozilla.org Actual results: Hanger to allow reading of canvas data. Expected results: No hanger. Regardless of whether it’s a problem across the web, I see no reason why a blog (especially blog.mozilla.org) should be trying to fingerprint its users.
Sorry, reading back on my report I was needlessly accusatory. Thanks for digging, glad that it’s a Wordpress thing.
Hey Robin and Pascal, Thank you for the detailed report. We're going to bring this into our next sprint (starting later this week) and we'll follow up with you as soon as we can. If you need anything in the meantime, you can need info me on this bug.
For what it’s worth I’m hitting this on a load of blogs all across the web. Today it was triggered by blog.vive.com and blog.gov.uk. Every site it pops up on loads the same emoji plugin. I’ll file an issue with the plugin (if I can work out where) so that they’re aware at least.
Turns out it’s core Wordpress, or at least a bundled-by-default plugin. I’ve filed https://core.trac.wordpress.org/ticket/42428 .
github.com causes this fingerprinting warning for the same reason (reading text pixels from canvas to detect whether native emoji are rendered in color).
I opened this thread to talk about this from the Tor Browser side: https://lists.torproject.org/pipermail/tbb-dev/2017-November/000649.html
I'm a WordPress Core developer, I maintain the emoji support. This issue has come up before, in relation to the Tor browser, (https://core.trac.wordpress.org/ticket/32138), there unfortunately doesn't seem to be an option other than the canvas render for detecting whether emoji are correctly supported or not. The alternative of checking font metrics probably won't work (https://core.trac.wordpress.org/ticket/42428#comment:3). Back when it came up with Tor, I asked if a flag for "this browser won't allow access to canvas image data" was possible, but the conversation unfortunately died out (https://trac.torproject.org/projects/tor/ticket/18195). I have no personal preference for whether it's a flag specifically for canvas, or if it's a more generic "this browser has privacy protection enabled" flag. If either flag is set, I'm happy for WordPress to skip the canvas check. I understand that it could be a privacy problem for the browser to say that it has privacy protection enabled, never let it be said that we're unable to find mildly ironic problems.
This is no longer a WebOps issue and is being handled by WP team as referenced by this ticket: https://core.trac.wordpress.org/ticket/42428 Closing out.