Re: Please review HTTP performance aspects of Incremental Font Transfer

[Martin Thomson <[e-mail]>]

On Mon, Jul 4, 2022, at 22:35, Chris Lilley wrote:
> https://www.w3.org/TR/PFE-evaluation/

Thanks for the context.

I found this interesting, but wasn't able to reach the same conclusions here based on what was presented here.  Even taking it as given that a font subset is smaller, the network simulation here looks fancy, but my experience with simulation is that it is not worth much.  A real-world evaluation will include packet loss and contention with other activity.  That includes some impact from processing time, which I am guessing will be a factor here.

What the performance evaluation doesn't say is how much the (purported) performance regressions correlated with poor (simulated) network conditions.  I might infer from this that the users on the worst networks suffered the worst, but that isn't necessarily how something like this ends up working in practice.  

To take a different example, with QUIC, Google's initial experiments[0] showed that the regressions were observed for people on really fast networks.  The best theory there was that QUIC was a little more complex, so it involved spending a bit more CPU, which on a fast network became the determining factor.

QUIC was overwhelmingly good for people on bad networks.  Improvements got larger as networks got worse.  Here, it looks like you might have something that makes the people with the slowest 5% of connections slower. That would be a poor outcome if it is the case.

Other notes:

When you have processes like the suggested "font optimization" [1], there are some operational concerns here on top of the performance ones.  How would any site decide how to select the input material for optimization?  How broadly applicable would that optimization be?  How do you discover that your content is an outlier and therefore adversely affected?  What process do you put in place so that outliers aren't treated poorly?

Separately, the document acknowledges the possibility that a font server can use the subset of fonts to build information about what content its clients have viewed.  This isn't an idle problem, so the manner in which this is dismissed in the spec probably isn't really appropriate.  Website fingerprinting [2] is a thing and this gives the font server much better information, but what is not noted is that this also gives some of that information to network adversaries.

[0] https://research.google/pubs/pub46403/
[1] https://lists.w3.org/Archives/Public/public-webfonts-wg/2020Oct/0028.html
[2] https://www.ietf.org/archive/id/draft-irtf-pearg-website-fingerprinting-01.html