Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#2872 closed enhancement (fixed)

Limit the fonts available in TorBrowser

Reported by: mikeperry Owned by: mikeperry
Priority: High Milestone: TorBrowserBundle 2.3.x-stable
Component: Firefox Patch Issues Version:
Severity: Keywords: backport-to-mozilla, MikePerryIteration20111225
Cc: g.koppen@…, lunar@…, StrangeCharm Actual Points: 10
Parent ID: #2871 Points: 8
Reviewer: Sponsor:

Description

According to the Panopticlick data set, the font list (which they obtained through plugins) was the second most identifiable chunk of data they saw, behind plugins themselves. We block plugins, but fonts are still available through CSS.

There are seemingly two potential ways to solve this:

  1. Ship with a fixed set of fonts in TorBrowser
  2. Limit the number of fonts that can be loaded on a single page

Because of the wide variety of languages we support, and because we'd like this feature merged upstream in Firefox, I think the way to do this is is #2. The maximum number of fonts per page should be governed by an about:config setting.

Child Tickets

Change History (23)

comment:1 Changed 8 years ago by gk

Cc: g.koppen@… added

comment:2 Changed 8 years ago by mikeperry

Points: 16

Rough guess at the effort involved. Someone needs to start reviewing the relevant code to know for sure.

comment:3 Changed 8 years ago by mikeperry

Component: Tor bundles/installationTor Browser

comment:4 Changed 8 years ago by lunar

Cc: lunar@… added

comment:5 Changed 8 years ago by mikeperry

See #2187 for some other ruminations and test sites. It was closed as a dup of this.

comment:6 Changed 8 years ago by mikeperry

Beginning the descent down the rabbit hole on this.. Initial outlook is kind of bleak..

The main font wrangling lives in gfx/thebes/gfxFont.h. There appears to be a mapping to attributes (perhaps for purposes of querying via javascript) in accessible/src/base/nsTextAttrs.h.

Each OS seems to have its own set of classes in thebes for loading fonts.

There appear to be a few rendering surfaces upon which gfxFonts can be used. These include:

content/canvas/src/nsCanvasRenderingContext2D.cpp
layout/generic/nsHTMLContainerFrame.cpp
layout/svg/base/src/nsSVGGlyphFrame.h

and a few others..

CSS sheets appear to be represented via a linked list of nsStyleContexts.

There is a possibility we could store the number of fonts loaded by CSS in either the parent nsIPresShell or the nsIDocShell, which I believe might be accessible for most of these surfaces.

comment:7 Changed 8 years ago by mikeperry

There also appear to be an nsStyleSets, which in the source claim to represent style sheets.

There is also nsPresContext, which seems to have a 1:1 mapping to nsIPresShell, and may be more appropriate for storing CSS-related information. nsPresContext has a lot of helper functions for altering and recomputing styles after various changes.. It also houses the pref for "use_document_fonts", which is very promising...

comment:8 Changed 8 years ago by mikeperry

Looks like use_document_fonts only has an effect in nsRuleNode::ComputeFontData(), which also has access to the nsPresContext.

It looks like we might be able to add a call to nsPresContext to ask it if it has seen 'font' before, and what the current font count is. If the font count is too high, it could ComputeFontDate() could just take the codepath that the use_document_fonts=false takes.

I wonder what effect this would have on remote fonts.. We currently block those with NoScript, though, so that is probably irrelevant.

The other question is, what do we want to count? Just font-families? Or (font-family,font-style,font-size) tuples?

comment:9 Changed 8 years ago by mikeperry

Points: 168

We'll need to test this a lot, and there still are some choices to make, but I think the above hack should more or less be doable in a couple of days of work.

comment:10 Changed 8 years ago by mikeperry

Priority: normalmajor

comment:11 Changed 8 years ago by mikeperry

Cc: StrangeCharm added

comment:12 in reply to:  8 Changed 8 years ago by rransom

Replying to mikeperry:

The other question is, what do we want to count? Just font-families? Or (font-family,font-style,font-size) tuples?

