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

Re: [Integrity] Using hashes to locate the resource

From: Roman Ivanov <roman.s.ivanov@gmail.com>
Date: Wed, 26 Mar 2014 22:45:33 -0400
Message-ID: <533390CD.8010209@gmail.com>
To: Mike West <mkwst@google.com>
CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
Mike,

The most concise way to describe what I'm proposing is probably
noncanonical-src-any. In other words, some way to tell the client it can
attempt to load the file from a location of its choice.

I believe it would be useful, because in cases like JQuery neither the
website nor the user care about the exact location of the resource, but
they do care about ping time, availability or download speed.

Practical implementations could vary. I can think of several options.
Most of them are somewhat far-fetched, but simply having this
possibility in the draft would, in my opinion, make them more likely to
materialize.

I hope this clarifies what I meant.

...

I was not familiar with RFC5785 before you mentioned it, but something
similar to ".well-known/<hash>" did cross my mind:

<link rel="cdn-hint" href="//code.jquery.com/">
<link rel="cdn-hint" href="//ajax.googleapis.com/">
<link rel="cdn-hint" href="//ajax.aspnetcdn.com/">
<script src="/jquery-2.1.0.js"
integrity="ni:///sha-256;THISISTHEHASH?ct=application/javascript"
noncanonical-src-any></script>

The browser would try to load the file from
//code.jquery.com/.well-known/sha-256/THISISTHEHASH and so on. A similar
principle could be used for download mirrors. If the browsers are smart
about it, they could apply some heuristic to choosing the server,
including servers not on the hint list.

On 3/24/2014 4:25 AM, Mike West wrote:
> Hi Roman, thanks for the suggestion!
> 
> There's certainly some discussion of caching implications in the
> spec: http://w3c.github.io/webappsec/specs/subresourceintegrity/#caching-optional-1
> 
> 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
> 
> --
> Mike West <mkwst@google.com <mailto: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
> <mailto: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 Thursday, 27 March 2014 02:45:53 UTC

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