[gsnedders]

You don't even need the font metrics API. Draw a span containing the character "m", measure the width of the span using Element.clientWidth. Unless you taint (almost literally) the entire CSSOM, you can pull off similar things.

[derefr]

Is there a reason to not taint the entire CSSOM?

Alternately: why not anonymize CSSOM return values? Your browser might have access to OS fonts A+B+C, but if your JS asked the CSSOM about the size of characters on the page, the answer it would give would come from an "alternate world" where the browser only has access to the web-safe fonts, and so is using one of them.

[Arnavion]

Pixel-correct measurement of fonts / text is a must-have for certain specific applications like subtitle renderers. (I maintain one.)

For a specific example, it's more pleasing to split a long line of text in a way that all the split lines have roughly the same length - "a a a b b b" -> "a a a\nb b b". But CSS only gives you one way to split lines - as much text as possible in all but the last line and whatever's leftover in the last line - "a a a b b\nb". This means a renderer library has to be able to measure the width of text to be able to insert linebreaks itself.

[gsnedders]

Huge amounts of the web will break: anything doing anything layout-related with JS will likely break.

Changing line-lengths will cause odd bits of layout breakage, so just giving bogus results as if rendered with a different set of fonts won't work properly either.