Add support for <link rel=compression-dictionary ...>

[pmeenan]

What problem are you trying to solve?

The Compression Dictionary Transport spec defines a link relation for loading compression dictionaries. The HTML implementation of the link relation should be spec'd.

What solutions exist today?

None.

How would you solve it?

Define the compression-dictionary link relation behavior to mirror the behavior of a prefetch except for passing "compression-dictionary" through to fetch as the initiator and defaulting crossorigin to "anonymous" (instead of No-cors).

Anything else?

No response

[domenic]

defaulting crossorigin to "anonymous" (instead of No-cors).

Can you say more about why we'd want to depart from HTML's usual behavior here? This seems a bit worrying, as it makes crossorigin="" for this element behave differently than it does for every other element.

[domenic]

#11620 says

adds a default crossorigin mode of "cors" anonymous (necessary for dictionaries to be usable in a third-party context).

but I don't think that's necessarily a reason to remove the usual requirement that if a resource is to be usable in third-party contexts, web developers explicitly add a crossorigin="" attribute.

[pmeenan]

Compression dictionaries MUST be CORS-readable to be stored and used for future requests (because they can be used for oracle attacks, they can only be used where the content is directly readable already).

Because of that, no-cors is not a useful default for compression dictionaries and the concern is that developers will add the link tags but forget to explicitly set an appropriate crossorigin policy (we have history with this being a problem with preconnect and preload for fonts which have similar CORS issues). Same-site dictionaries would work fine but any cross-origin dictionaries would be fetched but silently dropped.

Anonymous is the most sensible default CORS mode for a stand-alone compression dictionary since they are geared towards common patterns across a site without user-specific data (and if sites aren't careful, including private user data in them can lead to issues).

[domenic]

It's still pretty unprecedented to change the meaning of a HTML attribute in such a way. I'd like @annevk's help in making a call there.

[annevk]

I think we have precedent for this actually, https://html.spec.whatwg.org/multipage/links.html#link-type-manifest appears to do this as well, unless I'm misreading. It might even be kind of reasonable given that we don't really want new no-CORS fetches, but it is rather inconsistent.

[domenic]

Oh, you're right. The end result is the same, although the underlying spec mechanisms are quite different. (Since compression-dictionary reuses "create a link request" whereas manifest does a custom request creation.)

Great, I'm fine with this then.