Re: Comments on Subresource Integrity

'Integrity' leaves more options open for future enhancement. For example,
we may at some point wish to add a mechanism allowing resources to be
verified by a signature, a la public-key-pins rather than a raw digest.

If we did something like that, would we prefer to add new attributes? Or
should one attribute describe the concept at play? Without thinking about
it too hard, I'd prefer the latter.

-mike

--
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 Tue, Jan 14, 2014 at 7:23 PM, Joel Weinberger <jww@chromium.org> wrote:

> +1 to "hash" as well.
>
>
> On Mon, Jan 13, 2014 at 11:23 AM, Devdatta Akhawe <dev.akhawe@gmail.com>wrote:
>
>> +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/
>> >
>>
>>
>