Opened 5 years ago

Last modified 5 months ago

#16312 new defect

Limit font queries per URL bar domain

Reported by: arthuredelstein Owned by: arthuredelstein
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-fingerprinting-fonts
Cc: dcf, brade, mcs Actual Points:
Parent ID: #18097 Points:
Reviewer: Sponsor:

Description (last modified by arthuredelstein)

In #13313, we introduced a patch to restrict the fonts allowed to be loaded in Tor Browser. But different versions of the same font could still be used to distinguish users. We could potentially limit the damage by introducing a second patch that restricts the number of allowed font requests per URL bar domain.

Previously we had a patch for #2872 that worked something like this, although it wasn't tied to URL bar domain.

Child Tickets

Change History (17)

comment:1 Changed 5 years ago by gk

Keywords: tbb-fingerprinting added

comment:2 Changed 5 years ago by mikeperry

Keywords: tbb-5.0a-highrisk added

What about a #13313-style solution? That is probably the only sure-shot solution against font fingerprinting. It looks like Mozilla landed support for that approach in FF32: https://bugzilla.mozilla.org/show_bug.cgi?id=998844.

As another option, gacar suggested https://bugzilla.mozilla.org/show_bug.cgi?id=1121643. But I think I'd rather spend the disk space on #13313/https://bugzilla.mozilla.org/show_bug.cgi?id=998844, which should be less work on our end, too.

comment:3 Changed 5 years ago by gk

Cc: dcf added

comment:4 Changed 5 years ago by gk

Owner: changed from tbb-team to arthuredelstein
Status: newassigned

comment:5 Changed 5 years ago by mcs

Cc: brade mcs added

comment:6 Changed 5 years ago by dcf

I haven't lost sight of #13313 but I'll have to page in a lot of information in order to resume working on it. It would be good to have someone else try the patches there and help figure out how to fix the problems with it.

comment:7 Changed 5 years ago by mikeperry

Keywords: tbb-5.0a4 added

Tag some 5.0a4 goals.

comment:8 Changed 5 years ago by mikeperry

Keywords: ff38-esr tbb-5.0a-highrisk tbb-5.0a4 removed
Resolution: duplicate
Status: assignedclosed
Summary: font limit patchLimit fonts to a whitelist?

I think #13313 is our plan here for the immediate future, but it is going to increase the bundle sizes by 15MB, not 3.. I am retitling this ticket to represent the approach mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1121643, in case we decide that the 15MB is not worth it for some reason.

In the meantime, I am taking this ticket off of our 5.0 radar in favor of #13313.

comment:9 Changed 5 years ago by mikeperry

Resolution: duplicate
Status: closedreopened

(I didn't mean to close this)

comment:10 Changed 5 years ago by arthuredelstein

In #13313, we introduced a patch that more or less implements a pref like the one described in https://bugzilla.mozilla.org/show_bug.cgi?id=1121643. If we decide in the long term not to bundle fonts (because 15 MB is too much), this pref, "font.system.whitelist", could also be used to expose a restricted set of pre-installed system fonts.

comment:11 Changed 5 years ago by gk

Keywords: tbb-fingerprinting-fonts added; tbb-fingerprinting removed
Severity: Normal

comment:12 Changed 4 years ago by arthuredelstein

Description: modified (diff)
Summary: Limit fonts to a whitelist?Limit font queries by URL bar domain

comment:13 Changed 4 years ago by arthuredelstein

Parent ID: 18097

comment:14 Changed 4 years ago by arthuredelstein

Parent ID: 18097#18097

comment:15 Changed 3 years ago by cypherpunks

Status: reopenedneeds_information
Summary: Limit font queries by URL bar domainLimit font queries per URL bar domain

Is this a way to go?

comment:16 Changed 6 months ago by gk

Status: needs_informationnew

comment:17 Changed 5 months ago by Thorin

In a paper (I'll dig up the reference if required), it was shown that the most fonts used (legitimately?) by sites (using an Alexa top sites listing) was around 30, with one site using close to 50. Most were 10 or under. Without the reference to hand, I do not know for sure that they were only counting installed fonts. But where would you draw the line vs breakage. I assume the analysis excluded FPing scripts that have a font component (e.g fingerprintjs2 starts at 60+ fonts). It would be interesting if OpenWPM could return anything meaningful on installed font queries per site

I also wonder how easy this would be to bypass - I can think of a number of ways: i.e I am thinking about what happens on subsequent domain pages in the same session, or sub-domains, etc - do I get another free hit? Additionally, by using targeted font lists, I can still get all the entropy possible that I know of (e.g. within TB Window users I only need five or six fonts: and you can't hide that you are the Tor Browser on Windows, and I will always come in under your limit).

Limiting the installed fonts used per whatever (domain, sub-domain, eTLD+1?) and per session might make it harder for current FPing scripts, but will ultimately not hold up. The only real solution, IMO, is for all users to have the same identical bundled fonts (different per OS if need be) as this also mitigates other font FPing techniques.

However, given that bundling all fonts for all users might be is a pipe-dream, this would probably be the next best measure, certainly upstream for Firefox RFP users .. assuming it's even feasible (IDK think if it is)

Note: See TracTickets for help on using tickets.