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

Re: Comments on Subresource Integrity

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Mon, 13 Jan 2014 11:23:50 -0800
Message-ID: <CAPfop_1EJA8PY0KfwsX6WOpt4exOC1-=fDbwAhyq5LuFG0t4Ww@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Mike West <mike@mikewest.org>, WebAppSec WG <public-webappsec@w3.org>
+1 on "hash" over checksum or integrity.

On 13 January 2014 06:37, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Sat, Jan 11, 2014 at 5:06 PM, Mike West <mike@mikewest.org> wrote:
>> On Sat, Jan 11, 2014 at 4:06 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
>>> ni URL scheme. Is this expected to be parsed and handled by browsers?
>> Only insofar as the three components need to be extracted.
>>> Because then we need a definition layered on top of
>>> http://url.spec.whatwg.org/ I think.
>> What would you suggest?
> To do that, I guess?
> Otherwise it's unclear what string ni:///sha-256;%61 represents. That
> seems problematic in general with URL parsers not being fully
> interoperable at the moment.
>> Which part of step 4 (now step 2)? The "Access-Control-Allow-Credentials"
>> bit? I added that as a resource fetched via a basic fetch would fail a CORS
>> check even if it contained a reasonable 'Access-Control-Allow-Origin' header
>> due to steps 4 and 5 of the resource sharing check.
>> Since most of these requests will be basic fetches, bypassing those steps
>> seems reasonable.
> Well those checks are there for a reason. And in fact, if this is a
> CORS fetch that header will have to be present otherwise you'd have a
> network error. Are you applying a CORS check to what is otherwise a
> tainted cross-origin request?
>> If that's the bit you meant, I'll add a note to that effect:
>> https://github.com/w3c/webappsec/commit/7ff8c4720b4241d6c89a1cebb5ab5e2bc5cd4288
> This note explains what you are doing, not why it is a good idea.
>>> For XMLHttpRequest should we not put if statements around dispatching
>>> progress events and such if the policy is block? Seems somewhat weird
>>> for that API to be different from the others.
>> The current spec basically says "Hey author, don't be silly. Listen only for
>> `load` and `error` if you care about integrity."
>> But it might make sense to protect authors from themselves. How does
>> https://github.com/w3c/webappsec/commit/ff3149f29eefe60c226439f7eefb5f14e7354999
>> look?
> I think in http://xhr.spec.whatwg.org/ you want to hook into "process
> response", "process response body", and such.
>> I was assuming nosniff-style behavior here. If that option is set, I know
>> that Blink, at least, does reject scripts that are served with inappropriate
>> headers. I guess I need to read that spec to see how I can define the kind
>> of behavior I'd like to see here.
> That header is also not defined. Including what types of MIME types
> are acceptable for various resources. E.g. I believe that even with
> nosniff a image/jpeg labeled still resource will still happily decode
> as GIF if it happens to be one, because they all go to the same
> underlying library.
>> "hash", "digest", "checksum", "whatever". If folks have strong feeling about
>> the names, I'm happy to change them. "integrity" made the most sense to me,
>> as that's the purpose of the attribute, but I'm totally sympathetic to
>> spelling. :)
> "hash" or "checksum" sound good.
> --
> http://annevankesteren.nl/
Received on Monday, 13 January 2014 19:24:37 UTC

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