Proposal: Improve Tor Browser font whitelist / bundled fonts

Background:

In #13313 (moved) we introduced a new font whitelisting mechanism. Tor Browser only allows certain fonts to be used in the browser, in order to prevent bad people from trying to identify you by detecting what fonts are installed on your computer. Font whitelisting is also available in Firefox, off by default. (The whitelisting is controlled by a pref, "font.system.whitelist", which contains a comma-separated list of allowed font names. You can edit this pref by opening a tab and browsing to about:config.)

On Window and Mac, we mostly whitelist certain system fonts that are bundled with the operating system by default. We bundle a few Google Noto fonts as well for languages that don't have a built-in platform font.

On Linux, we bundle a large number of Google Noto fonts, plus Arimo, Cousine, and Tinos. We don't expose any system fonts, because these aren't consistent across Linux flavors.

My strategy for choosing fonts for the whitelist was to try to cover all possible languages with at least one font, and get the work done as efficiently as possible. I whitelisted Mac and Windows fonts that have been available for a long time and should be on essentially all systems. Bundling fonts from the Noto collection was a quick and dirty method for covering any missing fonts for different languages.

But there are probably more appealing fonts for some languages that we could use, especially on Linux. For example, in #20820 (moved) we are considering switching Linux from Noto Japanese to mona.ttf because the latter looks better (according to Yawning) and because mona.ttf can be used in the ancient Japanese art of ascii calligraphy. I also heard from someone who knows that the Tamil font on Windows is not too beautiful.

Proposed project:

So it would be a useful project to go through each of the fonts on each platform and see if there are better fonts that could be used instead. Important considerations would include:

• Aesthetics
• Character coverage
• Printability
• Font licensing
• Font file size

This would require asking the opinions of native speakers of various languages.

Ideally, we could come up with a new font whitelist and bundling list for Mac, Windows and Linux, where the fonts are beautiful and users are happy.

added component::applications/tor browser owner::tbb-team parent::18097 priority::medium severity::normal status::assigned tbb-usability type::defect ux-team labels

Trac:
Cc: gk to gk, yawning

Trac:
Cc: gk, yawning to gk, yawning, brade, mcs

I'm interested in seeing some better unicode support for dingbats in Linux TBB.

Simple things like the pencil doesn't work on TBB on Linux: ​https://www.fileformat.info/info/unicode/char/270E/browsertest.htm

This is Unicode version 1.1.0 released in June, 1993. https://www.fileformat.info/info/unicode/char/270e/index.htm It probably should be supported in TBB.

In TBB on Windows, the pencil works via Micro$oft's copyrighted MS PGothic (which Linux can't use) but it doesn't look very pretty at all.

Also, black flag dingbats don't seem to work on TBB on either Windows or Linux: ​https://www.fileformat.info/info/unicode/char/2691/browsertest.htm This came out in Unicode 4, which was released 14 years ago.

The Up Down Arrow does work on Linux: ​https://www.fileformat.info/info/unicode/char/2195/browsertest.htm

Also, a regular multiplication sign works ​https://www.fileformat.info/info/unicode/char/00D7/browsertest.htm but a "MULTIPLICATION X" does not. ​https://www.fileformat.info/info/unicode/char/2715/browsertest.htm Multiplication X is also Unicode 1.1 which is 24 years old.

When surfing the web, it isn't unusual to come across some of these and it looks silly when they don't render.

I got these example errors while trying to figure out what was going on with fed.wiki.org and ended up writing a github issue about it, only to close it after I found out that it was a Tor Browser bug: https://github.com/fedwiki/wiki/issues/97

Some people also were talking in this issue about emojis not working: https://trac.torproject.org/projects/tor/ticket/18172

Is https://www.google.com/get/noto/#emoji-zsye a possible solution to this? I'm not seeing a debian package for it.

Trac:
Username: vegansalad

Ok, I looked into noto emoji a bit more. I found that the "noto color emoji" font is being packaged here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849042

It was said that this should allow for color and black and white emojis once it is finished.

