[tor-bugs] #11935 [Tor Browser]: Strange fallback font behavior on Mac and Windows

Tor Bug Tracker & Wiki blackhole at torproject.org
Sun Jul 27 00:03:11 UTC 2014


#11935: Strange fallback font behavior on Mac and Windows
-------------------------+-------------------------------------------------
     Reporter:  mt2014   |      Owner:  mikeperry
         Type:  defect   |     Status:  reopened
     Priority:  normal   |  Milestone:
    Component:  Tor      |    Version:
  Browser                |   Keywords:  tbb-fingerprinting, tbb-firefox-
   Resolution:           |  patch
Actual Points:           |  Parent ID:
       Points:           |
-------------------------+-------------------------------------------------

Comment (by dcf):

 I 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.
 [[Image(nosuchfont.png)]]

 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 attachment: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."

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/11935#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list