Re: Comments on Subresource Integrity

I agreed with Mike here from another address that awaits moderation, but in
the interests of being "on paper" before the call..  (blasted complexity)

 -1 to "hash" since we're talking about a hash with very specific
requirements and possibly some other metadata like media type, all towards
a goal of integrity.  -10 to "checksum" for the same reason : a checksum
protects weakly against accidental corruption, we're trying to protect
strongly from deliberate malicious modification.


On Tue, Jan 14, 2014 at 10:58 AM, Mike West <mkwst@google.com> wrote:

> '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/
>>> >
>>>
>>>
>>
>