Text rendering allows font fingerprinting

Using dcf's font fingerprinting demo,

https://www.bamsoftware.com/talks/fc15-fontfp/fontfp.html#demo

gk [ticket:13313#comment:24 observed] that different operating systems render glyphs in the same font differently:

I just tested that on two 32bit Linux systems (one Ubuntu 12.04 and one Debian testing) and even there are differeces visible with bundled fonts (the diff is attached). I guess this means shipping the alpha with it is fine (it can't get worse wrt to the status quo :) ) but we might want to have an estimation about what the current solution really helps us for the stable series before we ship it there.

So I wonder whether it's possible to force Firefox/Tor Browser to use a cross-platform method for rendering fonts.

added TorBrowserTeam201603 component::applications/tor browser owner::arthuredelstein parent::18097 priority::medium severity::normal status::assigned tbb-5.5 tbb-fingerprinting-fonts type::defect labels

Another option is to try to minimize text rendering differences by adjusting anti-aliasing, hinting, and other similar settings. We'll have to investigate how these are implemented across different platforms.

Trac:
Summary: Text rendering allows OS fingerprinting to Text rendering allows fingerprinting

Trac:
Cc: gk to gk, mcs

dcf created a fonts.conf files that should help to homogenize rendering settings across Linux platforms. See https://trac.torproject.org/projects/tor/ticket/13313#comment:1

Also, he did fantastic work on font/text-rendering fingerprinting, reported here: https://bamsoftware.com/papers/fontfp.pdf with a demo described at https://trac.torproject.org/projects/tor/ticket/13313#comment:16

David, do you think there might be anything in the raw data from your survey that would help us to identify fingerprintable glyph rendering settings?

Trac:
Cc: gk, mcs to gk, mcs, dcf

Trac:

Here's a weird difference between OS X and linux. In TBB 5.0a4, we have Noto fonts used for everything, including chrome elements. But the chrome elements in linux look very different from those in OS X. For example, here is a comparison of the URL bar. On the left is Ubuntu/XFCE, and on the right is OS X.

So why the massive difference in rendering? Obviously the linux version is ugly and pretty unacceptable.

Trac:

Here's another example of web page text being rendered differently across platforms, even though they all are using the same font (Noto Sans). From top, Ubuntu (GNOME), OS X, Windows. Note that Ubuntu (GNOME) has a different URL bar from Ubuntu (XFCE):

It looks like Ubuntu GNOME is failing to generate bold and italics fonts (which may be related to not having Bold variants installed). Windows seems to render bold text wider than OS X. Regular text seems to be very similar on Linux and Windows, but a little different on Mac. The chrome text on Ubuntu GNOME is overly large and possibly fixed-width.

Replying to arthuredelstein:

It looks like Ubuntu GNOME is failing to generate bold and italics fonts (which may be related to not having Bold variants installed).

FWIW it is neither related to Ubuntu nor to GNOME. I see that on my Debian with Xfce as well.

Putting this on tbb-5.0 because if we don't figure out some way to improve this situation, we're going to need to drop the whole patch for 5.0 (which is fine, but we need to be aware of that possibility when looking at the 5.0 radar over the next few days).

Trac:
Keywords: N/A deleted, tbb-5.0 added

Replying to arthuredelstein:

dcf created a fonts.conf files that should help to homogenize rendering settings across Linux platforms. See https://trac.torproject.org/projects/tor/ticket/13313#comment:1

Also, he did fantastic work on font/text-rendering fingerprinting, reported here: https://bamsoftware.com/papers/fontfp.pdf with a demo described at https://trac.torproject.org/projects/tor/ticket/13313#comment:16

David, do you think there might be anything in the raw data from your survey that would help us to identify fingerprintable glyph rendering settings?

The main things are hinting and antialiasing settings. The other thing was people having different versions of the same named font (different versions of Verdana, for example). But that should be prevented by font file whitelisting.

Replying to arthuredelstein:

Using dcf's font fingerprinting demo,

https://www.bamsoftware.com/talks/fc15-fontfp/fontfp.html#demo

gk [ticket:13313#comment:24 observed] that different operating systems render glyphs in the same font differently:

I just tested that on two 32bit Linux systems (one Ubuntu 12.04 and one Debian testing) and even there are differeces visible with bundled fonts (the diff is attached). I guess this means shipping the alpha with it is fine (it can't get worse wrt to the status quo :) ) but we might want to have an estimation about what the current solution really helps us for the stable series before we ship it there.

The differences in linux32diff:ticket:13313, i.e. differences in 1 or 2 pixels of height, look like they are probably caused by hinting settings. That's what gk and I found last September when we were looking intensively at some examples. Could you try e.g. U+20B9 at

https://people.torproject.org/~dcf/fonttest.html#viewer

What we did before was to make screenshots of the renderings and then diff them. (In Gimp, Open as Layers, then change the layer mode of the top layer to "Difference".) Here's an example from the past of what a difference in hinting settings looks like: You can tell it is due to hinting because the non-black pixels are all shades of gray. If the difference had instead been caused by LCD subpixels, then they would be colored.

In the past, we wanted to disable all subpixel antialiasing, because of hardware differences in RGB versus BGR subpixel ordering, and vertical versus horizonal subpixels (when people rotate their monitors). A quick and dirty test for subpixels is to run the xmag program and check the edges of glyphs. If subpixels are disabled, then the antialiased pixels will all be gray; otherwise they will be shades of blue and red. (See https://www.bamsoftware.com/talks/fc15-fontfp/fontfp.html#textrendering for example.)

Trac:

Graphical diff of U+018D in cursive style from September 2014. I think it was between Debian and Ubuntu with different hinting settings.

Also FYI, about:support on Firefox will show you various graphics settings, such as whether acceleration is being used, and whether DirectWrite is being used on Windows. The difference between cairo and skia might also matter.

Here is a sample of how rendering differs on two Debian 8 systems with the same bundled fonts (Tor Browser 5.0a4). It's an animation with two frames, wait for it to cycle. The rendering is quite different, even if the integer pixel metrics are the same. (Canvas fingerprinting would not be fooled.) In this case, the checksum difference is not because the rendering settings, but because of font selection in one code point, which is unrelated to this ticket.

Trac:

Animation showing difference in rendering on two Debian 8 systems. It originally comes from the thread at ​https://lists.torproject.org/pipermail/tor-qa/2015-August/000654.html.

Here are some fixup patches for review:

There are two commits for tor-browser-bundle.git: https://github.com/arthuredelstein/tor-browser-bundle/commits/16672+1 And one commit for tor-browser.git: https://github.com/arthuredelstein/tor-browser/commits/16672+2

Builds for testing are available at: https://people.torproject.org/~arthuredelstein/downloads/16672-builds/

After carefully examining several free fonts including Noto Sans and Noto Serif, I decided at this stage that the best way to keep users happy is to follow Mike's suggestion and use native Latin system fonts. For Mac I chose (Verdana, Georgia, Courier) and for Windows (Arial, Georgia, Courier New). These fonts are installed by default on their respective operating systems. This approach potentially sacrifices some fingerprinting protection, because different Windows or Mac versions may have different versions of Arial, for example. So it will make sense to revisit this problem and see if it is possible either to suppress any variations in default fonts, or to find free fonts that look as good as the default counterparts.

The font situation in Linux is much more complex. No fonts can be relied upon in every linux flavor. So I chose to bundle Arimo, Tinos, and Cousine fonts (Sans, Serif, and Monospace respectively), which I think are aesthetically better than the Noto Latin fonts. (Arimo and Tinos are metrically idential to Arial and Times.) I also added dcf's fontconfig patch, which makes sure no fonts are used outside the bundled font directory, and also standardizes certain font settings, such as hinting and aliasing.

Obviously I haven't been able to try every OS flavor -- so I'm very interested to hear what checksums people get on various systems using David's test: https://people.torproject.org/~dcf/fonttest.html

I also modified the prefs in Tor Browser to enforce a strict font fallback order for every supported language. It will be interesting to see if this patch allows David and Mortiz to get matching checksums on their two Debian systems.

(In the pref patch, I also removed Noto Kufi Arabic in favor of Noto Naskh Arabic.)

Trac:
Keywords: N/A deleted, TorBrowserTeam201508R added
Status: new to needs_review