Repository navigation
Font Enumeration API #399
Copy link
Copy link
Closed
Labels
Missing: venueProvenance: FuguReview type: CG early reviewAn early review of general direction from a Community GroupAn early review of general direction from a Community GroupTopic: fontsRelated to fonts on the web, including web fonts and system fontsRelated to fonts on the web, including web fonts and system fontsTopic: native platform integrationFeatures that enable web sites to integrate better with native platformsFeatures that enable web sites to integrate better with native platformsTopic: permissionsTopic: powerful APIsAPIs that reach into your life.APIs that reach into your life.Topic: privacy
Milestone
Description
こんにちはTAG!
I'm requesting a TAG review of:
- Name: Font Enumeration API
- Specification URL: https://wicg.github.io/local-font-access/
- Explainer (containing user needs and example code)¹: https://github.com/inexorabletash/font-enumeration
- GitHub issues (if you prefer feedback filed there): https://github.com/WICG/local-font-access/issues
- Tests: TBD
- Primary contacts (and their relationship to the specification): @chasephillips, @inexorabletash
Further details:
- Relevant time constraints or deadlines: We'd like to discuss this at TPAC (Sep 16, 2019) so getting TAG review before then would be great. Overall, we plan to Dev Trial in M79 (mid Oct, 2019) and Origin Trial in M80 (early Dec, 2019).
- I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
- I have reviewed the TAG's API Design Principles
- The group where the work on this specification is: TBD
We recommend the explainer to be in Markdown. On top of the usual information expected in the explainer, it is strongly recommended to add:
- Links to major pieces of multi-stakeholder review or discussion of this specification:
- Links to major unresolved issues or opposition with this specification:
We'd prefer the TAG provide feedback as (please select one):
- open issues in our GitHub repo for each point of feedback
- open a single issue in our GitHub repo for the entire review
- leave review feedback as a comment in this issue and @-notify [github usernames]
Please preview the issue and check that the links work before submitting. In particular, if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document.
¹ For background, see our explanation of how to write a good explainer.
Reactions are currently unavailable
Metadata
Metadata
Labels
Missing: venueProvenance: FuguReview type: CG early reviewAn early review of general direction from a Community GroupAn early review of general direction from a Community GroupTopic: fontsRelated to fonts on the web, including web fonts and system fontsRelated to fonts on the web, including web fonts and system fontsTopic: native platform integrationFeatures that enable web sites to integrate better with native platformsFeatures that enable web sites to integrate better with native platformsTopic: permissionsTopic: powerful APIsAPIs that reach into your life.APIs that reach into your life.Topic: privacy
Activity
dbaron commentedon Sep 12, 2019
@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.
dbaron commentedon Sep 12, 2019
Also, @ylafon points out that the explainer in #400 seems to provide a rather bad example of the use of this API -- it enumerates all of the fonts on the system just to find "Consolas" -- it seems like that would be much better addressed by an API that lets you ask for "Consolas".
65 remaining items
hober commentedon May 12, 2021
Any updates for us?
hober commentedon Sep 13, 2021
@plinss and I took another look at this today in our F2F and it seems we're still waiting on updates from @oyiptong. We're going to close this; please let us know when you're ready for us to take another look and we'll reopen it.
inexorabletash commentedon Mar 21, 2022
@hober @torgo and anyone else - I commented over in #400 (sorry about the two issues!) but we're ready for another look. Pinging here hoping for attention too.
Bug 1666951 [wpt PR 25735] - FontAccess: Sort fonts in lexicographica…
Bug 1667354 [wpt PR 25786] - Revert "FontAccess: Sort fonts in lexico…
Bug 1667499 [wpt PR 25799] - Reland "FontAccess: Sort fonts in lexico…