Re: Comments on Subresource Integrity

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