Re: Comments on Subresource Integrity

+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