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

Re: Couple comments on Subresource Integrity

From: Brad Hill <hillbrad@gmail.com>
Date: Tue, 25 Mar 2014 09:38:50 -0700
Message-ID: <CAEeYn8j8-_ThX5mSRQoXd9xaNQhOQz9R48pnQc+Uzbb+6kq5bw@mail.gmail.com>
To: Devdatta Akhawe <dev.akhawe@gmail.com>
Cc: Trevor Perrin <trevp@trevp.net>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Regarding explicit specification of content-type, consider if we eventually
decided to use the hash identifiers for retrieving things from some type of
content-addressable-storage.  The browser might have the correct bits
laying around, but they may have been delivered over a non-HTTP mechanism
or the original headers may not have been preserved.

Using a standard format also is how we start to build an ecosystem around
these ideas.  In the future you might be able to use a local CDN that
allows ni:// urls to be used like magnet links, etc.

I'd rather reference a 20 page spec that's done and add a new algorithm to
the already-established registry than re-invent 10 or even 5 pages inline
with this one unless there are good reasons not to use the existing spec.
 Saving a few bytes hasn't convinced me yet.

On Tue, Mar 25, 2014 at 5:40 AM, Devdatta Akhawe <dev.akhawe@gmail.com>wrote:

> > The 6920 format adds verbosity, parsing, and having to read a 20-page
> > (?!) doc.  What's the benefit?
> I am curious: are these the only concerns you have with using the RFC 6920?
> One benefit of having content type as separate meta-data is the
> browser can send that and only that in the "accept" header. Regardless
> of whether the format is RFC6920 or not, I do think this is useful.
> I agree that reading a 20 page doc for something so simple is kinda
> ridiculous: at first glance, there do seem to be things in it that are
> unnecessary for the SRI use-case. But, at first glance---maybe others
> are able to come up with scenarios where those things are useful too.
> thanks
> Dev
Received on Tuesday, 25 March 2014 16:39:22 UTC

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