Count (font-family, font-style) pairs (I'm assuming that weight and slant and italic/not-italic are part of font-style here). The bold form of a font may be shipped in a separate file from the not-bold form, and may be created in a later version of the font package.

comment:13 Changed 8 years ago by StrangeCharm

Keywords: backport-to-mozilla added

comment:14 Changed 8 years ago by mikeperry

Milestone: TorBrowserBundle 2.3.x-stable

comment:15 Changed 8 years ago by mikeperry

Keywords: MikePerryIteration20111211 added

comment:16 Changed 8 years ago by mikeperry

Keywords: MikePerryIteration20111225 added; MikePerryIteration20111211 removed

comment:17 Changed 8 years ago by mikeperry

Actual Points: 10
Resolution: fixed
Status: newclosed

Ok, this is finally done. The patch is in mikeperry/patches waiting for the buildbot to hit it. We create two prefs: browser.display.max_font_count and browser.display.max_font_attempts. My initial experimentation seems to indicate we want to set these around 5 and 50 respectively, but perhaps the second one can be lower when not using font testing sites.

We'll need some font snobs to test this out and let us know what values don't make the web look like shit.

Also note, we use only font families, as font styles did not seem to be always available in ComputeFontData(). Font families seem to be more intuitive with all of the testing sites I found on the net, anyway. We can just set the limits lower to compensate for this.

comment:18 Changed 7 years ago by cypherpunks

Has this patch been submitted upstream? What is the bugzilla bug no?

comment:19 in reply to:  18 Changed 7 years ago by mikeperry

Replying to cypherpunks:

Has this patch been submitted upstream? What is the bugzilla bug no?

We maintain a canonical list of our patches at https://www.torproject.org/projects/torbrowser/design/#firefox-patches.

As I am the only browser engineer we have, I'm focusing on making sure our prototype works well. I don't really have any time to manage merging bugs upstream. Either Mozilla decides they like our ideas, or they don't.

comment:20 Changed 7 years ago by cviecco

Mozilla has a bug about this at: https://bugzilla.mozilla.org/show_bug.cgi?id=732096 . A Different approach is used, that is to limit the fonts to use only the generic font family.  It is doubtful the current Tor font patch would be merged upstream as fonts can still be enumerated, just more slowly. The generic approach prevents this but makes many websites (that have incomplete font-familiy stacks) look strange.

comment:21 Changed 7 years ago by cypherpunks

Resolution: fixed
Status: closedreopened

Does not work for me with the latest TBB. On three different test systems (Linux and two different Windows versions) there are three different sets of fonts.

How to reproduce:
Enable javascript. Go to ip-check.info start the test once with TBB on Linux and once with TBB on Windows.

Result:
Windows 1: about 180 fonts
Windows 2: about 40 fonts
Linux: about 20 fonts
(they can not only see the number, but the exact list)

Expected result:
Windows 1 fonts = Windows 2 fonts = Linux fonts

Suggested solution:
Reply with only 3 fonts.
monospace, serif, times new roman

Who done implemented already:
I am not a big fan of JonDo, but in this case they done it better. Go to https://anonymous-proxy-servers.net/en/jondofox.html and download JonDoFox for free. You can test it without proxy. Right click on JondoButton (like TorButton) and choose no proxy. Then go to ip-check.info - only 3 fonts. Perhaps look at their source code for a tip.

comment:22 Changed 7 years ago by mikeperry

Resolution: fixed
Status: reopenedclosed

We have not yet set values for the two prefs created by this patch. I created #4797 to find values.

In fact, I am pretty sure we want to switch the patch out entirely for the alternate patch attached to #4797, which implements your suggested solution.

comment:23 Changed 7 years ago by mikeperry

FYI: We picked 10 font attempts and 5 fonts for this approach, which is deployed in the current TBB 2.2.35-11. #4797 is for trying an alternate approach limiting us to "generic" fonts to see if it's better/worse.. The two prefs are named browser.display.max_font_attempts and browser.display.max_font_count if you want to try tweaking the values.

Note: See TracTickets for help on using tickets.