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:
Ship with a fixed set of fonts in TorBrowser
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 (closed). The maximum number of fonts per page should be governed by an about:config setting.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
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:
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.
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...
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?
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.
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.
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.
Trac: Actualpoints: N/Ato 10 Status: new to closed Resolution: N/Ato fixed