[ceejayoz]

> Does this mean browser fingerprint is somehow scrambled before it is sent to the tracker instead of blocking?

It might be homogenized instead of scrambled. Every iOS device could be given (barring IP etc.) the same fingerprint.

[pmiller2]

I don't think that's even theoretically possible. How do you block JS font enumeration without crippling the browser font API?

[tinus_hn]

Offer the same basic set to every site. Why does a website need to know the fonts you've installed?

[MBCook]

No user installed fonts on iOS. So that's already effectively the case there.

[astrange]

You can install fonts on iOS with MDM or configuration profiles.

[gsnedders]

You can't block font enumeration without crippling the entire CSSOM.

But that doesn't affect iOS, because you can't install fonts on iOS.

[dsp1234]

you can't install fonts on iOS.

Custom fonts can be installed via custom configuration profiles[0], which is what some font applications do[1]

I'm not sure if this is exposed via Safari or not, so it could still be a moot point.

[0] - https://developer.apple.com/library/content/featuredarticles...

[1] - https://itunes.apple.com/us/app/anyfont/id821560738

[derefr]

Simple way would be tainting any JS/DOM data that interacts with the font metrics API (or one of a number of other similar APIs) and then not allowing tainted data to be used as parameters in network requests.

[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.

[ceejayoz]

Browsers already treat first-party cookies differently than third-party ones. Report a homogenized fingerprint to Google Analytics, but a real one to the main site.

[om2]

One way would be to not expose any installed fonts to web content other than the system default ones.

[dangayle]

Isn't this one of the stated features of the Tor browser?

[rapind]

But then sites could easily identify and choose to react to that fingerprint. (But maybe that's OK)