Add an option to only expose whitelisted system fonts to avoid fontlist fingerprinting (Tor 13313)

RESOLVED FIXED in Firefox 52

Status

()

Core
Graphics: Text
P3
normal
RESOLVED FIXED
3 years ago
3 months ago

People

(Reporter: jrmuizel, Assigned: arthuredelstein)

Tracking

(Blocks: 4 bugs, {privacy})

unspecified
mozilla52
privacy
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox52 fixed, firefox53-)

Details

(Whiteboard: [gfx-noted] [tor][fingerprinting])

Attachments

(2 attachments, 10 obsolete attachments)

25.35 KB, patch
jfkthame
: review+
Details | Diff | Splinter Review
14.73 KB, patch
jrmuizel
: review+
Details | Diff | Splinter Review
(Reporter)

Description

3 years ago
System font's can be used for fingerprinting. It would be nice if we had the option to only expose a per platform white list of fonts.
Keywords: privacy
Whiteboard: [gfx-noted]
jfkthame/jtd: Jeff suggested you would be good mentors for this bug; feel free to tag yourself as a mentor for it if you are willing and able :)

Updated

3 years ago
Summary: Add an option to not expose system fonts → Add an option to only expose whitelisted system fonts

Comment 2

3 years ago
Suggestions for whitelists:

Windows:
- all fonts in the union of WinXP/Win8 default installs
- fonts in Office
- fonts in Adobe Creative Suite

OSX:
- all fonts in union of OSX 10.6/10.10 default installs
- fonts in Office
- fonts in Adobe Creative Suite

Linux:
- fonts installed by default for Ubuntu/Debian/etc.

The whitelist should probably be the default lists above plus a an explicit whitelist in a pref.

Testing: view Wikipedia default page with/without whitelist active. Are there languages for which glyphs no longer appear when the whitelist is applied?

Updated

3 years ago
OS: Mac OS X → All
Hardware: x86 → All
Summary: Add an option to only expose whitelisted system fonts → Add an option to only expose whitelisted system fonts to avoid fontlist fingerprinting

Comment 3

2 years ago
I think the best mechanism that would be the least intrusive in current code would be to have a method in gfxPlatformFontList that filters out family names from mFontFamilies based on a per-platform whitelist. The whitelist would only be compiled when the appropriate build conditional was enabled.

There's a Tor project ticket for tracking this issue:
https://trac.torproject.org/projects/tor/ticket/13313
(Assignee)

Updated

2 years ago
Whiteboard: [gfx-noted] → [gfx-noted] [tor]
(Assignee)

Comment 4

2 years ago
Here's a patch in Tor Browser 5.04-alpha that exposes a "font.system.whitelist" pref. It's based on Firefox 38-ESR:

https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-38.1.0esr-5.0-1&id=2a36205b70076fc26145400addaa383142d71c81
(Assignee)

Comment 5

2 years ago
Created attachment 8681522 [details] [diff] [review]
0001-Bug-1121643-Add-font.system.whitelist-pref-to-resist.patch

This is the Tor Browser patch, rebased to mozilla-central. It provides a "font.system.whitelist" pref for Mac and Windows. If the pref exists and contains a comma-separated list of font family names, then only those font families are allowed to be used. If the pref is empty or not present, then all fonts are allowed.

For illustration and testing, here are the font families currently used by Tor Browser 5.5a:

Mac:
AppleGothic, Arial, Courier, Geneva, Georgia, Heiti TC, Helvetica, Helvetica Neue, Hiragino Kaku Gothic ProN, Lucida Grande, Monaco, Noto Sans Armenian, Noto Sans Bengali, Noto Sans Canadian Aboriginal, Noto Sans Cherokee, Noto Sans Devanagari, Noto Sans Ethiopic, Noto Sans Gujarati, Noto Sans Gurmukhi, Noto Sans Kannada, Noto Sans Khmer, Noto Sans Lao, Noto Sans Malayalam, Noto Sans Mongolian, Noto Sans Myanmar, Noto Sans Oriya, Noto Sans Sinhala, Noto Sans Tamil, Noto Sans Telugu, Noto Sans Thaana, Noto Sans Tibetan, Noto Sans Yi, STHeiti, Tahoma, Thonburi, Times, Times New Roman, Verdana

Windows:
Arial, Batang, Courier New, Euphemia, Gautami, Georgia, Gulim, GulimChe, Iskoola Pota, Kalinga, Kartika, Latha, Lucida Console, MS Gothic, MS Mincho, MS PGothic, MS PMincho, MV Boli, Mangal, Microsoft Himalaya, Microsoft YaHei, MingLiU, Noto Sans Buginese, Noto Sans Khmer, Noto Sans Lao, Noto Sans Myanmar, Noto Sans Yi, Nyala, PMingLiU, Plantagenet Cherokee, Raavi, Segoe UI, Shruti, SimSun, Sylfaen, Tahoma, Times New Roman, Tunga, Verdana, Vrinda

Please note that the "Noto" fonts are currently bundled with Tor Browser, but all other fonts are long-time built-in system fonts for OS X and Windows.

Try server results: https://treeherder.mozilla.org/#/jobs?repo=try&revision=5611a227770d
Builds can be downloaded from these results for testing.

(For Linux, we are currently used a fontconfig file to restrict available fonts to a font directory bundled in the application. We avoid whitelisting any built-in system fonts, which are not homogeneous between Linux flavors.)
Attachment #8681522 - Flags: review?(jdaggett)

Comment 6

2 years ago
Comment on attachment 8681522 [details] [diff] [review]
0001-Bug-1121643-Add-font.system.whitelist-pref-to-resist.patch

Review of attachment 8681522 [details] [diff] [review]:
-----------------------------------------------------------------

