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

Apologies for missing this back when you actually sent it!

I think this sounds great, and at the very least would be great to discuss
this at one of the upcoming WG calls. I think it tackles most (all?) the
concerns raised at TPAC and would be great to push this forward.

On Tue, Sep 24, 2024 at 2:45 AM Patrick Meenan <pmeenan@google.com> wrote:

> 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.
>