Strange fallback font behavior on Mac and Windows
On stayinvisible.com, for some reason our font patch is causing Windows and Mac builds to report that they have all the fonts installed, where as Linux the test properly stops detecting fonts after our limit is reached.
This could be because something about TBB is simply causing the fallback fonts on Mac and Windows to be different than what they expect. Possible OS fingerprinting issue, or deeper bug?
In either case, this is not ridiculously serious, but is worth investigating.
Trac:
Username: mt2014
Activity
You are using a broken Tor Browser as the one we ship contains Torbutton enabled and functional (the Torbutton onion has to be green). I guess that is the reason for your leaking fonts list. But that is not a Tor Browser issue. Please get a new Tor Browser at https://www.torproject.org/download/download-easy.html.en and don't forget to verify the signature.
Trac:
Resolution: N/A to invalid
Status: new to closed
Via TorBrowser #2 (closed)
Trac:
Username: mt2014-
it's still same.
The first screen shot is using torbutton without Tor (transparent torrification)
second try i downloaded again from https://www.torproject.org/download/download-easy.html.en then run it all by default (see attachment)
I have tried it on different computer as well. it's gives the same results.
can you do the test on stayinvisible.com and take a screenshot?
Trac:
Username: mt2014 -
So. I can see this issue on Windows and Mac but my Linux box shows 0 fonts. That is kind of weird as my normal Iceweasel shows 7 fonts. We need some further investigation here... The fonts in attachment three are not the same I have on Windows visible although, of course, there is overlap.
Trac:
Cc: N/A to mcs, brade
Component: Torbutton to Firefox Patch Issues
Priority: blocker to critical -
Trac:
code -
Trac:
code2 -
What you see is not the fonts leaked but basically the list of fonts they test against (note e.g. the mentioning of Bell MT twice in your test results which is contained twice as well in their font list). Not sure what goes wrong here, though. The tests seem to behave correctly if one disables fingerprinting resistance for testing purposes setting "extensions.torbutton.resist_fingerprinting" to "false".
Trac:
Status: assigned to closed
Resolution: N/A to invalid 
Trac:
Description: why torbrowser still leaking fonts list? check here: stayinvisible.comto
On stayinvisible.com, for some reason our font patch is causing Windows and Mac builds to report that they have all the fonts installed, where as Linux the test properly stops detecting fonts after our limit is reached.
This could be because something about TBB is simply causing the fallback fonts on Mac and Windows to be different than what they expect. Possible OS fingerprinting issue, or deeper bug?
In either case, this is not ridiculously serious, but is worth investigating.
Priority: critical to normal
Summary: TorBrowser Fonts Leaking.... to Strange fallback font behavior on Mac and Windows
Keywords: N/A deleted, tbb-fingerprinting added
Cc: mcs, brade to N/AI have a guess as to what's happening. I ran into it myself while testing some web font stuff. When the font count limit is reached, and a new font family is requested, Tor Browser falls back to the default system font rather than show the requested font. However it does this even when there are more font families in the style, even if those families were previously allowed under the font limit. Other browsers would instead try the remaining families before falling back to the system default.
You can see it in action with the following HTML document. You have to run it on a system with DejaVu Sans Mono installed (any GNU/Linux system).
<!DOCTYPE html> <div id=d></div> <script> var d = document.getElementById("d"); function test(n) { if (n > 15) return; var p = document.createElement("p"); p.style.fontFamily = "nosuchfont" + n + ", DejaVu Sans Mono"; p.textContent = p.style.fontFamily; d.appendChild(p); setTimeout(function() { test(n + 1) }, 200); } test(1); </script>The output in Tor browser is below. After ten font families are tried, the text starts being rendered in the default system font (non-monospace), even though "DejaVu Sans Mono" was previously allowed under the font limit.
A giveaway in the stayinvisible.com case is that on my Windows, the first font name reported is Aharoni, which is the fifth font name tested. Counting the "Arial Black" that is used as a reference as one, and counting each font name twice because the test changes the family twice, it means the detection starts to go wrong after ten families have been loaded.
The code in code2 works by first measuring the width of a reference string with the CSS style
font-family: Arial Black;It then successively tries a bunch of two-family styles, all with "Arial Black" as the second family, like
font-family: Adobe Caslon Pro, Arial Black; font-family: Adobe Garamond, Arial Black; font-family: Adobe Garamond Pro, Arial Black; font-family: Agency FB, Arial Black; font-family: Aharoni, Arial Black; font-family: Algerian, Arial Black; ... font-family: Zapfino, Arial Black;The code compares the width of the string in each of these styles against the reference width. If the width differs, the tested font is counted as installed. The idea is that if the first family in the style is installed, it will be loaded and change the width of the string; and if it is not present, the second family "Arial Black" will be used and the width won't change.
Tor Browser's short-circuit font limit patch is effectively turning all the two-family styles, after the font limit is reached, into the default system font. Since the default has different dimensions than "Arial Black", the script false detects every font as installed. Why you don't see it on GNU/Linux, is because GNU/Linux usually doesn't have the "Arial Black" font they're using for reference, so the reference width is already using the system default.
I think this is the Tor Browser patch: https://gitweb.torproject.org/tor-browser.git/commitdiff/fc24b518cfba6310e1bdfa7d1aadeffaf9e86a2c#patch10.
I wouldn't be surprised if this issue also affects things like Google Web Font Loader, because they also rely on detecting changed glyph dimensions to know when a font has been loaded.
- https://github.com/typekit/webfontloader
-
http://processingjs.nihongoresources.com/the_smallest_font/ "What this font lets you do is typeset a div with
font-family: 'Desired Font', tinyfont, and then poll its dimensions over a few milliseconds."
