[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