Pervasive Resources - continued... .well-known?

Continuing the brainstorming on pervasive resources and minimizing
redundancy, specifically for the 3rd-party subresource case, could we
benefit from a ".well-known" dictionary mechanism for advertising
origin-specific public dictionaries?

Something like /.well-known/compression-dictionary :
- Require that it be cacheable, public for some minimum time
- Maybe fetch through privacy-preserving proxy, cors anonymous
- Advertise existence in HTTP response header for existing requests (i.e.
"Uses-Well-Known-Compression-Dictionary: true")
- Dictionary response can (optionally) specify match and match-dest params
in response header
- UA's decide when/if to fetch (maybe randomly and only use after same
dictionary fetched in multiple contexts or pre-seeded whitelist, etc)
- Once stored, update automatically based on cache/stale-while-revalidate
periods

This could solve the Shopify countries, Google analytics and Facebook
events JS cases (update the dictionary monthly or longer) and also solve
for dynamic use cases like Optimizely, ads and other 3rd-party resources
where there is a lot of common repeat data but a need to not make them
cacheable.

You still need to take care that the shared dictionary can't be abused as a
tracking vector since the dictionary ID would be sent in future requests
but it limits the risk profile quite a bit by limiting it to a single
dictionary per origin and only allowing it to be used in a dictionary
context.

This is separate from the broader dictionary for frameworks and self-hosted
resources but, hopefully, eliminates the need to pierce cache boundaries
for specific individual resources.