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

[SRI] What should we Hash Redux

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Wed, 2 Jul 2014 14:58:47 -0700
Message-ID: <CAPfop_1Uoz6G8Wu31mNPEqTbS8ww6SR_BQQh34yO_qkMrTtZNg@mail.gmail.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
Previously, on "what should we hash"
http://lists.w3.org/Archives/Public/public-webappsec/2014Mar/0023.html

Hi,

Recently, for ServiceWorker, Anne and others have been dealing with "what
content to surface to the ServiceWorker." This is similar to the question
of "What should we hash" for SRI that we previously discussed extensively
on this list. For the same reason that we don't want to hash the gzip'ed
images, SWs don't want to surface the gzip'ed values.

See https://github.com/slightlyoff/ServiceWorker/issues/339

Anne modified Fetch, based on the discussion above, to talk about the gzip
quirks we dealt with previously in "What should we hash". In particular,
see point 9 in
http://fetch.spec.whatwg.org/#http-network-or-cache-fetch

So, finally, I am wondering if "After Step 9" the body of the HTTP response
is what SRI implementations should hash? That is, can we remove the weird
wording in Step 2 of
http://w3c.github.io/webappsec/specs/subresourceintegrity/#apply-algorithm-to-resource
and instead just hook into fetch now. Basically, if I am not wrong, it
would be "After Step 9, undo content and transfer encodings (if any) and
then hash"

What to others think? Is there any difference between the new Fetch spec
and what SRI wants to hash? I couldn't see one, but maybe I am wrong.

cheers
Dev
Received on Wednesday, 2 July 2014 21:59:36 UTC

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