Re: [w3ctag/design-reviews] Font Enumeration API (#399)

@ylafon and I are looking at this during a breakout at the Tokyo TAG face-to-face meeting.

One issue that doesn't appear to be addressed in the Security and Privacy questionnaire response is the question of fingerprinting.  Having an API for font enumeration seems like it makes font-based active fingerprinting substantially easier and faster.  That's something that needs to be traded off against the use cases for the feature -- use cases that aren't especially clear in the explainer.

It would probably be helpful if the explainer gave some compelling examples of user-facing features that would be enabled by this web feature.  This would also help understand the question of whether there are other less-powerful APIs that could address the same use cases, for example, APIs designed for finding similar fonts.

It's also worth noting that past studies of font-based fingerprinting had reported entropy that included order data from plugins.  One of the major plugins (I don't remember if it was Java or Flash) had a font enumeration API that returned the fonts in a system-specific sort order that I think was a function of the time the font was installed on the system.  This provided a large amount of additional entropy that was totally unnecessary for the feature.  At the very least it seems important for the spec to prescribe a sort order for the enumeration to avoid a repeat of this problem.

I've still been hoping to find the time to take a somewhat closer look at this, but haven't managed to do that yet.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/399#issuecomment-530679815