Re: [w3ctag/design-reviews] Incremental Font Transfer (Issue #1057)

garretrieger left a comment (w3ctag/design-reviews#1057)

> Hi [@svgeesus](https://github.com/svgeesus), the TAG discussed it and are happy with such efforts that will increase web font usage and improve the overall web interoperability, which is good. There are also certain aspects we are unsure about.
> 
> Regarding security and privacy, we would ask for a more detailed security review. There are known techniques ([example](https://adragos.ro/fontleak/)) to leak the exact content (not just the character set) of an element with injected CSS, recursive imports and web fonts. The [Incremental Font Extension Algorithm](https://www.w3.org/TR/2025/WD-IFT-20250220/#extend-font-subset) seems to allow a similar pattern, so is it possible to create a similar attack?
> 
> Regarding page performance, how likely will IFT negatively affect the page loading performance and therefore affect its adoption? In particular:
> 
> * The patches are loaded sequentially, which is known to be a slow loading pattern.
> * The patches are applied sequentially, which might make the page layout unstable with multiple FOUTs.

Thanks for the feed back! I can add some additional context on the performance characteristics of IFT. 

In the spec the extension algorithm is described as a sequential operation for ease of understanding, but practical implementations are expected to do the loads and application in batches to maximize performance. The extension process is designed so that both patch loading can happen in parallel and application of multiple patches can be done in a single pass. To expand on this a bit:

- Patches are categorized as either fully, partial or not invalidating. When multiple candidate patches are matched and they will not invalidate each other then the client is allowed to load all of them in parallel. In the same fashion a client implementation can apply these to the font all in a single pass (so the font changes only once). The [incremental font extension algorithm](https://w3c.github.io/IFT/Overview.html#extend-font-subset) talks a bit about this: "in step 9 the client may optionally start loads for patches which are not invalidated by the currently selected entry. This is an important optimization which significantly improves performance by eliminating network round trips where possible by initiating loads for patches that will be needed in later iterations."
- We don't currently mention optimizing the client by applying multiple patches in a single pass so I'll add a note about that. This behaviour is allowed by the spec as currently written, but we should definitely call out that optimized implementations will want to do that.
- The most typical configuration for an IFT encoded font will be a set of partially invalidating patches that augment non-outline data and a set of non invalidating patches that augment outline data. In this configuration all extension operations can typically be completed with just a single round trip where one partial invalidating patch and multiple non invalidating patches are loaded in parallel in response to any extension request.
- To see this in practice check out the [IFT demo](https://garretrieger.github.io/ift-demo/) which demonstrates IFT encodings that utilize this "one round trip" approach. Additionally the client patch application implementation uses single pass patch application to maximize performance and reduce FOUT.

Overall IFT fonts should have similar or better performance characteristics when compared to [unicode range](https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/unicode-range) based font loading where a font is split into many smaller fonts that are loaded on demand based on which unicode codepoints are present. For context unicode range based loading is the current state of the art for efficiently serving large fonts (for example CJK fonts). Both approaches will initiate multiple loads in parallel in response to new content being encountered but the IFT font will typically load less total data (in the IFT demo we see about 1/3 the total data loaded vs unicode range). Likewise for FOUT it should be similar or better than the unicode range approach since patch application will be done in a single pass whereas with unicode range the individual fonts can render as they arrive potentially creating multiple FOUTs.

> 
> Thank you!



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

Message ID: <w3ctag/design-reviews/issues/1057/2859533716@github.com>