#1057: Incremental Font Transfer

Visit on Github.

Opened Feb 20, 2025

こんにちは TAG-さん!

I'm requesting a TAG review of Incremental Font Transfer.

Incremental transfer allows clients to load only the portions of the font they actually need which speeds up font loads and reduces data transfer needed to load the fonts; a font can be loaded over multiple requests where each request incrementally adds additional data.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • Previous early design review, if any: No (but see considered alternatives)
  • Relevant time constraints or deadlines:
  • The group where the work on this specification is currently being done: WebFonts WG
  • The group where standardization of this work is intended to be done (if different from the current group):
  • Major unresolved issues with or opposition to this specification:
  • This work is being funded by:

You should also know that...

Earlier horizontal review was done on the 9 July Working Draft of IFT; TAG review is requested on today's 20 Feb Working Draft which incorporates feedback from horizontal review and latest developments.

We previously requested review of an earlier approach, which had several problems such as difficulty in deployment, requirement for an active server implementation, fingerprinting risk, and poor performance with CDN caches. The new approach does not suffer from these problems.

Discussions

Log in to see TAG-private discussions.

Discussed Apr 14, 2025 (See Github)

Lola: Would like to be on this one Xiaocheng: I would join … will affect how fonts will be loaded Hadley: Feels architectural Xiaocheng: Might affect i18n … for larger character sets like Chinese

Comment by @svgeesus Apr 25, 2025 (See Github)

Hello, TAG!

We now have a fully functional Demo of IFT which compares IFT to normal font loading with Unicode-range static subsetting. Just click on "next text sample" to see the font being upgraded in real time to support more writing systems and more font variation axes. There is a running total of bytes transferred, you can see that IFT loads much less data.

Discussed Apr 28, 2025 (See Github)

Xiaocheng: this is a proposal for a new font format ... allows a new web font to be loaded incrementally. The motivation - fonts with large number of characters, eg. chinese, so the adoption rate for web fonts is lower for these. This format allows a web font to be loaded incrementally. The basic design is ... incremental font file consists of a base file.. which is a normal font file plus a patch file... then patches can be loaded at runtime when needed. The patches are static. The server doesn't dynamically calculate... That's the basic design... I think it's a good approach.. It's going to increase the adoption rate of web fonts and therefore increase interop. Also the current approach addresses several issues that have been raised .. and earlier approach uses dynamic patches and that is not as good for caching. The current approach uses static patches... server doesn't need any special implementaiton... My concerns are mostly related to ... security. Web font has always been used to fingerprint users. Also existing techniques that allow exfiltrating content of sensitive data by injecting malictious CSS.. Attack pattern is incremental inputs + malicious CSS... Patching process is recursive importing of new subsets, and the importing process depends on the page content... I feel like this part ... we should ask for more security review ...

... minor concern: the loading process is sequential: fully load it, process it, and then decide to load the next one... The loading performance may not be great. Second minor concern : iterative loading .. may cause layout instability during loading...

... the security issue is partially discussed in the security considerations in the spec... "may be used to leak characters on the page to a font server"... There are exploits that can leak not only the character set but also the exact page content... by injecting malicious CSS...

torgo: and that could be concerning with fonts for minority languages, and other reasons. We could ask them about this CSS injection attack and ask them how they propose to mitigate against that?

Xiaocheng: the spec proposes a mitigation: when loading a patch, it also loads other random patches, so the font server doesn't know which patch is needed. I'm not sure how much this will obfuscate... it depends on how careful the attackers are.

Marcos: this is outside my area, but I concur with Xiaocheng re privacy. Not sure about other security aspects, recursive thing sounds not great. Esp re SVG use, as we've discussed -- similar things.

Hadley: it sounds like the mitigation may make the fingerprinting fuzzier, but it doesn't sound great for performance, if you're loading things you don't need.

Torgo: it sounds like this is being designed for languages that don't have enough uptake. Is that assumption validated in some way? Do we need to add this complexity to the web?

Xiaocheng: explainer has some studies that show the usage of webfonts in china and japan is close to zero.

Torgo: so they've done a reasonable job of saying this is the reason they aren't being used?

Xiaocheng: yes. I'll draft a reply.

Discussed May 12, 2025 (See Github)

(Martin) One issue mentioned in Slack, but this looks good.

Xiaocheng: they have responded on the performance concerns... we raised 2 concenrs: patch loading alg (they said it's to be simple and it can be implemented in parallel - and they had demos of that - they also demoed to overall loading performance is similar to UNICODE fonts - so no longer have concerns); regarding security, they think there shouldn't be new security risks... they filed an issue ... we should wait for conclusion. Martin also raised an issue about migration of existing web fonts... they said existing web fonts

Martin: I think even that trivial change would need a tool that would take a UNICODE range file and spit out another file... I don't think that's trivial. I also think they don't have any web platform tests. But I think this is on the right track.

Xiaocheng: so security & migration concerns are still pending.

Xiaocheng to post a comment as pending external review

Discussed May 19, 2025 (See Github)

Xiaocheng: we raised some other concerns… regarding how it should be deployed… e.g. migration of existing fonts. We found out they provided such tools. Regarding security they opened up an issue but then closed it finding no security risks. I think we can close it as satisfied…

consensus to close

Xiaocheng to write closing comment and close as satisfied

Discussed May 19, 2025 (See Github)

Xiaocheng: we raised some other concerns… regarding how it should be deployed… e.g. migration of existing fonts. We found out they provided such tools. Regarding security they opened up an issue but then closed it finding no security risks. I think we can close it as satisfied…

consensus to close

Xiaocheng to write closing comment and close as satisfied

Discussed May 26, 2025 (See Github)

Xiaocheng: We discussed last week and agreed to close as satisfied; already posted comment.