Re: SRI for preemptive cache validation

On Fri, May 15, 2015 at 6:59 AM, Jeff Kaufman <> wrote:
> A common pattern on the web is that people include some external
> resource that gets updated by a third party:
>     //
>     //
>     //
> These are used for social buttons, analytics, ads, fonts, and content
> optimization, among others.  Longcaching isn't possible here because
> the people who update the external resource aren't the same people who
> serve the webpages.
> Additionally, while most websites could switch most of their resources to
> longcaching, typically sites still use simple urls and short cache lifetimes
> because longcaching (a) would require explicit effort on the part of
> someone who has lots of other things to worry about and (b) isn't 100%
> safe for web servers to apply automatically.
> This means there are very many times when a resource is sitting stale
> in the browser cache while the server knows it's still valid.  In this
> case the browser has to check with the server and wait for a 304 Not
> Modified before it can use the resource.
> If the server could mark up resources with their expected hashes,
> however, then the browser would be able to cut out the round trip in
> this common case.

This was considered and rejected, at least within Google, because it
allows one to "put words in a server's mouth". I.e. if the browser
uses a content-addressable store in its cache and never makes the HTTP
request then an attacker could prime the cache with a value with hash
$h, then reference https://other.origin/ with that hash and have the
browser believe that "other.origin" actually served that data. This
impacts the web security model in a number of worrying ways.

(One difference with your suggestion is that your examples are only
ever same origin. I don't know whether that was deliberate. If so,
then the impact would be very different, although the benefits would
be reduced too. I've not thought about that subset of the idea



Received on Monday, 18 May 2015 23:03:28 UTC