> +/* static */
> +nsTHashtable<nsStringHashKey>* gfxFontUtils::sWhitelistFamilyNames = nullptr;
> +
> +/* static */
> +bool
> +gfxFontUtils::IsFontFamilyNameAllowed(const nsAString& aFontFamilyName)
> +{

This isn't the right place for this. This is a method that should hang off gfxPlatformFontList. And rather than keep polling the pref, you should build a hash of the names in the preflist (each lower-cased since font name matching is case-insensitive) and use that to check each against the hash.

The other thing you're missing here is that fonts can be referenced via (1) font family names in fontlists and (2) via the use of src: local() within @font-face rules. On some platforms (e.g. DirectWrite) not adding a family will effectively remove it from the list of local font names but that's not true under OSX. For local lookups on platforms that use platform routines for lookup, you'll need to keep the whitelist hash around and check the hash after looking up a local name.

Also, if you want to implement this feature as something to land on Gecko trunk, it needs to be applied across all platforms, not just DirectWrite/OSX/GDI.
Attachment #8681522 - Flags: review?(jdaggett) → review+

Updated

2 years ago
Attachment #8681522 - Flags: review+ → review-
(Assignee)

Comment 7

2 years ago
(In reply to John Daggett (:jtd) from comment #6)
> Comment on attachment 8681522 [details] [diff] [review]
> 0001-Bug-1121643-Add-font.system.whitelist-pref-to-resist.patch
> 
> Review of attachment 8681522 [details] [diff] [review]:
> -----------------------------------------------------------------

Thanks for the review!

> > +/* static */
> > +nsTHashtable<nsStringHashKey>* gfxFontUtils::sWhitelistFamilyNames = nullptr;
> > +
> > +/* static */
> > +bool
> > +gfxFontUtils::IsFontFamilyNameAllowed(const nsAString& aFontFamilyName)
> > +{
> [snip]
> And rather than keep polling the pref, you should build
> a hash of the names in the preflist (each lower-cased since font name
> matching is case-insensitive) and use that to check each against the hash.

I believe that's what I did in that function. It only reads the pref the first time it runs.

> The other thing you're missing here is that fonts can be referenced via (1)
> font family names in fontlists and (2) via the use of src: local() within
> @font-face rules. On some platforms (e.g. DirectWrite) not adding a family
> will effectively remove it from the list of local font names but that's not
> true under OSX. For local lookups on platforms that use platform routines
> for lookup, you'll need to keep the whitelist hash around and check the hash
> after looking up a local name.

Thanks for catching this omission. Indeed I confirmed that my whitelisting patch fails on OS X work on fonts loaded by `src: local()`.

> Also, if you want to implement this feature as something to land on Gecko
> trunk, it needs to be applied across all platforms, not just
> DirectWrite/OSX/GDI.

That sounds reasonable. Do you think there is any place I can insert a single whitelisting mechanism that would operate outside the specific platform implementation code? It seems messy to be working with each platform-specific file, but despite a lot of staring at the code, I couldn't seem to find an easier way.
Flags: needinfo?(jdaggett)

Comment 8

2 years ago
(In reply to Arthur Edelstein from comment #7)

> > And rather than keep polling the pref, you should build
> > a hash of the names in the preflist (each lower-cased since font name
> > matching is case-insensitive) and use that to check each against the hash.
> 
> I believe that's what I did in that function. It only reads the pref the
> first time it runs.

Argh, yes indeed you did!

> > Also, if you want to implement this feature as something to land on Gecko
> > trunk, it needs to be applied across all platforms, not just
> > DirectWrite/OSX/GDI.
> 
> That sounds reasonable. Do you think there is any place I can insert a
> single whitelisting mechanism that would operate outside the specific
> platform implementation code? It seems messy to be working with each
> platform-specific file, but despite a lot of staring at the code, I couldn't
> seem to find an easier way.

Create a helper routine on gfxPlatformFontList that does the whitelist initialization and initializes an nsAutoPtr to the hash. Call that routine from within gfxPlatformFontList::InitFontList. Within the various versions of FindFamily, *if* the hash exists, check the name against the hash.

Handling src: local() is going to be a bit trickier, you'll probably want to do that in a separate patch. You'll need to do a check of the family name within each of the versions of LookupLocalFont. The Windows versions lookup an existing gfxFontEntry, which has a family name associated with it, so you can check the family name against the white list hash. Here too, please check for the existence of the hash to minimize the perf impact when no whitelist exists.

The OSX version does the lookup via an OS routine, so you'll need to figure out the OSX call to get the family name. For the gfxFcPlatformFontList and gfxFT2FontList versions, you'll need to check the family name of the font pattern/entry within LookupLocalFont.
Flags: needinfo?(jdaggett)

Comment 9

2 years ago
(In reply to John Daggett (:jtd) from comment #8)

> Handling src: local() is going to be a bit trickier, you'll probably want to
> do that in a separate patch. You'll need to do a check of the family name
> within each of the versions of LookupLocalFont. The Windows versions lookup
> an existing gfxFontEntry, which has a family name associated with it, so you
> can check the family name against the white list hash. Here too, please
> check for the existence of the hash to minimize the perf impact when no
> whitelist exists.

Thinking about this part a bit more, I think it might be simpler to just ban src: local() references when using a whitelist. That would be *much* simpler to implement, just check the pref within all the derived instances of LookupLocalFont.

Comment 10

2 years ago
Arthur, anything I can do to help you here? Are you working on a revised patch?
Flags: needinfo?(arthuredelstein)
(Assignee)

Comment 11

2 years ago
Created attachment 8696399 [details] [diff] [review]
0001-Bug-1121643-Add-font.system.whitelist-pref-to-resist.patch

(In reply to John Daggett (:jtd) from comment #10)
> Arthur, anything I can do to help you here? Are you working on a revised
> patch?

Thanks, John -- here's my latest version of the patch. I moved IsFontFamilyNameAllowed to gfxPlatformFontList. I added whitelisting for the fontconfig and freetype 2 implementations. (I think that covers all platforms now, correct?)

I also added whitelisting to src:local declarations.

try server results: https://treeherder.mozilla.org/#/jobs?repo=try&revision=8cdb843ffca8
Attachment #8681522 - Attachment is obsolete: true
Attachment #8696399 - Flags: review?(jdaggett)
(Assignee)

Updated

2 years ago
Flags: needinfo?(arthuredelstein)
(Assignee)

Comment 12

2 years ago
Created attachment 8711379 [details] [diff] [review]
0001-Bug-1121643-Add-font.system.whitelist-pref-to-resist.patch

I found a simpler way to whitelist fonts, which doesn't require any platform-specific changes. (The src:local code remains the same.)
Attachment #8696399 - Attachment is obsolete: true
Attachment #8696399 - Flags: review?(jd.bugzilla)
Attachment #8711379 - Flags: review?(jd.bugzilla)

Comment 13

2 years ago
Comment on attachment 8711379 [details] [diff] [review]
0001-Bug-1121643-Add-font.system.whitelist-pref-to-resist.patch

Review of attachment 8711379 [details] [diff] [review]:
-----------------------------------------------------------------

> +/* static */
> +nsTHashtable<nsStringHashKey>* gfxPlatformFontList::sWhitelistFamilyNames = nullptr;

This doesn't really feel like something that should be static. Please make it a member of gfxPlatformFontList instead:

  nsAutoPtr<nsTHashtable<nsStringHashKey>> mWhitelistFamilyNames;

Initialize it within gfxPlatformFontList::InitFontList, then use the existence of mWhitelistFamilyNames as a way to flag "allow all fonts". That's going to be the very common default for all platforms so we need to make this case as fast a possible.

> +bool
> +gfxPlatformFontList::IsFontFamilyNameAllowed(const nsAString& aFontFamilyName)
> +{
> +    if (!sWhitelistFamilyNames) {
> +        sWhitelistFamilyNames = new nsTHashtable<nsStringHashKey>();
> +        nsAutoTArray<nsString, 10> list;
> +        gfxFontUtils::GetPrefsFontList("font.system.whitelist", list);

Font family name lookups always happen so there's no point to lazy loading this. As mentioned above, do this in InitFontList. If the list has zero length don't create the hash.

> +    return sWhitelistFamilyNames->Count() == 0 ||
> +           sWhitelistFamilyNames->Contains(fontFamilyNameLower);

  return mWhitelistFamilyNames && mWhitelistFamilyNames->Contains(fontFamilyNameLower));

> +        void Put(KeyType familyName, already_AddRefed<gfxFontFamily> familyData) {
> +            if (IsFontFamilyNameAllowed(familyName)) {
> +                nsRefPtrHashtable<nsStringHashKey, gfxFontFamily>::Put(familyName, mozilla::Move(familyData));
> +            }
> +        }
> +        void Put(KeyType familyName, const UserDataType& familyData) {
> +            if (IsFontFamilyNameAllowed(familyName)) {
> +                nsRefPtrHashtable<nsStringHashKey, gfxFontFamily>::Put(familyName, familyData);
> +            }
> +        }

Use the method gfxPlatformFontList::PlatformFontList() to get a pointer to the singleton platform fontlist object, then call the non-static IsFontFamilyNameAllowed method.

> +            gfxFontEntry* fe = nullptr;
> +            if (gfxPlatformFontList::IsFontFamilyNameAllowed(currSrc.mLocalName)) {
> +                fe =  gfxPlatform::GetPlatform()->LookupLocalFont(currSrc.mLocalName,
> +                                                                  mWeight,
> +                                                                  mStretch,
> +                                                                  mStyle);

This is incorrect, local names aren't the same as family names. For example, the Arial family is made up of "Arial", "Arial Bold", "Arial Italic", etc.

I think for the whitelisting case simply blocking all use of local() is better. That's much simpler to implement and get right. Since local() typically only matches once in a while, this isn't really a big feature change. So just create a simple bool check for whether mWhitelistFamilyNames is null or not.

I think you'll also need an observer method for the font, so that if the user edits the "font.system.whitelist" pref, the whitelist will automatically be updated. The code in gfxFontListPrefObserver::Observe will need to call UpdateFontList() when that pref changes.
Attachment #8711379 - Flags: review?(jd.bugzilla) → review-
Created attachment 8763472 [details] [diff] [review]
0001-Bug-1121643-Add-font.system.whitelist-pref-to-resist.patch

(In reply to John Daggett (:jtd) from comment #13)
> Comment on attachment 8711379 [details] [diff] [review]
> 0001-Bug-1121643-Add-font.system.whitelist-pref-to-resist.patch
> 
> Review of attachment 8711379 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
>  [snip]

Thank you for the review. Here is a new version of the patch, with all changes you suggested, and updated to apply to the latest mozilla-central code.
Assignee: nobody → arthuredelstein
Attachment #8711379 - Attachment is obsolete: true
Attachment #8763472 - Flags: review?(jd.bugzilla)
(Assignee)

Updated

a year ago
Blocks: 732096
(Reporter)

Updated

a year ago
Flags: needinfo?(jmuizelaar)
(Reporter)

Comment 15

a year ago
John Daggett is no longer at Mozilla so I don't know if or when he'll get to this review. You might want to try Jonathan Kew instead.
Flags: needinfo?(jmuizelaar)
Comment on attachment 8763472 [details] [diff] [review]
0001-Bug-1121643-Add-font.system.whitelist-pref-to-resist.patch

(In reply to Jeff Muizelaar [:jrmuizel] from comment #15)
> John Daggett is no longer at Mozilla so I don't know if or when he'll get to
> this review. You might want to try Jonathan Kew instead.

Thanks -- switching review request to Jonathan.
Attachment #8763472 - Flags: review?(jd.bugzilla) → review?(jfkthame)
(Assignee)

Updated

a year ago
Status: NEW → ASSIGNED
Comment on attachment 8763472 [details] [diff] [review]
0001-Bug-1121643-Add-font.system.whitelist-pref-to-resist.patch

Review of attachment 8763472 [details] [diff] [review]:
-----------------------------------------------------------------

Have you considered what will happen if the whitelist is non-empty, but does not list any names that are actually present on the platform? It looks to me like that will be problematic, because gfxPlatformFontList will refuse to provide -any- fonts, and Gecko gets unhappy if it doesn't have a valid font to use.
Comment on attachment 8763472 [details] [diff] [review]
0001-Bug-1121643-Add-font.system.whitelist-pref-to-resist.patch

Review of attachment 8763472 [details] [diff] [review]:
-----------------------------------------------------------------

There are a number of changes in the patch (e.g. in gfxFT2FontList.cpp, also a couple other places) where raw pointers (gfxFontFamily* etc) are replaced with RefPtr<...>. It's not clear to me that those are necessary (and if they're not, then they just add overhead). Can you revert those changes, or are they actually needed?
(In reply to Jonathan Kew (:jfkthame) from comment #18)
> Comment on attachment 8763472 [details] [diff] [review]
> 0001-Bug-1121643-Add-font.system.whitelist-pref-to-resist.patch
> 
> Review of attachment 8763472 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> There are a number of changes in the patch (e.g. in gfxFT2FontList.cpp, also
> a couple other places) where raw pointers (gfxFontFamily* etc) are replaced
> with RefPtr<...>. It's not clear to me that those are necessary (and if
> they're not, then they just add overhead). Can you revert those changes, or
> are they actually needed?

Those are actually needed. I discovered those leaks while running regression tests on the try server.
(In reply to Jonathan Kew (:jfkthame) from comment #17)
> Comment on attachment 8763472 [details] [diff] [review]
> 0001-Bug-1121643-Add-font.system.whitelist-pref-to-resist.patch
> 
> Review of attachment 8763472 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Have you considered what will happen if the whitelist is non-empty, but does
> not list any names that are actually present on the platform? It looks to me
> like that will be problematic, because gfxPlatformFontList will refuse to
> provide -any- fonts, and Gecko gets unhappy if it doesn't have a valid font
> to use.

I think you are right that this may be a problem. I will look into how to fix it.
Created attachment 8767370 [details] [diff] [review]
0001-Bug-1121643-Add-font.system.whitelist-pref-to-resist.patch

Here's a new version that sets the "font.system.whitelist" pref to empty if the whitelist contains no fonts present on the system. In that (hopefully unusual) situation, whitelisting turns off.
Attachment #8763472 - Attachment is obsolete: true
Attachment #8763472 - Flags: review?(jfkthame)
Attachment #8767370 - Flags: review?(jfkthame)
Created attachment 8767376 [details] [diff] [review]
0001-Bug-1121643-Add-font.system.whitelist-pref-to-resist.patch

(Fixing a small mistake.)
Attachment #8767370 - Attachment is obsolete: true
Attachment #8767370 - Flags: review?(jfkthame)
Attachment #8767376 - Flags: review?(jfkthame)
Created attachment 8767518 [details] [diff] [review]
0001-Bug-1121643-Add-font.system.whitelist-pref-to-resist.patch

I made a some more changes to fix failing tests.

try server results: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ab421eef92ed
Attachment #8767376 - Attachment is obsolete: true
Attachment #8767376 - Flags: review?(jfkthame)
Attachment #8767518 - Flags: review?(jfkthame)
Comment on attachment 8767518 [details] [diff] [review]
0001-Bug-1121643-Add-font.system.whitelist-pref-to-resist.patch

Review of attachment 8767518 [details] [diff] [review]:
-----------------------------------------------------------------

This seems pretty workable, but there are a few aspects where I think I'd prefer a slightly different approach to the code; please see notes below, and consider whether they're feasible adjustments.

::: gfx/thebes/gfxDWriteFontList.h
@@ +423,4 @@
>       * Table of font substitutes, we grab this from the registry to get
>       * alternative font names.
>       */
> +    FontFamilyTable mFontSubstitutes {true};

This is very cryptic; it at least needs a comment explaining the {true}.

However, I think I'd prefer an approach where the decision whether to apply a whitelist is made explicitly at the callsites that add entries to the font tables; ISTM that would make things easier to follow. E.g. we could add a whitelist parameter (which could be a const nsTHashtable<nsStringHashKey>*) to the FontFamilyTable::Put() method, and let callers pass nullptr to apply no whitelist, or a pointer to the table of acceptable names.

::: gfx/thebes/gfxPlatformFontList.cpp
@@ +446,5 @@
> +    // Check that the whitelist hasn't blocked ALL available fonts:
> +    if (mFontFamilies.Count() == 0 && !mFamilyNamesWhitelist.IsEmpty()) {
> +        // We have loaded no fonts! Wipe the bad whitelist and
> +        // load without whitelisting.
> +        Preferences::SetCString(kFontSystemWhitelistPref, "");

I'm not sure about actually modifying the pref here; that seems unexpected. Can we just clear the in-memory whitelist and try again, but leave the user's pref untouched?

Also, this isn't the only place InitFontList() can be called from, IIRC. The platform implementations of CreatePlatformFontList() also call it, so don't they need a similar check? Or we should refactor things a bit so that there's a common bottleneck where the check can be done for all callers.

::: gfx/thebes/gfxPlatformFontList.h
@@ +372,4 @@
>                              eFontPrefLang aPrefLang,
>                              nsTArray<RefPtr<gfxFontFamily>>* aGenericFamilies);
>  
> +    class FontFamilyTable : public nsRefPtrHashtable<nsStringHashKey, gfxFontFamily> {

This class leaves me just a bit uneasy.... I don't think we really expect/intend nsRefPtrHashtable to be subclassed like this. Note that the Put method is -not- a virtual method, so it can't really be "overridden" in the usual C++ sense. It works in this patch because we never end up dealing with FontFamilyTable via a base-class pointer, but it feels hacky.

Could we instead do something more along the lines of:

    class FontFamilyTable
    {
    private:
        nsRefPtrHashtable<nsStringHashKey, gfxFontFamily> mFamilies;

    public:
        void Put(....) {
            // check whitelist, then forward to mFamilies.Put()
        }
        bool Get(....) {
            // just forward to mFamilies.Get()
        }
    }

etc?

@@ +474,5 @@
>      nsCOMPtr<nsILanguageAtomService> mLangService;
>      nsTArray<uint32_t> mCJKPrefLangs;
>      nsTArray<mozilla::FontFamilyType> mDefaultGenericsLangGroup;
> +
> +    nsTHashtable<nsStringHashKey> mFamilyNamesWhitelist;

Given that the whitelist is only used during InitFontList (right?) to filter the names we put into the FontFamilyTable, I don't think there's any need for gfxPlatformFontList to hold onto it in a member variable. Just read the pref into a local hash at the beginning of InitFontList, and let it go away when we're finished with it; all we need thereafter is a bool flag for whether src:local should be blocked.

::: gfx/thebes/gfxTextRun.cpp
@@ +1817,4 @@
>      bool needsBold;
>      gfxPlatformFontList *pfl = gfxPlatformFontList::PlatformFontList();
>      gfxFontFamily *defaultFamily = pfl->GetDefaultFont(&mStyle);
> +    NS_ASSERTION(defaultFamily || pfl->IsFontFamilyWhitelistActive(),

Instead of the whitelist-active exception here, can we modify GetDefaultFont so that it always returns something valid? It was meant to be a last-ditch method that code can rely on to get a usable font when all else fails. (Oh, and note that this isn't the only callsite.)

If the platform's usual "default" font has been excluded by the whitelist, GetDefaultFont should still return -something- usable, IMO. Even if it's as basic as "the first family in the font list".
Priority: -- → P1
Priority: P1 → P3
Created attachment 8774405 [details] [diff] [review]
0001-Bug-1121643-Add-font.system.whitelist-pref-to-resist.patch

Hi Jonathan -- thank you for the review. Here is a revised version of the patch taking into account all your suggestions. It required a some refactoring of the ::InitFontList and ::GetDefaultFont functions.

To summarize: I decided to introduce an ::ApplyWhitelist() function that runs at the end of ::InitFontList(), removing all fonts from mFontFamilies not in the whitelist.
Attachment #8767518 - Attachment is obsolete: true
Attachment #8767518 - Flags: review?(jfkthame)
Attachment #8774405 - Flags: review?(jfkthame)
Comment on attachment 8774405 [details] [diff] [review]
0001-Bug-1121643-Add-font.system.whitelist-pref-to-resist.patch

Review of attachment 8774405 [details] [diff] [review]:
-----------------------------------------------------------------

This looks basically fine; a few minor notes below re comments, style, etc. that would be good to tidy up.

I've realized there may be an additional issue to consider with regard to how system font fallback behavior is implemented on Windows and/or OS X; I plan to look into that a little further to see if it's something we need to address here, or if it'll be OK as is. I'll set need-info on myself as a reminder to follow up...

::: gfx/tests/mochitest/test_font_whitelist.html
@@ +34,5 @@
> +  return yield SpecialPowers.pushPrefEnv({"set": [["font.system.whitelist", val]]});
> +}
> +
> +// Run a test to see that we don't expose the supported mimeTypes
> +// or installed plugins when "privacy.resistFingerprinting" is active.

This comment looks like it belonged to a different testcase!

@@ +40,5 @@
> +  yield setFontWhitelist("Arial, DejaVu Sans, Roboto");
> +  ok(getWidth(1) === getWidth(2) && getWidth(2) === getWidth(3), "Sans only");
> +  yield setFontWhitelist("Courier New, DejaVu Sans Mono, Droid Sans Mono");
> +  ok(getWidth(1) === getWidth(2) && getWidth(2) === getWidth(3), "Mono only");
> +  yield setFontWhitelist("Georgia, DejaVu Serif, Droid Serif");

Here and below, I think you should probably include Times in the list of serif fonts, instead of (or in addition to) Georgia, as that's more likely to be configured as the default mapping for 'serif'.

::: gfx/thebes/gfxDWriteFontList.h
@@ +360,2 @@
>  
> +    virtual gfxFontFamily* GetDefaultFontForPlatform(const gfxFontStyle* aStyle) override;

This looks >80 chars long; please wrap (after the return type), as previously. Likewise in the other .h files where this occurs.

::: gfx/thebes/gfxPlatformFontList.cpp
@@ +200,4 @@
>      NS_ADDREF(gFontListPrefObserver);
>      Preferences::AddStrongObservers(gFontListPrefObserver, kObservedPrefs);
>  
> +    Preferences::RegisterCallback(FontWhitelistPrefChanged, kFontSystemWhitelistPref);

line length

@@ +211,4 @@
>      ClearLangGroupPrefFonts();
>      NS_ASSERTION(gFontListPrefObserver, "There is no font list pref observer");
>      Preferences::RemoveObservers(gFontListPrefObserver, kObservedPrefs);
> +    Preferences::UnregisterCallback(FontWhitelistPrefChanged, kFontSystemWhitelistPref);

line length

@@ +220,5 @@
>  
> +void
> +gfxPlatformFontList::ApplyWhitelist()
> +{
> +    AutoTArray<nsString, 10> list;

10 seems very small for the potential whitelist length, so it's likely to spill over to heap allocation anyway. Either increase this so that it's big enough to accommodate the whole list in typical scenarios (there are around 40 in the example lists in comment 5, so maybe AutoTArray<nsString,100> to be generous), or else forget the AutoTArray optimization and just make it a normal nsTArray. I doubt the perf difference will be significant compared to the whole InitFontList process.

@@ +284,5 @@
>  
>      sPlatformFontList = this;
>  
> +    nsresult rv = InitFontListForPlatform();
> +    NS_ENSURE_SUCCESS(rv, rv);

We're generally moving away from macros like NS_ENSURE_SUCCESS that "hide" potential control flow surprises. I think I'd prefer this written as:

    if (NS_SUCCEEDED(rv)) {
        ApplyWhitelist();
    }
    return rv;

or something similarly explicit.

@@ +1199,5 @@
> +    gfxFontFamily* family = GetDefaultFontForPlatform(aStyle);
> +    if (family) {
> +        return family;
> +    }
> +    return mFontFamilies.Iter().Data();

A comment would be nice here, explaining that this is a last resort if the usual platform method fails.

::: gfx/thebes/gfxPlatformFontList.h
@@ +156,5 @@
>  
>      // get the system default font family
> +    gfxFontFamily* GetDefaultFont(const gfxFontStyle* aStyle);
> +    virtual
> +    gfxFontFamily* GetDefaultFontForPlatform(const gfxFontStyle* aStyle) = 0;

Please add comments to clarify why there are these two different methods here.

Actually, the second one can be moved to the 'protected' section, can't it? It's purely an internal implementation detail, not part of the public API of gfxPlatformFontList. So let's enforce that, and then you can just add a comment that it's a platform-specific helper for GetDefaultFont.

Then we should also move it to 'protected' in the various subclasses.

::: gfx/thebes/gfxTextRun.cpp
@@ +1817,4 @@
>      bool needsBold;
>      gfxPlatformFontList *pfl = gfxPlatformFontList::PlatformFontList();
>      gfxFontFamily *defaultFamily = pfl->GetDefaultFont(&mStyle);
> +    NS_ASSERTION(defaultFamily || pfl->IsFontFamilyWhitelistActive(),

With the fallback in GetDefaultFont, I don't think you need to add the IsFontFamilyWhitelistActive() alternative here, do you? We expect GetDefaultFont() to return something usable, no matter what.
Attachment #8774405 - Flags: review?(jfkthame) → feedback+
Flags: needinfo?(jfkthame)
OK, my suspicions were right -- there's an unfortunate interaction here with font fallback, and I think we need to figure out a way to address it.

Testcase: on Mac OS X (10.9, but probably behaves similarly on other versions), set font.system.whitelist to "Helvetica,Arial". Then go to http://www.unicode.org/standard/WhatIsUnicode.html and observe the links to different translations on the left-hand side.

Many of the non-Latin links there will appear as hexboxes because none of the available fonts support the necessary characters; that's expected, with such a limited whitelist. Note, however, that the first link (for Arabic) is fine; again, that's expected, because Arial includes Arabic support.

Now click that link, to go to http://www.unicode.org/standard/translations/arabic.html. Result: the body text (which should be Arabic script, and ought to be able to render with Arial) displays entirely as hexboxes, except for the occasional Latin-script words within it.

That body text is styled with font-family:tahoma, but we've excluded Tahoma from the whitelist. So then fallback is required; and as Arial is available, we'd expect it to work OK. The problem, however, is that the Core Text-based font fallback code doesn't know about our whitelist, and probably tells us to use Geeza Pro. But then we try to look that up, and it's not in our font list. So then we give up and just use Helvetica (from the default font prefs). And that doesn't support Arabic; hence, hexboxes (even though we *could* render that text with one of the whitelisted fonts).

I suspect there will be similar issues on Windows, because we have similar platform-specific code paths to find fallback fonts there, and they likewise won't know to avoid picking non-whitelisted fonts.
Flags: needinfo?(jfkthame)
Comment on attachment 8774405 [details] [diff] [review]
0001-Bug-1121643-Add-font.system.whitelist-pref-to-resist.patch

Review of attachment 8774405 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/thebes/gfxDWriteFontList.cpp
@@ +343,4 @@
>  }
>  
>  already_AddRefed<IDWriteFont>
> +gfxDWriteFontFamily::GetDefaultFontForPlatform()

Oops, this is the wrong GetDefaultFont() to be renaming in this file!
Created attachment 8776340 [details] [diff] [review]
0001-Bug-1121643-Add-font.system.whitelist-pref-to-resist.patch

Thanks again for the review. For the record here's a new version of the patch that should fix all the problems noted in comment 26 and comment 28. I still need to investigate the font fallback issue in comment 27, so I'm not asking for another review right now.
Attachment #8774405 - Attachment is obsolete: true
Created attachment 8783813 [details] [diff] [review]
0001-Bug-1121643-Add-font.system.whitelist-pref-to-resist.patch

Here's the patch again, revised to fix the font fallback issue on Windows and Mac (in both cases, see `bool useCmaps = ...`).

Also, I modified the mochitest to use whatever fonts it discovers on the test machine.

Try results: https://treeherder.mozilla.org/#/jobs?repo=try&revision=7938c26cd18d
Attachment #8776340 - Attachment is obsolete: true
Attachment #8783813 - Flags: review?(jfkthame)
(Assignee)

Updated

a year ago
Summary: Add an option to only expose whitelisted system fonts to avoid fontlist fingerprinting → Add an option to only expose whitelisted system fonts to avoid fontlist fingerprinting (Tor 13133)
Thanks for the update; yes, that looks like the simplest fix for the fallback issue. It may mean that enabling the whitelist affects the fallback behavior in some cases, as it causes us to switch to the generic algorithm, but I think that's OK.

Unfortunately, the try run seems to be hitting an assertion in test_font_whitelist on Android (see the M18 job on Android 4.3 debug); I'm not yet sure what that's about. I've pushed another try job (https://treeherder.mozilla.org/#/jobs?repo=try&revision=68d5db7cbe5f) based on latest mozilla-central to see whether this persists; if so, we'll need to investigate and see what's actually happening.
Tryserver says this keeps happening :( so we'll need to get to the bottom of it before we can consider landing the patch; right now it turns Android M18 permanently orange, though I don't know why.
Looks like a couple of the tests are triggering NS_ASSERTIONs. You can see the assertions if you open the logcat ("artifact uploaded: logcat-emulator-5554.log" in the Job Details pane) and look for assertion output interleaved in the test output.
Yeah.... but (a) I don't currently understand why test_font_whitelist.html (the new test here) should trigger the assertion, and (b) we're also seeing the assertion appear on test_animation_operators.html, which hasn't been touched and should not be affected by the font-list changes in any way, AFAICS.
(In reply to Jonathan Kew (:jfkthame) from comment #34)
> Yeah.... but (a) I don't currently understand why test_font_whitelist.html
> (the new test here) should trigger the assertion, and (b) we're also seeing
> the assertion appear on test_animation_operators.html, which hasn't been
> touched and should not be affected by the font-list changes in any way,
> AFAICS.

Thanks for looking into this. I'm presently running a try test that will, I hope, log a stack trace for these assertions:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=4001d2365c3c&selectedJob=26603617
Well, unfortunately that still didn't produce stack traces. So I'm looking for other ways to figure it out.
You could change the NS_ASSERTION to a MOZ_CRASH or a MOZ_ASSERT, I think both of those produce stack traces. The former at least should.

Updated

a year ago
Blocks: 1260929
(Assignee)

Updated

a year ago
Summary: Add an option to only expose whitelisted system fonts to avoid fontlist fingerprinting (Tor 13133) → Add an option to only expose whitelisted system fonts to avoid fontlist fingerprinting (Tor 13313)
(Assignee)

Comment 38

11 months ago
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #37)
> You could change the NS_ASSERTION to a MOZ_CRASH or a MOZ_ASSERT, I think
> both of those produce stack traces. The former at least should.

I tried both of these, but I was unable to get a stack trace to print. I also ran the mochitest on my own computer, by creating a debug build of Fennec-x86 and running the mochitest in the Android emulator with --debugger=gdb. Unfortunately, all the tests passed and unfortunately I didn't see any asserts. Maybe the asserts only get hit in the ARM build.

So I'm pretty stumped. Any other ideas how I might get a stack trace?
Hm, that's odd. Did you get stack traces at all? Or just stack traces with no symbols? You might not see them in a local build if they're racy, I often have assertions that only show up on tryserver but not locally.

I'm kind of surprised if no stack traces are showing up in either the regular build log or the logcat output, that might be something we should file a bug about.
(Assignee)

Comment 40

11 months ago
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #39)
> Hm, that's odd. Did you get stack traces at all? Or just stack traces with
> no symbols? You might not see them in a local build if they're racy, I often
> have assertions that only show up on tryserver but not locally.
> 
> I'm kind of surprised if no stack traces are showing up in either the
> regular build log or the logcat output, that might be something we should
> file a bug about.

So I ran them again, and realized I didn't remember all the details exactly. When I change the offending Assertion to MOZ_CRASH, it weirdly produces an extra error (in a seemingly unrelated test, test_bug231389.html), with a stack trace. But I only see a stack trace associated with that error, not with the original test_font_whitelist.htm/test_animation_operators.html errors. 

Here are the tests with NS_ASSERTION:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=4d933e570536&selectedJob=27593162

Here they are with MOZ_CRASH:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=52e935fda9f4&selectedJob=27593174

Do you have any ideas about what might be going on here? The new error at least seems to have something to do with removing nsIObservers at shutdown time.
Ok, so it looks like MOZ_CRASH does give you a stack trace. However the NS_ASSERTION you changed in your second push seems unrelated to the assertion that was failing in the first push. According to the logcat in your first push, the assertion failing is this one:

###!!! ASSERTION: Existing entry in disk StartupCache.: 'zipItem == nullptr', file /home/worker/workspace/build/src/startupcache/StartupCache.cpp, line 357

I've done a new try push for you which adds a MOZ_CRASH for this assertion, here:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=642b5049b863

Hopefully this will give you a stack for the offending assertion.
Sorry, I typo'd MOZ_ASSERT instead of MOZ_CRASH in that one, so the build failed. Let me try again:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=93d52727a3f4
Thanks for helping this along, Kats.

Now I see where the problem is coming from, I think. The issue is with how gfxFT2FontList caches the font names in the StartupCache, to accelerate launch times. This normally works fine, but it triggers this assertion if the font list is rebuilt (and therefore the caching gets re-done); StartupCache doesn't like that.

So this has been kinda broken all along, but we didn't notice because nothing normally triggers rebuilding of the font list during a run. But changing the font whitelist will trigger it, and therefore that testcase asserts.

I think we can fix this by reworking the FontNameCache so that it doesn't actually try to stash anything in the StartupCache until shutdown time, instead of doing it as soon as it has built the list. That way, even if the list gets rebuilt multiple times during a run, we'll still only cache it once.
Created attachment 8792218 [details] [diff] [review]
Ensure the FontNameCache only updates its records in StartupCache once, even if the font-list is rebuilt

I believe this will prevent the problematic assertion being triggered. Let's see how tryserver likes it: https://treeherder.mozilla.org/#/jobs?repo=try&revision=bc72517b4407.
Attachment #8792218 - Flags: review?(bugmail)
Comment on attachment 8792218 [details] [diff] [review]
Ensure the FontNameCache only updates its records in StartupCache once, even if the font-list is rebuilt

Review of attachment 8792218 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry but i don't know this code at all, so I'm probably not a good reviewer.
Attachment #8792218 - Flags: review?(bugmail)
(Assignee)

Comment 46

11 months ago
(In reply to Jonathan Kew (:jfkthame) from comment #44)
> Created attachment 8792218 [details] [diff] [review]
> Ensure the FontNameCache only updates its records in StartupCache once, even
> if the font-list is rebuilt
> 
> I believe this will prevent the problematic assertion being triggered. Let's
> see how tryserver likes it:
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=bc72517b4407.

We should run the mochitests tc-M(18) to make sure they pass now. I tried to trigger it but somehow I don't seem to be able to.
(Assignee)

Comment 47

11 months ago
On philor's suggestion, I rebased to the latest mozilla-central and push the two patches again, to check tc-M(18):

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a5c8f65852af

Updated

11 months ago
Attachment #8792218 - Flags: review?(jmuizelaar)
Argh -- that is of course the test I meant to run on my try push, not R18! OK, let's see how it goes...
The first M18 has just come back....green. :) So I think there's hope for this. I've triggered a bunch of re-tests, to confirm that it truly is green, and won't show up even intermittently.
Hmm... so, the assertion in test_font_whitelist.html definitely seems to be gone, but on 3/10 runs, I got the crash in test_bug231389.html (as mentioned in comment 40).

The stack there looks like we're in the midst of trying to update the cached font name info in the StartupCache during XPCOM shutdown. Which sounds suspiciously like it could be a real issue related to the changes here. Maybe once we're into ShutdownXPCOM, it's too late to reliably be putting new stuff into the StartupCache?
Comment on attachment 8792218 [details] [diff] [review]
Ensure the FontNameCache only updates its records in StartupCache once, even if the font-list is rebuilt

Cancelling r? on this patch, as we still see some crashiness with it (see comment 50). I'm testing a revised version; will post it for review if tryserver says it's more reliable.
Attachment #8792218 - Flags: review?(jmuizelaar)
Created attachment 8792416 [details] [diff] [review]
Ensure the FontNameCache only updates its records in StartupCache once, even if the font-list is rebuilt

This avoids the problem of trying to update the StartupCache too late during shutdown by giving the font-list an observer for the xpcom-will-shutdown notification; this lets it do any necessary StartupCache update before we actually start tearing down XPCOM services. With this, tryserver seems happier: https://treeherder.mozilla.org/#/jobs?repo=try&revision=e904d6397031. (The two orange runs there are unrelated, existing intermittents.)
Attachment #8792416 - Flags: review?(jmuizelaar)

Updated

11 months ago
Attachment #8792218 - Attachment is obsolete: true
(Reporter)

Updated

11 months ago
Attachment #8792416 - Flags: review?(jmuizelaar) → review+
Comment on attachment 8783813 [details] [diff] [review]
0001-Bug-1121643-Add-font.system.whitelist-pref-to-resist.patch

Review of attachment 8783813 [details] [diff] [review]:
-----------------------------------------------------------------

OK, with the fix for the Android assertion (which wasn't really your fault, the whitelist test just exposed a pre-existing flaw) I think we could go ahead and take this patch. Arthur, any further thoughts or last-minute updates to consider before we try landing?

(And thanks for your patience here, I know it's taken a while to get to this point!)
Attachment #8783813 - Flags: review?(jfkthame) → review+
(Assignee)

Comment 54

11 months ago
(In reply to Jonathan Kew (:jfkthame) from comment #53)
> Comment on attachment 8783813 [details] [diff] [review]
> 0001-Bug-1121643-Add-font.system.whitelist-pref-to-resist.patch
> 
> Review of attachment 8783813 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> OK, with the fix for the Android assertion (which wasn't really your fault,
> the whitelist test just exposed a pre-existing flaw) I think we could go
> ahead and take this patch. Arthur, any further thoughts or last-minute
> updates to consider before we try landing?

No, I'm not aware of any further issues.

> (And thanks for your patience here, I know it's taken a while to get to this
> point!)

Not at all -- I hugely appreciate your help with this, Jonathan! Many thanks to you, Kartikaya, John and Jeff.
https://hg.mozilla.org/integration/mozilla-inbound/rev/1e11d10bd648150440e784bb7ce0b120319ef5b2
Bug 1121643 - Ensure the FontNameCache only updates its records in StartupCache once, even if the font-list is rebuilt. r=jrmuizel

https://hg.mozilla.org/integration/mozilla-inbound/rev/e688328c81ec31ebf184d9b9079c9a3582cc8fd3
Bug 1121643 - Add "font.system.whitelist" pref to resist font-based fingerprinting. r=jfkthame

Comment 56

11 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/1e11d10bd648
https://hg.mozilla.org/mozilla-central/rev/e688328c81ec
Status: ASSIGNED → RESOLVED
Last Resolved: 11 months ago
status-firefox52: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla52

Updated

11 months ago
Depends on: 1306715

Updated

10 months ago
Whiteboard: [gfx-noted] [tor] → [gfx-noted] [tor][fingerprinting]

Comment 57

8 months ago
This solution doesn't seem that good at what it tries to do.

The goal is to provide font fingerprinting protection. To do so, this solution asks the user or an extension to set a pref with a list of fonts to allow - all other fonts will then be forbidden. Right ?

If so, this will not decrease fingerprint as much as it could. Essentially, all user-set whitelists could very well be unique or very rare.

Why didn't you guys follow comment 2 ?
- Create a built-in default whitelist
- Create a boolean pref to toggle protection (Or better, use privacy.resistFingerprinting)
- Have font.system.whitelist be useful ONLY for those few users who have a problem and want to allow a font that isn't on the default whitelist. font.system.whitelist is empty by default and its content is added to the default whitelist as fonts are requested.

This way, ALL users who enable privacy.resistFingerprinting have the SAME font list. Only people with very specific problems will customize the whitelist. This is much better for privacy than this bug's solution, isn't it ?


I will create another bug suggesting this is done, unless you guys have a reason not to have followed comment 2 and the above proposition.


Note: Tor Browser can be fingerprinted if people have a...custom whitelist. Any customization that can be detected by a website is done at the expense of privacy. If we are building a fingerprint protection feature, might as well do it right. (Because doing it wrong is either subpar-ly useful or sometimes even harmful)

Comment 58

8 months ago
Correcting a missing word:
*Tor Browser can be fingerprinted if people have a...custom NOSCRIPT whitelist
(Assignee)

Comment 59

8 months ago
(In reply to Steph from comment #57)
> This solution doesn't seem that good at what it tries to do.

I agree it would be nice to activate font whitelisting when privacy.resistFingerprinting is set to true. Perhaps we could re-purpose "font.system.whitelist" to contain the default list, so that it would still be modifiable by users if they wish. (Fonts could be both added to or removed from the whitelist that way.) This would be a fairly minor modification to the existing implementation.

Tor Browser's current default whitelists are here. This list was developed by studying the list of fonts available on most Mac and Windows installations, and revised after getting feedback from users:
https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-tor-browser.js?h=tor-browser-45.6.0esr-6.5-1#n316

Unfortunately, Linux doesn't have a consistent set of fonts, so it's necessary to bundle fonts. And it helps to bundle fonts on Mac and Windows as well. Also, we don't yet have a whitelist for Android. So I think there would be significant work in developing an Android whitelist and deciding how to bundle fonts on the various platforms before default whitelists could be uplifted to Firefox.

Comment 60

8 months ago
(In reply to Arthur Edelstein [:arthuredelstein] from comment #59)
> Perhaps we could re-purpose
> "font.system.whitelist" to contain the default list, so that it would still
> be modifiable by users if they wish. (Fonts could be both added to or
> removed from the whitelist that way.) This would be a fairly minor
> modification to the existing implementation.

It would already be better than what we currently have indeed. My main point though is that fingerprinting protection is about looking like everyone else. If we were to have font.system.whitelist contain the default whitelist and a subset of users add a couple fonts to it (I see no use case for removing fonts from the default, it harms privacy), that will create fragmentation as the default whitelist gets updated in the future since these users will not get updates for their "user set" about:config pref.

Example:
- In 2016, default whitelist is fonts A and B. Subset of users X add font xA.
- In 2017, default whitelist gets updated, now it's fonts A, B and C. Subset of users Y add font yA.
- In 2018, default whitelist becomes A, B, C and D. Subset of users Z add font zA.
By 2019, we have:
- Most users with A, B, C, D
- A subset with A, B, xA
- A subset with A, B, C, yA
- A subset with A, B, C, D, zA

Alternatively, if the whitelist was separated from the custom list, by 2019 there would be a common A, B, C, D ground for all users regardless of customisation. That's slightly better for fingerprinting protection. Nothing ground breaking, but why not do it right ? Is it really more work to not surface the default whitelist in about:config and concatenate it with the custom one ?

Of course you guys do what you think is right, I'm just adding food for thought.


(In reply to Arthur Edelstein [:arthuredelstein] from comment #59)
> Unfortunately, Linux doesn't have a consistent set of fonts, 
> so it's necessary to bundle fonts. And it helps to bundle fonts 
> on Mac and Windows as well. Also, we don't yet have a whitelist 
> for Android. So I think there would be significant work in 
> developing an Android whitelist and deciding how to bundle fonts 
> on the various platforms before default whitelists could be uplifted to Firefox.

I agree it represents work, but if it's **** we provide a false sense of privacy, which is arguably worse than no sense of privacy. (People who feel protected are less cautious)
We can't half-ass privacy features just like we can't half-ass security ones. It's not the same as regular UX features that only need to "feel" right and where corners can be cut to save resources.

Perhaps implement it on Windows and Mac first (> 95% of users), and delay Android and Linux a bit so it's done right ?

Comment 61

8 months ago
You could always use telemetry and firefox experiments to get details on:
- installed fonts per platform and os
- fonts used by sites, both native os fonts and external fonts loaded from the site and cdns
- sites that  break with a certain whitelist.
With this data you could get to a point where the feature can be enabled by default for all torbrowser and firefox users

Comment 62

8 months ago
Most Web sites don't specify fonts that are specific to Linux. They specify like Arial (Windows) or Helvetica (Mac). It doesn't seem to me that Linux needs it's own separate whitelist. A Linux system may have Windows and/or Mac compatible replacement fonts (or even real licensed Windows or Mac fonts), but will have no other fonts that are used by most Web sites. It seems to me that the Linux whitelist could consist of the combined Windows and Mac whitelists. The site would then only be able to detect any common fonts the user may have installed. If a problem is that the Linux system may have no Windows or Mac compatible fonts (and thus whitelisting would get disabled), Firefox could simply bundle e.g. the Liberation fonts (licensed under SIL Open Font License, Version 1.1) which provides replacement fonts for e.g. Times New Roman, Arial, and Courier New -- this would ensure whitelisting doesn't get disabled due to lack of common fonts.

Really, even the Windows and Mac whitelists may be more robust than is necessary, since my impression is that only a few of the available system fonts ever get referenced in CSS on most Web sites, and most anything else is done with embedded fonts.

Comment 63

8 months ago
[Tracking Requested - why for this release]:

In Firefox 53, setting the default Windows 7 fonts:

Arial, Arial Black, Calibri, Cambria, Cambria Math, Comic Sans MS, Consolas, Courier, Courier New, Georgia, Helvetica, Impact, Lucida Console, Lucida Sans Unicode, Microsoft Sans Serif, MS Gothic, MS PGothic, MS Sans Serif, MS Serif, Palatino Linotype, Segoe Print, Segoe Script, Segoe UI, Segoe UI Light, Segoe UI Semibold, Segoe UI Symbol, Tahoma, Times, Times New Roman, Trebuchet MS, Verdana, Wingdings, Aharoni, Andalus, Angsana New, AngsanaUPC, Aparajita, Arabic Typesetting, Batang, BatangChe, Browallia New, BrowalliaUPC, Candara, Constantia, Corbel, Cordia New, CordiaUPC, DaunPenh, David, DFKai-SB, DilleniaUPC, DokChampa, Dotum, DotumChe, Ebrima, EucrosiaUPC, Euphemia, FangSong, Fixedsys, FrankRuehl, FreesiaUPC, Gabriola, Gautami, Gisha, Gulim, GulimChe, Gungsuh, GungsuhChe, HELV, IrisUPC, Iskoola Pota, JasmineUPC, KaiTi, Kalinga, Kartika, Khmer UI, KodchiangUPC, Kokila, Lao UI, Latha, Leelawadee, Levenim MT, LilyUPC, Malgun Gothic, Mangal, Marlett, Meiryo, Meiryo UI, Microsoft Himalaya, Microsoft JhengHei, Microsoft New Tai Lue, Microsoft PhagsPa, Microsoft Tai Le, Microsoft Uighur, Microsoft YaHei, Microsoft Yi Baiti, MingLiU, MingLiU_HKSCS, MingLiU_HKSCS-ExtB, MingLiU-ExtB, Miriam, Miriam Fixed, Modern, Mongolian Baiti, MoolBoran, MS Mincho, MS PMincho, MS UI Gothic, MV Boli, Narkisim, NSimSun, Nyala, Plantagenet Cherokee, PMingLiU, PMingLiU-ExtB, Raavi, Rod, Roman, Sakkal Majalla, Script, Shonar Bangla, Shruti, SimHei, Simplified Arabic, Simplified Arabic Fixed, SimSun, SimSun-ExtB, Small Fonts, Sylfaen, System, Terminal, Traditional Arabic, Tunga, Utsaah, Vani, Vijaya, Vrinda


Result in some fonts to be missing on various test sites (such as https://browserprint.info) and giving the following output:

Arial, Calibri, Cambria, Cambria Math, Comic Sans MS, Consolas, Courier, Courier New, Georgia, Helvetica, Impact, Lucida Console, Lucida Sans Unicode, Microsoft Sans Serif, MS Gothic, MS PGothic, MS Sans Serif, MS Serif, Palatino Linotype, Segoe Print, Segoe Script, Segoe UI, Segoe UI Symbol, Tahoma, Times, Times New Roman, Trebuchet MS, Verdana, Wingdings, Aharoni, Andalus, Angsana New, AngsanaUPC, Aparajita, Arabic Typesetting, Batang, BatangChe, Browallia New, BrowalliaUPC, Candara, Constantia, Corbel, Cordia New, CordiaUPC, DaunPenh, David, DFKai-SB, DilleniaUPC, DokChampa, Dotum, DotumChe, Ebrima, EucrosiaUPC, Euphemia, FangSong, FrankRuehl, FreesiaUPC, Gabriola, Gautami, Gisha, Gulim, GulimChe, Gungsuh, GungsuhChe, IrisUPC, Iskoola Pota, JasmineUPC, KaiTi, Kalinga, Kartika, Khmer UI, KodchiangUPC, Kokila, Lao UI, Latha, Leelawadee, Levenim MT, LilyUPC, Malgun Gothic, Mangal, Marlett, Meiryo, Meiryo UI, Microsoft Himalaya, Microsoft JhengHei, Microsoft New Tai Lue, Microsoft PhagsPa, Microsoft Tai Le, Microsoft Uighur, Microsoft YaHei, Microsoft Yi Baiti, MingLiU, MingLiU_HKSCS, MingLiU_HKSCS-ExtB, MingLiU-ExtB, Miriam, Miriam Fixed, Mongolian Baiti, MoolBoran, MS Mincho, MS PMincho, MS UI Gothic, MV Boli, Narkisim, NSimSun, Nyala, Plantagenet Cherokee, PMingLiU, PMingLiU-ExtB, Raavi, Rod, Roman, Sakkal Majalla, Script, Shonar Bangla, Shruti, SimHei, Simplified Arabic, Simplified Arabic Fixed, SimSun, SimSun-ExtB, Small Fonts, Sylfaen, Traditional Arabic, Tunga, Utsaah, Vani, Vijaya, Vrinda


Note: Arial Black, etc missing

Verdict: The feature is not operating correctly in current nightly (build 2017-01-01)

Don't trash me for being helpful, this is my first bugreport on this site. Very thankful for the feature, just wish it would work at all for me.
tracking-firefox53: --- → ?
(In reply to 2owqt8+c82qa9v7eqptw from comment #63)
> Note: Arial Black, etc missing

If your system is running the DirectWrite font backend (i.e. if hardware acceleration is enabled), then Arial Black is not a valid font-family name (it's a face within the extended Arial family). See bug 644385.

The same applies to other faces in your list such as Segoe UI Light and Segoe UI Semibold; and others are legacy bitmap-only or vector fonts (e.g. FixedSys, HELV, Terminal) that DirectWrite does not support. So those fonts will not appear as available, regardless of the presence of the whitelist.

Comment 65

8 months ago
@ Jonathan Kew (:jfkthame)

Thank you for the fast and helpful reply, yet whilst I agree that it should not show fonts that are potentially not supported, this allows for more tracking.

Telling a site what fonts you have is one thing, what your client secretly uses as the page is rendered is another thing.

So basically we cannot blend in and make our browser appear less unique because of a DirectWrite limitation? That sort of defeats the idea of better anonymity and allows to filter out users on the treat mentioned above.

I'm not entirely convinced of the usefulness of this about:config flag yet.
For a reduced-fingerprinting configuration, I would suggest setting a much more limited font whitelist that includes only a few well-known and widely-used fonts that are common to all Windows releases from WinXP onwards.

Of course, this will work best if people don't manually decide on their own whitelist, but all share a common list. The pref here was created not so much for individuals to tweak on their own as for projects such as Tor to use in order to ship a configuration that standardizes the list of available fonts.

(Another possibility would be for someone to produce and distribute an add-on that users can easily install, just like installing an ad- or script-blocker, in order to set a common font whitelist.)

Comment 67

8 months ago
(In reply to Jonathan Kew (:jfkthame) from comment #66)
> For a reduced-fingerprinting configuration, I would suggest setting a much
> more limited font whitelist that includes only a few well-known and
> widely-used fonts that are common to all Windows releases from WinXP onwards.

Well that is what I did by retrieving the fonts of an untouched Win7 install in a virtual machine.

It yielded me an amazingly good result in a font fingerprinting test. After I applied it into font.system.whitelist in about:config and Firefox decided to be "funny" and remove some fonts from that list, it was 10 times worse on my actual working machine.

If the flag would expose a fixed list of fonts, regardless of availability, that should do the trick much better than a "whitelist", privacy-wise. Everyone who uses about:config regularly is aware that they can break stuff. Hence why I'm opposing the way it is currently implemented.

Right now it leads to believe in you can add any fonts, but ultimately it imposes what it wants.

Think bigger: It would not allow a user to pose as a Linux/Windows7/VM user just because of direct write? That is incredibly handicapped.

So we cannot have a Factor 10 less common fingerprint because of this issue. It sadly failed me, excuse any negativity, just felt let down since the people here had an actually great idea and didn't implement it with enough freedom for the enduser.

Comment 68

8 months ago
Torbrowser itself has

> Arial, Batang, 바탕, Cambria Math, Courier New, Euphemia, Gautami, Georgia, Gulim, 굴림, GulimChe, 굴림체, Iskoola Pota, Kalinga, Kartika, Latha, Lucida Console, MS Gothic, MS ゴシック, MS Mincho, MS 明朝, MS PGothic, MS Pゴシック, MS PMincho, MS P明朝, MV Boli, Malgun Gothic, Mangal, Meiryo, Meiryo UI, Microsoft Himalaya, Microsoft JhengHei, Microsoft JengHei UI, Microsoft YaHei, 微软雅黑, Microsoft YaHei UI, MingLiU,細明體, Noto Sans Buginese, Noto Sans Khmer, Noto Sans Lao, Noto Sans Myanmar, Noto Sans Yi, Nyala, PMingLiU, 新細明體, Plantagenet Cherokee, Raavi, Segoe UI, Shruti, SimSun, 宋体, Sylfaen, Tahoma, Times New Roman, Tunga, Verdana, Vrinda, Yu Gothic UI
can't we just use that?
(In reply to icedt from comment #67)
> If the flag would expose a fixed list of fonts, regardless of availability,
> that should do the trick much better than a "whitelist", privacy-wise.

What exactly do you mean by "expose" fonts here?

The browser doesn't directly "expose" a list of the available fonts (I believe Flash may do, but that's out of scope here). Rather, sites like browserprint.info infer the availability of specific fonts by putting them into CSS font-family and/or @font-face rules and detecting whether this affects rendering, or whether a subsequent font or resource is accessed (implying that the font being tested for wasn't available).

So how should we "expose a fixed list of fonts" that may not actually be available? Suppose "Arial" is in that list (so it's supposed to be "exposed"), but the user doesn't have Arial installed. What would you expect the browser to do when it encounters

  @font-face {
    font-family: foo;
    src: local("Arial");
  }

or

  font-family: Arial;

in content, to make it appear to a would-be fingerprinter that Arial is present?
(In reply to Selek Respa from comment #68)
> Torbrowser itself has
> 
> > Arial, Batang, 바탕, Cambria Math, Courier New, Euphemia, Gautami, Georgia, Gulim, 굴림, GulimChe, 굴림체, Iskoola Pota, Kalinga, Kartika, Latha, Lucida Console, MS Gothic, MS ゴシック, MS Mincho, MS 明朝, MS PGothic, MS Pゴシック, MS PMincho, MS P明朝, MV Boli, Malgun Gothic, Mangal, Meiryo, Meiryo UI, Microsoft Himalaya, Microsoft JhengHei, Microsoft JengHei UI, Microsoft YaHei, 微软雅黑, Microsoft YaHei UI, MingLiU,細明體, Noto Sans Buginese, Noto Sans Khmer, Noto Sans Lao, Noto Sans Myanmar, Noto Sans Yi, Nyala, PMingLiU, 新細明體, Plantagenet Cherokee, Raavi, Segoe UI, Shruti, SimSun, 宋体, Sylfaen, Tahoma, Times New Roman, Tunga, Verdana, Vrinda, Yu Gothic UI
> can't we just use that?

IMO, that looks much better than the list in comment 63.

Comment 71

8 months ago
(In reply to Jonathan Kew (:jfkthame) from comment #69)
> What exactly do you mean by "expose" fonts here?

Exactly what the semantic meaning of 'whitelist' implies: You expose only the trait $fontname to the website out of a user defined string.

1) If I expose a limited amount of fonts, people don't know I have more.
2) "Regardless of availability" meaning: User has control to pretend to be on a different OS.


> So how should we "expose a fixed list of fonts" that may not actually be
> available? Suppose "Arial" is in that list (so it's supposed to be

We expose the fonts as the user wants. Hence why "a fixed list of fonts, regardless of availability, that should do the trick much better than a "whitelist", privacy-wise."

> What would you expect the browser to do when it encounters
> in content, to make it appear to a would-be fingerprinter that Arial is
> present?

The exact same behaviour that occurs when a user disables the access to the installed fonts completely by using the browser.display.use_document_fonts "0" flag.

Normal operation, browser just falls back to default font. Site looks different whilst privacy remains protected. Easy.

(In reply to Selek Respa from comment #68)
> Torbrowser itself has
> [cut]
> can't we just use that?

You can use whatever you want, as the string can be custom defined by the user. My gripes however are that some fonts are deliberately ignored and removed, breaking any custom list as matters stand.

(In reply to Jonathan Kew (:jfkthame) from comment #70)
> IMO, that looks much better than the list in comment 63.

It is not about "what looks better" in a string any user can custom define completely to their own wishes.

If I want to pretend to be a TOR user I use his list, if I want to pretend to be a Win7 user I use my list, If I want to pretend to be a Mac user I use a MAC list.

I do not understand why you would not take me serious for this.

Try to understand: A user of a rare operating system might want to pose as a windows user to stick out less of a crowd. That is the whole concept of counter-intelligence, to make fingerprinting useless. Blending into the crowd means look like everyone else, regardless what OS you really run.

</word>

Comment 72

8 months ago
Addendum: Before you recommend me using the browser.display.use_document_fonts "0" flag, please bear in mind that this breaks a lot of sites, as opposed to font.system.whitelist $string, which allows me sort of normal operation. Which is why it should be fixed.

(In reply to John Daggett (:jtd) from comment #2)

As John Daggett pointed out very nicely, a whitelist is best when it reflects an out of the box operating system. By removing fonts the user defined afterwards from $string you create uniqueness that can be used again for tracking.

I would like a second opinion regarding the whole discussion starting from comment 63 up to "future date" regarding this whole issue. Would certainly help rather than shipping out a placebo.

Websites such as browserprint.info back the observed problem
Flags: needinfo?(arthuredelstein)
(Assignee)

Comment 73

8 months ago
(In reply to icedt from comment #72)
> I would like a second opinion regarding the whole discussion starting from
> comment 63 up to "future date" regarding this whole issue. Would certainly
> help rather than shipping out a placebo.

Jonathan is right -- it's not possible to fake the presence of fonts that aren't actually on the user's system. If you wanted to pretend to be a Mac user, you would need to bundle all the Mac fonts with the browser.
Flags: needinfo?(arthuredelstein)
(In reply to icedt from comment #71)
> (In reply to Jonathan Kew (:jfkthame) from comment #69)
> > What exactly do you mean by "expose" fonts here?
> 
> Exactly what the semantic meaning of 'whitelist' implies:

IMO, "whitelist" implies that only fonts in the list will be made available, and all others will be ignored -- which is exactly what was implemented here. It doesn't imply that *all* the fonts in the list will necessarily be available; some of them might not exist.

> You expose only
> the trait $fontname to the website out of a user defined string.

But we don't expose such a name or string at all, as I said above. Sites infer the presence of specific fonts by trying to use them in CSS and checking what happens. That's what I'm trying to get at by asking what you mean by "expose" fonts, and I don't think you have adequately understood this.

> 
> 1) If I expose a limited amount of fonts, people don't know I have more.

Sure. That's what the Tor whitelist is aiming to do, for example.

> > So how should we "expose a fixed list of fonts" that may not actually be
> > available? Suppose "Arial" is in that list (so it's supposed to be
> 
> We expose the fonts as the user wants. Hence why "a fixed list of fonts,
> regardless of availability, that should do the trick much better than a
> "whitelist", privacy-wise."
> 
> > What would you expect the browser to do when it encounters
> > in content, to make it appear to a would-be fingerprinter that Arial is
> > present?
> 
> The exact same behaviour that occurs when a user disables the access to the
> installed fonts completely by using the browser.display.use_document_fonts
> "0" flag.
> 
> Normal operation, browser just falls back to default font. Site looks
> different whilst privacy remains protected. Easy.

Not so easy. If the browser falls back to a default font, the site can detect that the requested font was not actually used (e.g. because text metrics will be different). So you haven't "exposed a fixed list" at all; a site will still be able to detect which of those fonts are really available, and which are falling back to default.

> My gripes however are that some fonts are deliberately ignored and
> removed, breaking any custom list as matters stand.

Restrict your "custom list" to fonts that are available across all configurations; otherwise yes, the end result will be different depending which fonts are *actually* available at runtime.

> > If I want to pretend to be a TOR user I use his list, if I want to pretend
> to be a Win7 user I use my list, If I want to pretend to be a Mac user I use
> a MAC list.

That's not really feasible. You can't pretend to be a Mac user (from a font-fingerprinting point of view) except by having the actual Mac font collection available. Just supporting those font *names* but falling back to using your (Windows, Linux, whatever) default font instead will not do, because it will not behave like the Mac fonts it's claiming to be.

If you want to pretend to be a Win7 user... well, there are (at least) two sets of Win7 users: those running with GDI-based rendering, and those using D2D/DirectWrite rendering. And those two configurations have different font lists; that's simply the reality of the platform. Think of them as two distinct platforms, if you like. If you want to hide that distinction, then use a font list that is restricted to fonts available to both -- which basically means excluding legacy fonts in formats DirectWrite doesn't support (such as bitmap-only .fon files, Type1 fonts in .pfb format, etc) and faces that are treated as separate families under GDI but merged into a single family under DW (mostly extra weights of Arial, Segoe UI, etc).

(I'm pretty sure a site would still be able to detect the difference between GDI and DirectWrite in other ways, but that's another matter.)

Comment 75

8 months ago
Thanks for your reply, I understand your opinions and can take a no for an answer ;)

Happy New Year anyway.
(In reply to Arthur Edelstein [:arthuredelstein] from comment #73)
> (In reply to icedt from comment #72)
> > I would like a second opinion regarding the whole discussion starting from
> > comment 63 up to "future date" regarding this whole issue. Would certainly
> > help rather than shipping out a placebo.
> 
> Jonathan is right -- it's not possible to fake the presence of fonts that
> aren't actually on the user's system. If you wanted to pretend to be a Mac
> user, you would need to bundle all the Mac fonts with the browser.

(Which would require a license that may not be readily available.) Even then, it would still be possible for a site to distinguish between a real Mac using those fonts and a browser on a different OS, because only on a Mac would the AAT tables in the fonts be effective (at least at present). E.g. text using one of the AAT-dependent Arabic or Indic fonts would end up with very different metrics on a system that doesn't actually support AAT -- which is currently an Apple-only technology.
tracking-firefox53: ? → +

Comment 77

8 months ago
The scope of this feature is very narrow. Is there a second bug that builds on this one ? If not, should I make one, or will you make one yourself when you're done considering the various factors ?

I thought the project was to backport Tor's privacy improvements into Firefox itself, and not only to ease Tor developers' life but also to improve actual privacy for regular Firefox users.

With that scope in mind, shouldn't Firefox itself, and not Tor or a random extension, provide a sensible whitelist for everyone ? Isn't that the actual point of privacy.resistFingerprinting ? To have fingerprinting protection features built in vanilla Firefox ?
Work for this already landed in 52. Do we need something else to happen for 53/54? If so, it's probably best to open a new bug.
Flags: needinfo?(arthuredelstein)
jfkthame, is there further work here?
Flags: needinfo?(jfkthame)

Comment 80

7 months ago
Not the one you asked, but as Steph said: "provide a sensible whitelist for everyone". Variations between users mean essentially: Uniqueness, which translates to track-able traits. However, such whitelists would have to default to standard OS fonts, which are different for each OS. Please evaluate with jfkthame if you'd like to re-iterate from that perspective with a new bugticket. I certainly appreciate people still looking into this.


(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #78)
> Work for this already landed in 52. Do we need something else to happen for
> 53/54? If so, it's probably best to open a new bug.
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #79)
> jfkthame, is there further work here?
(Assignee)

Updated

7 months ago
Blocks: 1336208
(Assignee)

Comment 81

7 months ago
(In reply to Steph from comment #77)
> The scope of this feature is very narrow. Is there a second bug that builds
> on this one ? If not, should I make one, or will you make one yourself when
> you're done considering the various factors ?
> 
> I thought the project was to backport Tor's privacy improvements into
> Firefox itself, and not only to ease Tor developers' life but also to
> improve actual privacy for regular Firefox users.
> 
> With that scope in mind, shouldn't Firefox itself, and not Tor or a random
> extension, provide a sensible whitelist for everyone ? Isn't that the actual
> point of privacy.resistFingerprinting ? To have fingerprinting protection
> features built in vanilla Firefox ?

Hi Steph -- you make a very good suggestion. Thanks. I opened bug 1336208.

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #78)
> Work for this already landed in 52. Do we need something else to happen for
> 53/54? If so, it's probably best to open a new bug.

Yes, I think we're done with this bug.
Flags: needinfo?(arthuredelstein)
tracking-firefox53: + → -

Comment 82

7 months ago
Great. Looking forward to it. This whole Tor uplift project is a godsend if it can benefit vanilla Firefox users passively for certain features, and as a unified opt-in for others. (An important goal in fingerprinting protection is to avoid fragmenting the user base. Tor Browser's security sliders provides 3 groups. Firefox should take inspiration from that model IMO, even if the UI turn out to be a simple checkbox -- two groups.)


I have a question regarding font. Try writing in Japanese in an Occidental version of Firefox (I hope the Japanese one is better): The default font at least on Windows 7 is terrible. Meiryo or Meiryo UI would make for very good defaults though if that can be changed.

Question is, what if a user changes the Japanese default fonts through about:preferences#content ? Will content be able to detect that, making the user stand out ? If so, under which conditions ? (e.g. only with JS enabled, or only if the user actually inputs something with the Japanese font, ...)

Thanks :)
> (In reply to Liz Henry (:lizzard) (needinfo? me) from comment #78)
> > Work for this already landed in 52. Do we need something else to happen for
> > 53/54? If so, it's probably best to open a new bug.
> 
> Yes, I think we're done with this bug.

Agreed, this bug is done; we implemented support for a font whitelist. It's then up to the Tor project and/or individual users what they do with that. If we want to consider shipping a predefined whitelist in Firefox, and/or bundling a standard set of fonts to support such a list, those issues belong in their own bugs.

(In reply to Steph from comment #82)
> I have a question regarding font. Try writing in Japanese in an Occidental
> version of Firefox (I hope the Japanese one is better): The default font at
> least on Windows 7 is terrible. Meiryo or Meiryo UI would make for very good
> defaults though if that can be changed.

That sounds like a topic for a separate bug.

> Question is, what if a user changes the Japanese default fonts through
> about:preferences#content ? Will content be able to detect that, making the
> user stand out ? If so, under which conditions ? (e.g. only with JS enabled,
> or only if the user actually inputs something with the Japanese font, ...)

Presumably, with JS enabled it would be possible for content to simply draw some Japanese text to a canvas and then examine the resulting pixels to figure out what font got used.

Without JS, it seems harder, but I'd guess that if the default font has been changed to something with different metrics, there are probably ways to detect this from content.
Flags: needinfo?(jfkthame)

Updated

3 months ago
Blocks: 1329996

Comment 84

3 months ago
I'm using FF nightly 55.0a1 from some days ago on W7x64 - no Adobe Flash enabled.
I enabled the font.system.whitelist and set it to what TB uses:
https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-tor-browser.js?h=tor-browser-52.1.0esr-7.0-2

Theoretically (if I did not misunderstood something), now panopticlick should show the same result in the "System Fonts" category than TorBrowser. But it does not, for example my nightly shows "MS Sans Serif, MS Serif" - those fonts are _not_ in the whitelist, yet they are shown. Why? Bug?
You need to log in before you can comment on or make changes to this bug.