WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 2 years ago

Last modified 2 years ago

#32138 closed enhancement (wontfix)

WordPress 4.2 : Tor Browser’s and Canvas privacy warning prompt

Reported by: bluetouff Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.2
Component: Emoji Keywords:
Focuses: Cc:

Description

The Tor Browser is known to be used by activists, journalists, and people who need a high level of privacy while they’re surfing.
Every possible way to track people on Internet are a serious concern for the Tor developers because anonymization doesn’t not support approximation and leads to take decision that could seem « over-paranoid » to other developpers community.

In previous WordPress versions (prior to 4.2) Gravatar was already known to be detected as tracker by some tools like Ghostery. But with gravatars disabled, only logged in users get the warning due to the admin bar.
4.2 update on wp-includes/formatting.php introduced a new way to check if emoji are enabled or not, injecting in wp-head an emoji detection script using canvas.

This new addition, even with emoji disabled, and logged off, lead the Tor Browser to print the a warning message

https://reflets.info/wp-content/uploads/2015/04/Tor-Warning.png

WordPress owners running a website with high privacy concerns cannot let the highly trustable Tor browser giving an alert prompt to each reader about a possible privacy issue on their website. The ability to let Tor Browser users allow or block canvas hash decoding malicious use has been discussed here and here and appears in Tor Reference documentation as a fingerprinting threat (https://www.torproject.org/projects/torbrowser/design/#fingerprinting-linkability).

« We display the warning if websites attempt to render image data and then silently extract it, because this is a major, high-entropy, highly stable fingerprinting vector. »

« After plugins and plugin-provided information, we believe that the HTML5 Canvas is the single largest fingerprinting threat browsers face today. Initial studies show that the Canvas can provide an easy-access fingerprinting target: The adversary simply renders WebGL, font, and named color data to a Canvas element, extracts the image buffer, and computes a hash of that image data. Subtle differences in the video card, font packs, and even font and graphics library versions allow the adversary to produce a stable, simple, high-entropy fingerprint of a computer. In fact, the hash of the rendered image can be used almost identically to a tracking cookie by the web server. »

Even if this not a security issue with WordPress, i guess the WordPress community should reconsider the use and implementation of this feature which is not critically useful for most of us, considering trust and privacy are useful and critical for vulnerable people who use Tor to protect themselves. This is related to trust, trust between : over-paranoid people who sometimes have good reasons to be such paranoid and website owners who try to run a state of the art WordPress for privacy, just like it should be out of the box.

For instance, i added in wp-includes/formating.php the following line :

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

Initially posted here : https://reflets.info/wordpress-4-2-tor-browsers-and-canvas-privacy-warning-prompt/

Attachments (1)

Tor-Warning.png (66.8 KB) - added by bluetouff 4 years ago.

Download all attachments as: .zip

Change History (12)

@bluetouff
4 years ago

#1 @SergeyBiryukov
4 years ago

Related: #32102

For instance, i added in wp-includes/formating.php the following line :
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );

No need to alter core files, there's a plugin to remove the emoji functionality.

#2 follow-up: @bluetouff
4 years ago

hey,

unfortunately, this plugin doesn't fix the tor browser prompt alert.

#3 in reply to: ↑ 2 @ocean90
4 years ago

Replying to bluetouff:

unfortunately, this plugin doesn't fix the tor browser prompt alert.

Can you explain this further? The plugin does the same as you have suggest: https://plugins.trac.wordpress.org/browser/disable-emojis/trunk/disable-emojis.php#L35

This ticket was mentioned in Slack in #core by ocean90. View the logs.


4 years ago

#5 @pento
4 years ago

Thank you very much for the bug report, @bluetouff!

To explain why this warning is occurring, it's to determine if the browser can support emoji - it draws the emoji on a canvas, then exports them and analyses the result. This is better than maintaining a list of browsers that do/don’t support emoji, as the emoji compatibility JS will automatically stop loading itself as soon as the browser updates with emoji support.

I'm not very familiar with the Tor Browser, so are you able to suggest a way we can get the same information, without causing this warning?

#6 @ilf
4 years ago

+1 to subscribe.

#7 @pento
3 years ago

  • Component changed from Formatting to Emoji

I've asked the Tor Browser crew for a flag that we could use to disable this test: https://trac.torproject.org/projects/tor/ticket/18195

#8 @swissspidy
2 years ago

Unfortunately still no progress on that Tor ticket

#9 @pento
2 years ago

#39700 was marked as a duplicate.

#10 follow-up: @pento
2 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

No movement on the Tor ticket in well over a year. Unless they change something, there's nothing we can do.

#11 in reply to: ↑ 10 @superpoincare
2 years ago

Replying to pento:

No movement on the Tor ticket in well over a year. Unless they change something, there's nothing we can do.

The ticket in Tor forums using fonts got me thinking ...

Adobe blank is a font which has zero width. This can be used to detect if the browser has used a system font or the fallback, which is Adobe Blank.

Or a subset of Adobe Blank.

From: https://blog.typekit.com/2013/03/28/introducing-adobe-blank/

  1. Include Adobe Blank as a data URI in the CSS file.
  1. Specify ‘font-family: SomeWebFont, “Adobe Blank” in the CSS rule for some DOM element that contains >text (and would therefore have a non-zero width when rendered using a regular font). One example would >be a <span> element that is absolutely positioned offscreen.
  2. Check the width of the DOM element. If it’s zero, SomeWebFont hasn’t loaded yet. If it’s greater than >zero, it has.

I am not sure if this works or even how to implement it. Just thinking out loud.

Note: See TracTickets for help on using tickets.