Re: SRI for preemptive cache validation

Jeff Kaufman <jefftk@google.com> wrote:

> Current stale-but-valid:
>
>     C: GET /
>     S: ... <script src="example.js"></script> ...
>     C: GET /example.js
>     S: 304 not modified
>

With HTTP/2's push mechanism, in the same origin case, the server can
preemptively give the client the new cache validators (ETags, etc) of
subresources of "/" before the client asks for them, if same-origin. And,
AFAICT, ths can be done with fewer bytes on the wire than would be required
for SRI or SRI-like mechanisms. In particular, note that the SHA-2 hashes
used in SRI are not compressible with deflate (or any algorithm) and cannot
be truncated, but such restrictions don't apply to cache validators like
ETags. This can be automated by the web server.

In the case of third-party fonts, a browser should probably just use the
stale version of the font (i.e. always act like stale-while-revalidate is
set on the font). No harm, no foul, at least as far as the web security
model is concerned.

For other third-party resources (including fonts), it seems you can get a
lot of the benefit of what you're proposing by having the site hosting the
third-party subresource make good use of stale-while-revalidate, if/when it
is implemented by clients. This also seems like something that can be
implemented with very little manual intervention.

> * Can we make it safe to apply cross-origin, ideally without checking for
CORS?

Basically the only way the subresource-hosting server can even attempt to
mitigate cache timing attacks against the HTTP cache is by carefully using
HTTP cache control directives on the sensitive resources. If an embedding
website could instruct the browser to ignore the server's caching
directives without the server opting into such behavior (e.g. with CORS),
then the embedding website would be able to thwart such mitigations. Thus,
I don't see how one would create a safe way of bypassing CORS for such
things.

Cheers,
Brian