Closed Bug 1413182 Opened 7 years ago Closed 7 years ago

Turning privacy.resistFingerprinting on triggers a canvas warning on blog.mozilla.org

Categories

(Infrastructure & Operations :: Blogs, task)

Production
task
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: robin, Assigned: joeyk)

References

Details

(Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/5755])

Attachments

(1 file)

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.
Confirmed, to be specific this is happening on all mozilla blogs with the old One Mozilla theme such as
https://blog.mozilla.org/javascript/ or https://blog.mozilla.org/security/

The main blog blog.mozilla.org or other blogs using the newer theme such as blog.nighty.mozilla.org are not affected.

I suspect that this is due to the inclusion of a Wordpress js library in the <head> part to handle emojis and that seems to use canvas.
Status: UNCONFIRMED → NEW
Component: General → WebOps: Blogs
Ever confirmed: true
Product: www.mozilla.org → Infrastructure & Operations
Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/5755]
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.
Assignee: nobody → jkrejci
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.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: