[css-fonts] Clarify: use of referrers in font fetching and relationship with preloads

[noamr]

Currently it is not specified how fonts are fetched. This PR attempts to fix that.

However, currently there is a behavior mismatch around referrers and fonts.
When fetching web-fonts, Gecko & Chromium send the URL of the stylesheet where the font is defined rather than the URL of the document as the referrer for the font (Safari loads web-fonts without CORS).

It's unclear what this was meant for, but it has the effect of not being fully compatible with preloading (<link rel="preload">). Because a preload doesn't have a way to specify a referrer, and the embedding HTML does not always know which stylesheet URL will eventually load the font, this may result in incompatibilities between the preloaded request and the actual request.

Also, browsers today have an out-of-spec "memory cache" or "resource cache" for fonts, where the referrer is not a cache key, so implementations are already depending on a behavior that fetching the same font with different referrers would be identical.

I suggest to not send the stylesheet URL as a referrer to avoid this problem, but I'm not sure of the implications.

[yoavweiss]

FWIW, Chromium recently changed the referrer used for other CSS based resources, with no compat implications.
It seems like it would be safe to do the same for fonts, and align on sending the referrer of the Document.

[yoavweiss]

/cc @achristensen07 - for Safari opinions
@estark37 @davidvancleve - for Chrome opinions
@bdekoz @annevk - Can you loop in the right folks on the Mozilla side?

[annevk]

1. Using the URL of the style sheet as referrer is correct. This leaks the least amount of data to style sheet subresources. We agreed upon this behavior quite a while ago and it's defined in https://w3c.github.io/webappsec-referrer-policy/#integration-with-css because CSS lacks Fetch integration.
   1. The document is still the authority for the fetch, so Sec-Fetch-Site should be the same I think.
2. I'm not sure what CORS has to do with the referrer.
3. The Chromium changeset in [css-fonts] Clarify: use of referrers in font fetching and relationship with preloads  #6775 (comment) appears to be about inline style sheets grabbing the document base URL rather than the document URL per the description. I didn't look at the code change. Can you clarify how it's related?

I think this argues for not taking referrer into account for caches and that's it.

@domfarolino this might interest you.

[yoavweiss]

3. The Chromium changeset in [css-fonts] Clarify: use of referrers in font fetching and relationship with preloads  #6775 (comment) appears to be about inline style sheets grabbing the document base URL rather than the document URL per the description. I didn't look at the code change. Can you clarify how it's related?

You're right. I misremembered this change. Apologies for the noise.

[noamr]

1. Using the URL of the style sheet as referrer is correct. This leaks the least amount of data to style sheet subresources. We agreed upon this behavior quite a while ago and it's defined in https://w3c.github.io/webappsec-referrer-policy/#integration-with-css because CSS lacks Fetch integration.

   1. The document is still the authority for the fetch, so Sec-Fetch-Site should be the same I think.

2. I'm not sure what CORS has to do with the referrer.

3. The Chromium changeset in [css-fonts] Clarify: use of referrers in font fetching and relationship with preloads  #6775 (comment) appears to be about inline style sheets grabbing the document base URL rather than the document URL per the description. I didn't look at the code change. Can you clarify how it's related?

I think this argues for not taking referrer into account for caches and that's it.

@domfarolino this might interest you.

Thanks, this provides the missing context.

I will amend the CSS fetch draft accordingly and will add a note about caching in my preload PR.

[noamr]

1. Using the URL of the style sheet as referrer is correct. This leaks the least amount of data to style sheet subresources. We agreed upon this behavior quite a while ago and it's defined in https://w3c.github.io/webappsec-referrer-policy/#integration-with-css because CSS lacks Fetch integration.

   1. The document is still the authority for the fetch, so Sec-Fetch-Site should be the same I think.

2. I'm not sure what CORS has to do with the referrer.

I meant that Safari seems to send neither origin or refrerer headers when fetching fonts.

[domfarolino]

Is there a concrete action item for this issue at this point? It seems that:

1. @noamr's PR is merged
2. We agree that resources in non-inline CSS sheets should use the CSS sheet's URL as the referrer
   • Safari apparently doesn't do this?
3. CORS here shouldn't impact whether the Referer is sent (I believe)

The compat risk raised in the OP was (correct me if I'm wrong) that a font preload's referrer will be the Document's URL, while the font's actual fetch's referrer will be a style sheet URL, yet reuse the different-referrer preload response. I guess this only matters when servers send Vary: Referer, which I don't think influences the preload cache. But per #6775 (comment) it sounds like this is documented now.

Can we just file a bug against Safari for (2) above and close this, or is there something specific that can still emerge from this?