Some web apps, e.g. word processors or any app that uses customisable text, may want to let the user choose from a list of pre-installed fonts on the system. It would be convenient to have an API to provide a list of the available font names.
The first objection is probably about the privacy/tracking implications of this. However this information is already available via the canvas2d API. Simply by running through a hard-coded list of possible font names, calling fillText(), then comparing the resulting pixel data, it’s possible to find out this information anyway. Here is a proof of concept that works in Chrome, Firefox and Edge: https://dl.dropboxusercontent.com/u/15217362/getfontlist.html
I’ve seen similar other workarounds based on text metrics, CSS and measuring DOM element sizes. AFAIK previously this list was also available via Java or Flash, but the move away from plugins has made them less viable. Note however that they meant for a lot of users for a long time, this information was also available anyway.
The proof-of-concept works, but is a pretty obnoxious solution, requiring a very long list of all the possible font names that are in use, and then consuming a lot of CPU to test them all. On mobile this can take a few seconds. The list I’ve used is certainly not exhaustive, and the CPU usage/delay increases as the list becomes more comprehensive.
Arguably a browser-provided list could improve tracking by including rare fonts that the hard-coded list does not include. However to mitigate this the solution is to make an ever more gigantic list of every possible font name that can be dug up from archives and font listing services, making the workaround even more obnoxious.
Some might suggest that web apps ought to use web fonts anyway. Web fonts are definitely worth considering. However for some web apps with locally-rendered content, access to the user’s local fonts allows them to use custom fonts they’ve pre-installed to their system, and helps bring parity with native apps, allowing both web apps and native apps to let the user access the same list of fonts. For example a user may want to pick a font they had previously used in Microsoft Word, but this may not be available in a web app if it is either missing from the hard-coded list, or a web font equivalent is not available.
I think the main argument in favour of this is that the information is already available as demonstrated by the proof-of-concept. A browser API to list available fonts therefore is not providing any previously unavailable information, and makes legitimate use of the font list much easier. It could even improve privacy by allowing browsers to control the list returned in some circumstances, e.g. by returning only one or two universal fonts in “tracking protection” mode, although browsers would have to do the same for the set of fonts allowed to be used via CSS, canvas2d, etc.