In the mean time, that link also said that https://packages.debian.org/jessie/ttf-ancient-fonts offers black and white emojis. I wonder if it would render the dingbats too. I don't know how to look through it to see if it has all of the Unicode 1 thru Unicode 4 dingbats though. If it does, perhaps we could whitelist it in the next TBB release.

I also looked at https://wiki.debian.org/Fonts/UnicodeCoverage to see if it might describe any packages that cover these old dingbats, but I wasn't able to figure it out.

Can anyone help me figure out what debian packaged font should be whitelisted to get all these old Unicode Characters to work in TBB?

Trac:
Username: vegansalad

I also posted an issue in Tails just in case they might have some fonts that they already use that might be good whitelisting candidates: https://labs.riseup.net/code/issues/12154

Trac:
Username: vegansalad

Trac:
Username: vegansalad
Parent: N/A to #18097 (moved)

My native language is Dingbat and TBB on Linux only supports a few words in my language. I notice that some of my language's symbols are on this webpage and in uBlock Origin, but aren't supported on Linux TBB, so I can't read them. Can you please evaluate whether adding NotoSansSymbols-Regular.ttf to TBB Linux would help this situation as yawning suggested here: https://trac.torproject.org/projects/tor/ticket/18364?replyto=9#comment:9?

Trac:
Username: vegansalad

Trac:
Cc: gk, yawning, brade, mcs to gk, yawning, brade, mcs, linda

Trac:
Component: Webpages to Applications/Tor Browser
Keywords: N/A deleted, ux-team added

I outlined below some font families who are running right now on products with a significant amount of users and which maybe we could add to our whitelist.

Android / Google Products Source -> https://material.io/guidelines/style/typography.html

Roboto is the standard typeface on Android. Noto is the standard typeface for all languages on Chrome and Android for all languages not covered by Roboto.

Script types

• English and English-like (Latin, Greek, and Cyrillic)
• Dense (Chinese, Japanese, and Korean)
• Tall (South and Southeast Asian and Middle Eastern languages)

Ubuntu Source -> http://font.ubuntu.com/

Ubuntu is the standar typeface on

• 1,200 glyphs, 200-250 languages (native languages of 3 billion people!).
• OpenType-based TTF (TrueType)
• Alternative glyphs (e.g. proportional/non-proportional/superscript/subscript numerals)
• Debugging glyphs (U+EFFD, U+EFFE, U+EFFF, U+F000) giving face, version, grayscale level and pixels-per-em digit display)

iOS San Francisco is the current standard typeface on all iOS products. https://github.com/AppleDesignResources/SanFranciscoFont https://en.wikipedia.org/wiki/San_Francisco_(sans-serif_typeface)

I'm open to looking into other options for specific OS related problems.

It'd be great to see this proposal move forward. I saw some similar chatter going on about this over here: https://github.com/pyllyukko/user.js/issues/286 Is there some way in which we could coordinate with them to try to get this stuff sorted?

Also, would it be bad to turn this propoal into a reality in the next few days by changing the name of this thread and just start asking people to start providing TBB font feedback like was provided in part in the above comment? https://trac.torproject.org/projects/tor/ticket/20842#comment:10 If not, who needs to say yes to this proposal? Is there a way in which proposals are officially reviewed and deemed appropriate that I'm not aware of? If so, is there a way to bump this proposal to the top of the list since it seems to have been ignored for so long?

Alternatively, would it be preferable to provide the TBB font feedback in the parent ticket? https://trac.torproject.org/projects/tor/ticket/18097

A third option would be to create seperate sub-tickets for font feedback that are OS specific and then solicit the opinions of native speakers of various languages and ask them to post in their respective operating system specific threads related to what fonts are good and bad?

I personally am a native speaker of dingbat/unicode/emoji and my personal request is to add fonts-noto-color-emoji to the list of Google Noto fonts shipped with the GNU+Linux version of TBB, now that it is an official Debian package https://packages.debian.org/buster/fonts-noto-color-emoji and the binary is available https://github.com/googlei18n/noto-emoji/releases I talk more about this suggestion in the specific issue page related to this bug here: https://trac.torproject.org/projects/tor/ticket/18364#comment:12

Trac:
Username: vegansalad

