W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2015

Re: Caching of web content based on hashes?

From: Christian Nygaard <christiannygaard@gmail.com>
Date: Thu, 3 Sep 2015 21:45:48 +0200
Message-ID: <CAMD5jYk1DZ9facNn0gb9+n=DjY5=H8jpYxHQB3gKGnK1MPSRWw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Richard Barnes <rbarnes@mozilla.com>, WebAppSec WG <public-webappsec@w3.org>
On Thu, Sep 3, 2015 at 6:18 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> You know that this isn't strictly a bad idea as long as you get the
> rules right.    This might be ok...
>
>     GET /foo HTTP/1.1
>     Host: example.com
>     Accept-Encoding: hash-sha256
>
> Though Roy would have this defined as a new 3xx code, you might see a
> response like:
>
>     HTTP/1.1 200 OK
>     Content-Encoding: hash-sha256
>
>     abcdefghijklmnopqrstuvwxyz...
>
> That isn't caching, but at the point that you have a strong hash, it
> doesn't matter where the content actually comes from[*].
>
>
This is one of the main points you could fetch the content from a node
closer to you
from a latency point of view or faster bandwidth. One might want to cache
common web libraries instead of fetching multiple copies of the same
content from different sites. Another point is that of availbility of
dispersed web content either through multiple copies or erasure coding.

You could say
Accept-Encoding hash-sha512
Version: 20150901-1401-000001

One would be in trouble if someone makes big crypto advances such as math,
quantum computers and makes hash collisions on purpose. Thus you probably
need to enforce a policy together with the content: and a max-age this is
already defined in Cache-control

Somewhat similar ideas as IPFS.org but for a web standard.

Of course, this is more appropriately a discussion for the HTTP working
> group.
>

I will ask in the HTTP working group instead thanks for pointing towards
that of possibly extending cache-control with hashes.


>
> [*] Much.  You still have to meet certain minimum standards of
> confidentiality etc...
>
> On 3 September 2015 at 08:04, Richard Barnes <rbarnes@mozilla.com> wrote:
> > This was discussed during the development of SRI.  It was not added
> because
> > it would provide the ability for a calling site to "speak for" another
> > origin, in the sense that the browser would load the content even the
> origin
> > server would have sent something completely different.
> >
> > --Richard
> >
> > On Wed, Sep 2, 2015 at 5:33 PM, Christian Nygaard
> > <christiannygaard@gmail.com> wrote:
> >>
> >> Is it possible to extend the Subresource integrity specification to
> allow
> >> for caching of web content based on hashes instead of max-age? This
> would
> >> allow for longer caching of objects and may speed up the web due to
> making
> >> cache control easier for web developers and proxies.
> >>
> >> http://w3c.github.io/webappsec/specs/subresourceintegrity/
> >>
> >> Best regards,
> >> Christian Nygaard
> >
> >
>
Received on Thursday, 3 September 2015 19:46:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:15 UTC