This issue is part of the PING privacy review w3cping/privacy-request#61

Currently the spec seems to define the document as the lifetime for the results of IFT responses.

The document is an uncommon privacy boundary on the Web; more commonly cache boundaries are defined in terms of eTLD+1, profile, etc. https://github.com/privacycg/storage-partitioning has more information about the effort and goals of partitioning storage and caches.

I think the best fix here would be to define the functionality here in terms of fetch(), in which case the proposal would "get" aligning with storage partitioning work "for free." If defining in terms of fetch() won't work though, I suggest working with the https://github.com/privacycg/storage-partitioning folks to figure out how to best align this functionality with the privacy-focused partitioning work already happening.

This is the analogue of #51 for the range-request method.

The WG's answer to the S&P questionnaire says, in part:

Web fonts are never installed on the underlying system; they are used without installation.

I don't see that restriction anywhere in the spec, and that restriction seems important to prevent the creation of an HSTS-like supercookie. Where should that normative requirement be documented?

We might think about allowing and encouraging the client to specify what "level" of a feature it supports in cases where there may be redundant information in the font.

I'm thinking of COLR v1 vs v0 vs BW fallback as the central example. A font may have all of these and there probably won't be overlap between the BW fallbacks and the v0/v1 glyphs. There may or may not be overlap between the v0 and v1 glyphs. The server implementation could be intelligent with COLR subsetting if it knows what the client can and will use (in a way that a "conventional" subsetter can't be).

(When well used CFF subroutinization and glyf composites may make such optimizations not worth the effort, although you'd still get the benefit of reducing the COLR table size. If COLR fonts become widely used they're probably the second best case for augmentation after CJK, though, so I think it's worth doing a bit of research on this possibility.)

In many cases a cache hit on an augmentation set will be very unlikely. However, there are cases where caching, and in particular regional caching (e.g. Akamai), can become not just relevant but important to performance. For example, when the initial subset is for a home page of a media service and the first augmentation is for the top article. Or when the initial subset is for the home page of a company and the first augmentation is for a popular tab or the first area added dynamically when scrolling.

Whether a request can be cached by existing services often depends on the request type (GET may be required) and the URL length. At present the spec is flexible when it comes to request method and the parameters are compressed but there are no length guarantees and some cases where the codepoints and indices will be fragmented in a way that takes more bytes to specify.

Additionally, any requirements for caching will typically be understood by the server rather than the client.

One way of addressing this need is to allow the server to respond to a GET or POST request with a different, cache-compatible URL to be used for the actual download of subset or augmentation data. This is similar to a temporary redirect, and in fact one of the existing redirect codes may suffice for this purpose (I unfortunately don't know off-hand).

(This alternative URL could contain a hash value generated from a canonicalized representation of the request, with the map stored on the server side so that the response can be regenerated on a cache miss. That possibility helps illustrate how the mechanism could work but I see no need to constrain the server-side implementation in the spec. Adobe's system has, at times, used a system like this to remain regional-cache-compatible.)

I suggest adding a section to the specification that addresses regional caching along the lines above. If we're confident that one of the existing redirect codes suffices then that section might just be informational. If we are not confident then a modest extension to the protocol may be needed.

Based on the preliminary discussion conducted as part of the WebFonts WG call, it appears that servers replying to a range-request may be able to amend that range request and respond with a larger byte range. If this is the case, this functionality can be very useful value-add for composite fonts, where a composite font preprocessing can be used to:

1. identify and group together a set of simple glyphs that are used as components, and
2. map these sets to a range of composite glyphs that reference them.

When a range-request is submitted to include composite glyphs, a smart server can amend the request to include simple components, thus avoiding any additional roundtrip requests and optimizing font sizes and user experience at the same time. The IFT Range-Request portion of the spec will not include any prescriptive text on what and how this can be done - this would be a true value-added functionality that would allow font server implementations to include additional steps and optimize user experience.

However, in order to enable this functionality to happen, certain portions of the range-request spec need to be edited - we would need to mention these possible optimization steps (both as the pre-processing step and server ability to amend range requests with larger byte range) instead of suggesting that composite fonts may not be suitable for range-request transfer and recommending that composite glyphs should be flattened to be used with range-request mechanism.

The privacy analysis done to date seems to focus on "what fingerprinting could one do based on analyzing normal use patterns", e.g.:

However, for those languages, it is possible that individual requests might be analyzed by a rogue font server to obtain intelligence about the type of content which is being read. It is unclear how feasible this attack is, or the computational complexity required to exploit it, unless the characters being requested are very unusual.

I would like the WG to analyze how IFT could be used for fingerprinting by malicious site with a self-controlled or colluding font server. For example, if installed font state - which includes a set of characters in each font which the client might or might not have - is exposed in the same way across sites, could a site create a tool for "reading" that state vector by 1) specifying a self-controlled or colluding font server and 2) seeing what characters are loaded by a full array read? Noting that the latter might be done invisibly to the user, using font color that matched the background or was otherwise not visible.

This is just one example, which makes me think that the current analysis is incomplete.

In section Privacy and Security Considerations it says

Note any issues that have been raised about privacy and security.

1. That could be read as "issues have been reported, but we haven't got around to noting them yet". I propose instead the text below

2. A recent change to the rules for wide review requires that the Privacy and the Security sections be separate. (They used to be sent to the same group, but now are sent to two different places).

I therefore propose:

Privacy Considerations
No Privacy issues have been raised against this document

Security Considerations
No Security issues have been raised against this document

I found this initially confusing. One of each, or one of these three (the latter is meant):

A range-request optimized font should have only one of these tables:

• The CFF table
• The CFF2 table
• The glyf table

The term outline table is used to describe the one table which is either a CFF table, CFF2 table, or glyf table.

suggested fix:

The term outline table is used to describe these three tables, which carry different types of glyph outlines:

• The CFF table
• The CFF2 table
• The glyf table

A range-request optimized font should have only one outline table.

may instead respond with http status code 400

If the request is malformed, what other reasonable status codes would apply, except for 400 Bad Request?

Why is this a may?

Note: The first request does not have to be a range request. If the browser expects the range-request threshold to lie within the first n bytes of the font, the first request may be a range request for the first n bytes of the font. However, a browser may instead make a non-range request, parse the data as it is being streamed from the server, and discover that it has reached the range-request threshold while data is still being streamed.

Once all the data before the range-request threshold has been loaded by the browser, the browser may either close this connection to the server, or it may choose to leave the connection open and let the font data continue loading in the background.

This is likely to cause problems.

Closing the connection from the client still has at least 1RTT of data in flight that consumes capacity that could otherwise be used to serve content. Depending on the network path and buffering in various places, that could represent a lot of data. Furthermore, establishing a new connection to replace it requires a handshake, warming up the congestion window, etc., and so represents a loss of efficiency.

Note that in H2 and H3, this is more properly described as resetting the request stream. That doesn't have the connection re-establishment overhead, but does still consume resources. In some ways, this is very similar to Server Push, where there's pretty much consensus that the overhead of sending speculative extra data isn't worth any benefit seen.

Letting the data stream in the background is not much better, because it will compete with other uses of the connection.

I strongly urge you to get some network perf folks involved (talk to the Web Perf WG as a start, perhaps; the HTTP WG also has a lot of experience here) in the design here; you're treading over ground that is very familiar to them, and their advice may help you avoid some pitfalls.

This issue is part of the PING privacy review w3cping/privacy-request#61

The server (including third-parties) could observe the patch requests to learn how the user is interacting with the page. In certain cases (e.g., when JavaScript is blocked) this would provide a unique powerful capability to the server, since they otherwise wouldn't be able to learn what the user is reading on the page, or typing in a form, etc.

I appreciate that this is partially discussed in Privacy Considerations section, but i think the analysis there is incorrect, or at least incomplete. Specifically the text currently says:

One mitigation, which was originally introduced for reasons of networking efficiency so is likely to be implemented in practice, is to request additional, un-needed characters to dilute the ability to infer what content the user is viewing. Requesting characters which are statistically likely to occur may avoid a subsequent request.

In practice though, this is unlilkely to be a useful mitigation, at least in the way its currently discussed. By definition, the client is likely to have already requested characters that are "statistically likely to occur" by the time the client needs to fetch an uncommon glyph / patch, meaning that there will be few or no common characters to request to obscure the uncommon, highly identifying characters.

I don't know what the best approach is here, but a partial solution here would be to define (or increase) the minimum patch size, reducing the granularity of the signal here.

We reference shared brotli which expired Jan 27, 2022 .

Is this expected to become an Informational RFC?

in 2.5.3. Patch Formats

TODO(garretrieger): reference updated brotli spec which includes shared dictionary.

However, IETF datatracker has no newer version. Brotli.org also has no mention

The section on client state is vague on how the client state is saved. For example how long should the client state be kept? What scope is the saved client state visible too? Should the client state respect caching headers?

This can be resolved by specifying the client state to be saved into the HTTP cache and follow normal behaviour around HTTP response caching. This can be done by referencing the fetch spec as an example implementation for caching policies.

The following sections of the FAST checklist seem to apply to the Incremental Font Transfer specification:

If technology allows visual rendering of content

• There is a defined way for a non-visual rendering to be created. Does not apply; this specification is about the fonts used to create the visual rendering from the content, and not the content itself (which will define how to create non-visual rendering such as text to speech)
• Content can be resized. Yes, the font can be used to render text at different sizes
• Luminosity and hue contrast can adapt to user requirements. Does not apply; the CSS or whatever is requesting the font controls this, not the font.
• Text presentation attributes can be changed. Does not apply; the CSS or whatever is requesting the font controls this, not the font.
• Visual presentation of pointers and cursors can be adjusted. Does not apply; the CSS or whatever is requesting the font controls this, not the font.
• Changing content presentation does not render it unreadable. Does not apply; the CSS or whatever is requesting the font controls this, not the font.
• Technology does not allow blinking or flashing of content, or provides a feature for users to quickly turn it off or permanently disable it. Does not apply; the CSS or whatever is requesting the font controls this, not the font.
• It is possible to make navigation order correspond to the visual presentation. Does not apply; the CSS or whatever is requesting the font controls this, not the font.

If technology defines an API

• If the API can be used for structured content, it provides features to represent all aspects of the content including hidden accessibility features. Does not apply; this API transfers just the fonts, not the structured content
• If the API relies on user agents to generate a user interface, the specification provides guidance about accessibility requirements needed to enable full interaction with the API. Does not apply; this API does not require a user interface

In 4. Declaring Incremental Fonts the CSS syntax is now outdated because of w3c/csswg-drafts#6635 and w3c/csswg-drafts#6791. The current CSS syntax would be

@font-face {
  ...
  src: url(a_font.ttf) format(truetype) font-technology(incremental);
}

The range request method has an appendix which is a suggested character ordering for CJK content. We should populate this section.

We should see if we can allow file-based static compression, rather than (in addition to?) the Content-Encoding compression.

Most of the privacy sections of the two methods should be shared, but there are probably some considerations which are distinct between the two methods.

While some font collections exist merely for packaging convenience—a single font resource instead of several—some exist for a non-trivial size benefit, such as sharing a single 'glyf', 'CFF ', or 'CFF2' table with multiple fonts.

We should make sure that there are considerations for font collections with incremental transfer.

Should fast hash be a normative reference?

Or should it be an informative reference, with the pseudo-code in the spec the normative part?

(Either way it should be in the references)

One particular aspect of IFT Range Request specification is related to describing what font table data the initial request must obtain, and how to calculate glyph coverage / byte ranges for subsequent requests. The current version of the spec says nothing about it, and in order to enable compliant and testable implementations we need to provide some specific information on what UAs are expected to implement and support. One big question is how much of this coverage calculation machinery has to be specified in details?

I think we'd need to provide more details on what range request client implementation is expected to do w.r.t. glyph coverage calculations, taking into account glyph substitutions, stylistic sets, alternate forms, etc. Leaving it open-ended for implementers to guess isn't really an option,

In PFE evaluation report document, "how to send a font data" was described in detail including how font data structure is organized and working, and also evaluations seems to be performed by glyph by glyph (in glyf). In this IFT specification, patch based transfer is defined based on Unicode codepoint but not glyph, like

A subsetted font should be able to render any combination of the codepoints in the subset identically to the original font.

(In theory?) It could be possible to list all relevant glyphs relates to a codepoint, like gathering all GSUB transformed GIDs (transformation such as liga for western scripts, or vert for CJK), but it seems there is no such detail in this specification yet if this specification really intends to work based on Unicode codepoint but not glyph in glyf table.

We would want to know how this patch based transfer works more in detail.

The current spec says:

The collection of IFT technologies utilizes a single shared opt-in mechanism. Each method does not use its own opt-in mechanism; instead, the webpage opts into the IFT technologies as a whole, and the browser and server negotiate to decide which specific method will be employed.

This, and on my reading the rest of the spec, implies that access to IFT facilities is all-or-nothing (beyond the choice between "methods").

This restriction may prevent some services from using any of the new IFT technologies. If, for example, the built-in options for caching were not sufficient for some service it would have to duplicate all of the IFT functionality, presumably with javascript-level code. This is quite restrictive and hinders experimentation that might eventually be folded into future versions of the specification. It's also not in the spirit of contemporary browser technology, which generally allows some control over what happens on the client side via the DOM interface or other Javascript APIs.

It seems as if there are three subsystems of IFT that could provide separate benefits to different implementations:

1. The scanning of the document to produce a set of subset parameters (code points and features)
2. The communication protocol with the server
3. The code that applies an augmentation to an earlier subset or augmentation to produce a new subset font. (And, if it is different from loading a non-subset font, the code that accepts an initial subset.)

Some use cases:

A service wants to use all three subsystems but do some client-side "super-setting" as mentioned in #93. To do that it might include some Javascript that wraps-around or otherwise intervenes between the document scan and the communication protocol to modify the subset parameters.

A service has caching requirements incompatible with the IFT communication protocol. Accordingly, it reuses the document scan and augmentation subsystems but replaces the communication protocol with its own bespoke system.

To increase the likelihood of caching a system uses a coarser grain of subsets and only ever augments those subsets. When subset X has been augmented once and needs to be augmented again, it keeps a copy of X around and re-augments against it. The system therefore needs to intervene both between the document scan and the protocol (to pick the right subset/augmentation combinations) and between the receipt of the subset-or-augmentation and the augmentation code (to provide the right building blocks to the latter).

This meta-issue tracks the early (post-FPWD) wide review of IFT

• Accessibility. See FAST Checklist. Review requested 14 Sept 2021. Completed
• Security. See self-review security answers. Review requested 20 Oct 2021 Timed out due to inaction
• Privacy. Review requested 10 Nov 2021. Completed
• I18n. See I18n checklist answers. Review requested 9 Oct 2021. Completed
• TAG. Requires completion of both Privacy and Security first. Review requested 26 May 2023 and on hold while we rework the specification
• Network performance review:
  • W3C Web Perf WG Review requested 28 June 2022
  • IETF HTTP WG Review requested 28 June 2022

As dynamic content is added to the page, there will be multiple requests to the server. However, because of server load balancing, each of those requests might end up going to a different physical server running different software.

If every server used for incrementally updating the existing subset has to be running the exact same software as the server used for creating the first subset (to make sure the subsetted files match what was previously sent to the client), that would be fairly brittle. Often, when large server farms have their software updated, the machines are updated a few at a time, rather than all together, so the update can be easily reverted if a problem is detected early.

One solution would be to include some token along with the font data that represents which server software was used to generate the subset, which would be resent with any subsequent requests. That way, the server receiving the second request can know which software it should use to recreate the subset the client already has.

(On the other hand, this solution is essentially a cookie, so maybe nothing new is needed. Or maybe cookies wouldn't work because of browsers' policies of blocking 3rd party cookies - font providers will almost always be 3rd parties. And, I'm also suggesting additional statefulness, which might allow additional tracking, which might be bad - there's a reason for those 3rd party cookie policies. So there might be other better solutions. This also might just not be a problem if servers don't get updated that often - the existing checksum failure would cause the font to be fully resent, and maybe this is rare enough that it's fine. We'd have to consider the situation where a client ends up ping-ponging between two different servers running two different software versions.)

(The range-request method doesn't have this problem because it's just a file - it's identical no matter which software is hosting it.)

This issue is part of the PING privacy review w3cping/privacy-request#61

The current spec text allows the client to include information about the current network speed. This is a privacy harm and would allow the server to gain additional information that could be used for profiling, fingerprinting or other related privacy harms.

Since the client can already control the size and rate to request additional glyphs / font patches, this also seems to be of limited utility; the client can already request smaller (or fewer) or bigger (or larger) patches based on what it already knows about the network condition.

Finally, there are already proposals (not yet rec track, but being discussed) that would allow the client to inform the server about local network state, which the server could then use for whatever purpose desired (including possibly the uses imagined by this proposal). https://github.com/tomayac/netinfo/blob/relaunch/README.md for example. If the authors think this funcitonality would be useful for IFT, I strongly encourage them to work on that proposal instead of possibly duplicating the informaiton here. Having all the "network state info" stuff in one spec makes the privacy analysis easier, prevents protections and choices in one proposal from undoing decisions made in the other, etc.

I recommend that the spec drop the network connection aspects all together.

(during i18n discussion,) I personally felt that a word 'codepoints' are used as identifier of both "set of codepoints" (target codepoints which client requests and are transferred from server) and "set of glyph substitutions of font" (handled as subset of font), and I wonder this might be confusing for some readers.

Considering the data we collected during PFE evaluation work on how network conditions affect the font transfer efficiency, and assuming that servers supporting both patch-subset and range-request methods would eventually learn how to optimize data transfer based on those conditions - should we allow a server to suggest a recommended approach?

In the current RangeRequest draft (#47), IFT method negotiation allows a client to request patch-subset method while a server may respond with Accept-Ranges header thereby making a recommendation to use an alternative approach to what a client has asked for. I believe this is a very useful functionality. However, there is no provision for a server to recommend another approach when a client initially asks for the range-request method but the server considers the patch-subset mechanism to be a better choice - we need to allow this to happen.

5. Range Request Incremental Transfer

This section is not normative.

What, the whole section !!

Suggested fix:

5. Range Request Incremental Transfer

5.1 Introduction

This section is not normative.

5.2 Font organization

It seems while IFT currently supports transferring OpenType Variations, it doesn't support transferring OpenType Features (that aren't mandatory; I understand those are transferred as part of the data needed to support requested unicode characters. )

For example, say that I have a font file which supports small caps, and I want to start using them.....

https://w3c.github.io/IFT/Overview.html#PatchRequest has

I expect

(Possibly this related practically to adding Font Collection support #28)

The IFT spec describes a format for use in query parameters of font URLs.

That's problematic, because it impinges on a server's authority over its own URLs.

The proper way to do this would be with request headers, probably Client Hints. If you don't want to do that, the next best thing would be to allow the site to dictate how to create a URL that contains the query information (e.g., using URI Templates).

This seems a bit handwavy:

recommended to use 4 as that has been shown to give the smallest encodings for most sets typically encountered

Shown where? Most?

Not a blocker but this should be firmed up.

In 2.1.1. Font Subset:

A subsetted font should be able to render any combination of the codepoints in the subset identically to the original font.

This is imprecise.

1. A font doesn't render anything, it is used by some application (like a browser) to render something.
2. An application which renders text using a font may have optional parts, or opt-in parts, and thus might render a subset and a full font identically, because it does not have a code path which is exercising the parts that should have been in the OpenType tables, or because that code path is not active.

However, this is a conformance requirement on the font, not on the application, so needs to be reworded to make that clear. I think it is also, primarily, a conformance requirement on the server that generated the subset.

As an example, consider a font subset which can only render the Latin letters c and s. The original font has ct and st ligatures. The client requests a patch for the letter t. A conformant server must include all the tables necessary to produce the two ligatures, (making the patched font a conformant subset) independent of whether the browser, for example, implements the CSS font-variant-ligatures: discretionary-ligatures which would actually cause the ct ligature to be rendered.

This specification needs to explain what the client does if the response to the fetch in https://w3c.github.io/IFT/Overview.html#extend-subset is unexpected in some way. For example, you could get a network error or non-200 status, you could get an unexpected content-type, content that isn't a CBOR-encoded PatchResponse, or a PatchResponse that violates some of the rules in https://w3c.github.io/IFT/Overview.html#handling-patch-request.

In most web specifications, there would be an algorithm with a series of steps that flows from needing to render a character that's outside the current font subset, through https://w3c.github.io/IFT/Overview.html#extend-subset, and into https://w3c.github.io/IFT/Overview.html#handling-patch-response, where you could handle errors and unexpected body contents in the response, but even without that level of detail, the clients still need to handle errors.

https://w3c.github.io/IFT/Overview.html#priv

No Privacy issues have been raised against this document

This statement is false. The document needs to describe how clients must request additional unnecessary glyphs in order to dilute the signal of what content the user is viewing. Ideally, we would place some minimum requirements here to make sure a browser can't just request 0 unnecessary glyphs and claim conformance.

Some urls are pointing to PFE rather than IFT and should be cleaned up.

There is a broken link to https://www.w3.org/TR/example which should be corrected to https://www.w3.org/TR/IFT

Garret does not have the w3c id listed.

Apart from that all the links look good.

From https://w3c.github.io/IFT/Overview.html#negotiating-transfer-type:

For the initial request for a font the client should assume that the server supports the patch subset based method and send a PatchRequest via HTTP GET

and in https://w3c.github.io/IFT/Overview.html#extend-subset

If sent as a GET request the client will include a single query parameter, request: the value is a single PatchRequest object

In this design, the client sends the necessary information for both methods of IFT, and the server chooses which method it wants to reply with. Browsers have to be able to make this decision themselves - browsers are more aware of the current network conditions and the current contents of the page than the server. So, if the clients have preferences, I believe this table describes the behaviors:

Problem 1

If the server only supports patch-subset, and the client prefers range-request, the client has to retry, causing a synchronous round-trip to the server before any useful information can be transferred. I think the most natural way to solve this problem is to require that all patch-subset servers should also required to support range-requests. A patch-subset server is already smart, so there shouldn't be almost any additional implementation burden. This effectively deletes the second row of the table above.

Problem 2

In the left column, 3 of the 4 boxes may involve the client sending a PatchRequest which doesn't end up being used. This could be a problem if the PatchRequest object is large.

Because of the CSS opt-in mechanism, it's probably safe to say that it will be rare for the browser to be trying to use IFT on a the server which support doesn't support either method. It's also probably safe to say that servers which support both methods will probably prefer patch-subset, because of the additional performance.

So, the biggest problem here is the situation where the browser prefers patch-subset, and the server only supports range requests. If the PatchRequest object is large, we would be spending time sending it to a server that doesn't have any idea what to do with it.

I don't actually have any good ideas about what to do about this. It would be rather unfortunate if CSS had to have two distinct opt-in mechanisms - I don't think that would be a good solution. Maybe these PatchRequest objects are small enough that this problem isn't necessary to solve?

Self-Review Questionnaire: Security and Privacy

This questionnaire has moved.

For your convenience, a copy of the questionnaire's questions is quoted here in Markdown, so you can easily include your answers in an explainer.

1. What information might this feature expose to Web sites or other parties,
   and for what purposes is that exposure necessary?

It exposes, to the server hosting a Web font, the set of characters that the browser can already render in a given Web font, and also the set of characters that it cannot render, but wants to (for example, to render a new Web page). For details, see Extending the Font Subset

The purpose of doing so is to allow the server to compute a binary patch to the existing font, adding more characters. Thus, fonts are transferred incrementally, as needed, which greatly reduces the bytes transferred and the overall network cost..

For some languages, which use a very large character set (Chinese and Japanese are examples) the vast reduction in total bytes transferred means that Web fonts become usable, including on mobile networks, for the first time.

2. Do features in your specification expose the minimum amount of information
   necessary to enable their intended uses?

Yes, we believe that they do.

It is possible to set a connection_speed parameter, which may allow the Web font server to make better trade-offs in terms of size of update vs. number of requests. This parameter is optional.

3. How do the features in your specification deal with personal information,
   personally-identifiable information (PII), or information derived from
   them?

No personal information is transferred

4. How do the features in your specification deal with sensitive information?

No sensitive information is transferred

5. Do the features in your specification introduce new state for an origin
   that persists across browsing sessions?

Yes.

6. Do the features in your specification expose information about the
   underlying platform to origins?

No

7. Does this specification allow an origin to send data to the underlying
   platform?

No. Web fonts are never installed on the underlying system; they are used without installation.

8. Do features in this specification enable access to device sensors?

No.

9. What data do the features in this specification expose to an origin? Please
   also document what data is identical to data exposed by other features, in the
   same or different contexts.

See answer to question 1.

10. Do features in this specification enable new script execution/loading
    mechanisms?

No

11. Do features in this specification allow an origin to access other devices?

No

12. Do features in this specification allow an origin some measure of control over
    a user agent's native UI?

No

13. What temporary identifiers do the features in this specification create or
    expose to the web?

64 bit checksums are generated and transferred between client and server. These are used for error detection, change frequently, and should not pose a tracking risk.

14. How does this specification distinguish between behavior in first-party and
    third-party contexts?

No difference.

15. How do the features in this specification work in the context of a browser’s
    Private Browsing or Incognito mode?

Such modes may elect to not request any WebFonts, in which case they will not use this specification.

16. Does this specification have both "Security Considerations" and "Privacy
    Considerations" sections?

Yes

17. Do features in your specification enable origins to downgrade default
    security protections?

No

18. How does your feature handle non-"fully active" documents?

Non-"fully active" documents will not trigger font subset extension requests.

19. What should this questionnaire have asked?

Nothing springs to mind.

One reviewer (from the IETF HTTP WG) found no reason for us to have two methods, and stated that it was impossible to choose between them.

The most obvious question is about why you would provide two
mechanisms. Nothing explores why you might prefer one over the other, at
server or client. It is simply taken for granted there there are two. I
don't know how a client might be expected to use this specification in a
sensible fashion based on the information presented. Nor how a server
might choose to deploy one or the other.

This needs to be made much clearer in the specification.

Short i18n review checklist is here

1. If the spec (or its implementation) contains any natural language text that will be read by a human (this includes error messages or other UI text, JSON strings, etc, etc),

   No. This is a client-server protocol to incrementally transfer Web fonts, which happens transparently in the background.

2. If the spec (or its implementation) allows content authors to produce typographically appealing text, either in its own right, or in association with graphics.

   No differently to traditional (transferred in their entirety) webfonts. Just faster.

3. If the spec (or its implementation) allows the user to point into text, creates text fragments, concatenates text, allows the user to select or step through text (using a cursor or other methods), etc.

   No

4. If the spec (or its implementation) allows searching or matching of text, including syntax and identifiers

   Not exactly. The set of characters to be rendered in a given font in a document is matched against the character repertoire of the font, and font subset update requests are made to get glyphs for any missing characters.

5. If the spec (or its implementation) sorts text

   No

6. If the spec (or its implementation) captures user input

   No

7. If the spec (or its implementation) deals with time in any way that will be read by humans and/or crosses time zone boundaries

   No

8. If the spec (or its implementation) allows any character encoding other than UTF-8.

   Textual content is not transferred by this specification

9. If the spec (or its implementation) defines markup.

   No

10. If the spec (or its implementation) deals with names, addresses, time & date formats, etc

    No

11. If the spec (or its implementation) describes a format or data that is likely to need localization.

    No

12. If the spec (or its implementation) makes any reference to or relies on any cultural norms

    No

I just found https://drafts.csswg.org/css-fonts-4/#fetch-a-font that defines common Fetch parameters for CSS font fetching. The new IFT fetch integration in https://w3c.github.io/IFT/Overview.html#extend-subset doesn't include all of those parameters, which means there will probably be unexpected effects on CORS, and maybe other things. Y'all should figure out how this is supposed to match up.

https://w3c.github.io/IFT/Overview.html#client-state also says that "The client will need to maintain at minimum the following state for each font file", but it's not obvious what a "font file" is. Is it a URL? Probably not, since that would break storage partitioning. It seems like it should be managed by whatever subsystem will eventually call https://drafts.csswg.org/css-fonts-4/#fetch-a-font, but that isn't wired up yet.

@noamr and @svgeesus might be the right people to think about the architecture here.

(This started as a review comment on the First Draft Range Request PR but I think it makes more sense as a separate issue)

General comment: I would like to see some consistency and harmonization in the Introduction and negotiation sections for the Patch Subset and Range Request documents. Currently they read like two different takes on the same problem.

If we are going to continue to have two separate specifications (which is not necessarily optimal) then we need to decide what our approach is:

1. The IFT is the main spec and has everything except Range Request in there. In which case, large amounts of the current Range-Request Introduction, Opt-In Mechanism and IFT Method Selection should be moved to the IFT spec. That avoids duplication and inconsistency but then it seems odd why one method is in a separate spec.
2. The Patch Subset and Range Request specs are peers and describe only the particulars of the two methods; implying that the current IFT spec should be renamed to Patch-Subset.bs and the need for a third spec which contains the (Harmonized) Intro, Opt-In Mechanism and IFT Method Selection (from this Range Request spec) and the Declaring Incremental Fonts, Negotiating Incremental Font Transfer from the current IFT spec.

Alternatively,

3. Same as 2. except all in one spec. To help maintain consistency, this would be my preference.

Either 2. or 3. solves the issue that the two specifications have similar sections but in different orders and with different section names.

To be clear, this will require changes to both the current documents.

Using Incremental Font Transfer in HTML

This looks like CSS to me :) so could be found in:

1. A CSS file
2. A style element in an HTML file
3. A style element in an SVG file

What this section doesn't contain, is information on using Incremental Font Transfer in a non-CSS, HTML-specific context (like a font preload). So I think the section name could be improved here.

The section does two things (which might indicate two sections, or one section with two subsections):

1. How to declare the existence of an incrementally transferable font, in CSS
2. How to perform an initial handshake to see which incremental method is supported.

Neither of these things is related to HTML

If the server receives the patch-subset query parameter and wishes to honor it, the server may reply with a valid patch subset response

So, it can also honor it with some other reply? How?

I can't see why this isn't a MUST. Or (to take into account that it wants to honor it but can't recreate the client state, a SHOULD)

In the IFT spec we mandate that a server supporting patch-request method must also support range-request method (which is a right thing to do, IMO). I couldn't find any language in the spec that would offer similar guidance for client implementations - I believe that in order to truly make it a viable option for authors the clients MUST support both IFT methods.

Right now there is a column in the PR for a client which prefers range-request and a client which prefers patch-subset. There should also probably be a column for a client which wants to let the server decide for them.

FYI, we're about to merge a change to the fetch spec that allows for particular formats of the Range header without needing a CORS preflight. Pretty useful for this spec 😄

whatwg/fetch#1312

WOFF2 data file contains a Brotli-compressed data stream that doesn't seem to allow random access into a compressed dataset - in order to be able to build a dictionary of tokens (that uses both pre-defined dictionary and variable-size sliding window dictionary), the decompressor needs to process the whole compressed data stream sequentially.

Organization of the uncompressed WOFF2 data set presents an additional obstacle - to minimize font sizes, the original font 'loca' table is omitted during compression step, and the glyph data is encoded as a collection of separate data streams that need to be processed all together to reconstruct both the original 'glyf' data and the 'loca' table itself. Presence of the 'loca' table is a hard requirement as it's the only dataset that would allow determination of the byte ranges, and the only possible way to obtain it is to reconstruct the whole glyph table from WOFF2-encoded data stream.

For reasons outlined above, I do not see WOFF2 font files as viable option for range-request transfer mechanism.