Trac:
Owner: N/A to tbb-team
Status: new to assigned

I'd like to request whitelist and packaging support for Linear A, Linear B and Cretan Hieroglyphs.

Of these, there is a 32kb Google Noto font for Linear B, which is a good start.

(I've been trying to use it via CSS and font-face/font-family, but it doesn't work. I can't find any docs about this, but I'm guessing it's being blocked, as it works in Firefox.)

Trac:
Username: winterflaw

Any progress on this?

I'd love to add Montserrat and Source Sans (both Google) to SecureDrop, but cannot until they're whitelisted.

If all of the Noto families could be whitelisted, that'd also be super swell. I really adore their multi-lingual/alphabet support.

Trac:
Username: ninavizz

Replying to ninavizz:

Any progress on this?

I'd love to add Montserrat and Source Sans (both Google) to SecureDrop, but cannot until they're whitelisted.

If all of the Noto families could be whitelisted, that'd also be super swell. I really adore their multi-lingual/alphabet support.

Hi Nina -- Montserrat, Source Sans, and the Noto fonts should still be usable as WebFonts. The only restriction is that Tor Browser is not whitelisting them as system fonts.

Replying to arthuredelstein:

Hi Nina -- Montserrat, Source Sans, and the Noto fonts should still be usable as WebFonts. The only restriction is that Tor Browser is not whitelisting them as system fonts.

When you say "WebFonts", do you mean font-face/font-family in CSS?

If so, I can't get this to work. I have a page, which uses them, and it's fine in Firefox (Linear B correctly displayed, using the Noto font), but it does not work in Tor Browser (I get "tofu").

Trac:
Username: winterflaw

Replying to winterflaw:

Replying to arthuredelstein:

Hi Nina -- Montserrat, Source Sans, and the Noto fonts should still be usable as WebFonts. The only restriction is that Tor Browser is not whitelisting them as system fonts.

When you say "WebFonts", do you mean font-face/font-family in CSS?

Yes, such as the examples in https://css-tricks.com/snippets/css/using-font-face/. (Note that the highest security setting blocks this mechanism.)

If so, I can't get this to work. I have a page, which uses them, and it's fine in Firefox (Linear B correctly displayed, using the Noto font), but it does not work in Tor Browser (I get "tofu").

I be glad to take a look at your page (if you want to post a link here or send it to me directly).

Okay, so, I have some odd results to report.

First, I checked security settings. They're set to standard.

Next, I followed the link you provided to CSS tricks.

I'm doing what it says except the font-face rule in my code was not first, before any style rules. I moved it, uploaded the CSS file, reloaded the site (shift+click on the reload icon) in Tor Browser. No change.

I then wanted to check the site in Firefox from a HTTP server. After all, HTTP is fairly different to local and I had only checked Firefox from local disk.

I copied the site to a normal, non-onion site I have (temporarily replaced the site there - only two files) and viewed the site in Firefox ESR (Debian 9).

The Linear B font loaded correctly.

I then put the original site back in place, and did a recursive chmod, changing all ownerships on all files for all web-sites (including the onion site) to "www-data" (files I upload through the Debian UI SFTP end up being my username - which should work fine, global "r" permission).

(Bear in mind that prior to this, the font loaded correctly in Firefox ESR over HTTP, which was using a cp -R copy of the onion site.)

I then went back to Tor Browser (which was still running - I'd not quit it) and reloaded the site - and hey presto, the font is showing.

So, I no longer have a problem, but I don't know why.

Trac:
Username: winterflaw

Replying to winterflaw:

Okay, so, I have some odd results to report.

First, I checked security settings. They're set to standard.

Next, I followed the link you provided to CSS tricks.

I'm doing what it says except the font-face rule in my code was not first, before any style rules. I moved it, uploaded the CSS file, reloaded the site (shift+click on the reload icon) in Tor Browser. No change.

I then wanted to check the site in Firefox from a HTTP server. After all, HTTP is fairly different to local and I had only checked Firefox from local disk.

I copied the site to a normal, non-onion site I have (temporarily replaced the site there - only two files) and viewed the site in Firefox ESR (Debian 9).

The Linear B font loaded correctly.

I then put the original site back in place, and did a recursive chmod, changing all ownerships on all files for all web-sites (including the onion site) to "www-data" (files I upload through the Debian UI SFTP end up being my username - which should work fine, global "r" permission).

(Bear in mind that prior to this, the font loaded correctly in Firefox ESR over HTTP, which was using a cp -R copy of the onion site.)

I then went back to Tor Browser (which was still running - I'd not quit it) and reloaded the site - and hey presto, the font is showing.

So, I no longer have a problem, but I don't know why.

Glad to hear it's working! That is indeed mysterious. But it sounds like maybe the file was not accessible for some reason? If you could reproduce the original problem, it might be interesting to see if you could directly download the font files with Tor Browser, or if you are getting some kind of HTTP error.

I think I found the problem.

A file which is uploaded, by the XFCE desktop GUI built-in SFTP, for the first time (rather than overwriting an existing file) gets permissions 600, and is owned by my user (not the HTTP server user).

Result - everything else worked, but not the freshly uploaded font file.

I did however before all of this check the developer tool for network, and saw no errors.

(Maybe I just did it wrong, or missed it).

Trac:
Username: winterflaw

Hi All: Sorry to be unclear in my request... :D

I work on SecureDrop. We recommend users to only use SD with the Tor security-slider set to SAFEST, which eliminates use of webfonts as an option. I appreciate that the default answer to this, is "well then design an alternative version without the nice fonts, or design only with system fonts" but that's inadequate. We're a Tor-first, SAFEST-first, product—but also want to provide a superb experience to our users. Typography is not a straight-forward discipline, and most system fonts for one reason or another, in my ~20yrs working in digital, are rarely adequate for the ux of a webapp.

Dotfont, as an example, is part of (an admittedly premature/hackish) a solution we're working on for show/hide functionality on password fields—which is critical for supporting highly usable AND highly secure experiences. Noto is the most cross-charset legible font, available—and legibility matters a ton, in usability (and in all alphabets). Finally, for our Journalist client app, we're using SourceSans and Montserrat—and, again, for usability, we want the information design of our Web UI to have visual parity with the web experience... and most standard system fonts just aren't that legible/usable across sizes and use instances (sorry, they're just not—especially on Linux distributions, which rarely involve typography experts).

Whitelisting a few non-standard fonts used often in support of usable, security-centric, and task-instensive UIs, is my ask. If there's a reason it's being punted for risk, I'd love to understand that reason more. :)

Trac:
Username: ninavizz

I don't think it's being punted for risk. I think it's being punted for a few reasons:

1. It's not whitelisting them, it's bundling them. We have to figure out which platforms need them, which have them (and since when) and bundle them on the ones that don't have them.
2. We have the evaluate the file size bump in our packages from doing so.
3. We probably don't want to just quick add fonts for whoever asks the most (no offense) but rather in some more impartial fashion that also captures other requests and the original intent of this bug, which was to replace fonts with ones that were better.

I'm not completely sold on #3 (closed) as a blocker though.

Aside from all that. We learned via a Canvas Fingerprinting exploration, that the same font from different versions of the same OS renders differently. This would be an argument to whitelist zero system fonts and only use ones we bundle across all OSes.

(However we're not sure if the OS itself also renders the same font file differently AFAIK....)

No offense taken—totally not wanting to get things implemented simply by being the squeakiest-wheel (though I appreciate that I can sure squeak loudly, sometimes!). ;)

Still not quite getting my head around this issue, but I'll chat with SD peeps more familiar with Tor. My only concern is wanting to get fonts other than those bundled in with the system or the browser at installation, to load in a Tor window when the security setting is on SAFEST.

Trac:
Username: ninavizz

ninavizz from SecureDrop made such an eloquent request in comment #21 (closed) above. All I can say is +1.

Trac:
Username: vegansalad

mentioned in issue #26146 (moved)

mentioned in issue #31141 (moved)

mentioned in issue #31666 (moved)

moved to tpo/applications/tor-browser#20842

mentioned in issue tpo/applications/tor-browser#31666 (closed)

mentioned in issue tpo/applications/tor-browser#18097 (closed)