W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2014

Re: [Integrity] Using hashes to locate the resource

From: Mike West <mkwst@google.com>
Date: Mon, 24 Mar 2014 09:25:21 +0100
Message-ID: <CAKXHy=cnyf0GL8z2FV4sn4o3Q0+==o8U=4DB7GHWw_NVmu8zjw@mail.gmail.com>
To: Roman Ivanov <roman.s.ivanov@gmail.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Hi Roman, thanks for the suggestion!

There's certainly some discussion of caching implications in the spec:

Does that cover some of what you're asking for, or do you have something
else in mind (something RFC5785-like, ".well-known/<hash>"?)? If so,
perhaps you spell out the proposal in a bit more detail?


Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Thu, Mar 20, 2014 at 1:34 PM, Roman Ivanov <roman.s.ivanov@gmail.com>wrote:

> Hello,
> The integrity hash from the draft is somewhat similar to a magnet link,
> so it can potentially be used to locate resources, rather than
> just verify them. This would open up many new possibilities, including
> the possibility of building a peer-to-peer caching network, or loading
> popular script files from a user-supplied CDN. The hash could also be
> used to locate files on the author-supplied CDN without the need to
> provide non-canonical URLs for every individual link.
> I think it would be extremely beneficial if this was discussed here and
> (unless deemed completely irrelevant) somehow reflected in the draft.
> After all, the idea is not much more radical than cross-domain caching,
> and it was already mentioned on http://wiki.whatwg.org/wiki/Link_Hashes,
> which the draft was partially inspired by.
Received on Monday, 24 March 2014 08:26:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:37 UTC