Re: Comments on Subresource Integrity

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 14:37:53 UTC