[tor-bugs] #5798 [Firefox Patch Issues]: Improve persistence and WebFont compatibility of font patch

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Sun Oct 7 14:22:25 UTC 2012


#5798: Improve persistence and WebFont compatibility of font patch
-------------------------------------------+--------------------------------
 Reporter:  mikeperry                      |          Owner:  mikeperry
     Type:  defect                         |         Status:  new      
 Priority:  major                          |      Milestone:           
Component:  Firefox Patch Issues           |        Version:           
 Keywords:  tbb-fingerprinting, interview  |         Parent:           
   Points:                                 |   Actualpoints:           
-------------------------------------------+--------------------------------

Comment(by monkeyiq):

 Looking over the patch, perhaps nsPrefShell refers to the nsPresContext
 where the mFontsUsed/mFontsTried member variables track the font
 use/attempts.

 Looking over the docs for [https://developer.mozilla.org/en-
 US/docs/XPCOM_Interface_Reference/nsIContentPrefService#setPref%28%29
 nsIContentPrefService] the use of the new
 [https://gitweb.torproject.org/torbrowser.git/blob/maint-2.3:/src/current-
 patches/firefox/alpha/0020-Add-mozIThirdPartyUtil.getFirstPartyURI-
 API.patch#l41 GetFirstPartyURI()] function gets us the "group"/url first
 param to SetPref(). Looking over what a variant can take (NsIVariant) it
 seems limited to strings and basic numeric types. So much for the perhaps
 bad idea of marshalling a stringset (font names used) into a single value
 there.

 I'm thinking that maybe using some canonical marshalling of the nsfont to
 a single string (eg, font.name from the current patch, maybe investigate
 adding style later too) and an aName (the key part for the pref) in the
 nsIContentPrefService of "tor.FontAttempt.${font.name}" and just setting
 the value to 1.
 Also using a prefix like "tor.FontAttempts" to record when a new
 fontattempt is made that isn't already in the prefs. So a probe to see if
 a font.name is new is quick, and the total number of used fonts or probes
 is also quick.

 Though there is some memory overhead using a new Content Prefs entry for
 each probe/use of a font for a site. Perhaps an acceptable trade of some
 RAM bits for less exposed entropy bits though.

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


More information about the tor-bugs mailing list