Re: [SRI] integrity + login looks broken

Hi James!

thanks for all the comments!

>
>
> In fact, perhaps any response without a 2xx status should be ineligible;
> or restrict it to only 200 (Ok) responses.
>

I believe any 4xx or 5xx response would fail much earlier with a network
error, right?


> 2. Section 3.4 "Modifications to Fetch" step 4 (handling 401) seems
> disastrous. It breaks a browser's


We are actively discussing that section. Mind jumping over to
https://github.com/w3c/webappsec/issues/238 and adding your input?


3. A web server should be able to specify an integrity value when
> responding with a 3xx redirect. Hopefully this could be specified in a
> future revision , just like section 3.5 says future revisions are likely to
> add integrity to other HTML elements.
>

Yes, something to consider for future versions of the spec, I think. One
think we should clear in this spec is what to do with redirects. I have
filed https://github.com/w3c/webappsec/issues/357 for tracking.



>
> 4. Example 1 and example 2 should include a full hash, not have part
> elided with "...".
>
> 5. Example 1 and example 2 should have different hash values as they are
> for different resources.
>
> 6. I'm a little surprised to see potentially real domains in examples 1 &
> 2 (site53.cdn.net and analytics-r-us.com) instead of, say "cdn.example.net"
> and "analytics-r-us.example.com".
>

4-5-6 all seem to be editorial nits. I am happy to consider it if others
feel strongly, particularly if you or anyone else is willing to write a
pull request :)



>
> 7. Section 3.1 "Integrity metadata" says the format is the same as
> hash-source from CSP2. This is not quite right. hash-source is defined to
> start and end with a single quote. Instead, refer to section 3.6 "The
> integrity attribute" that references hash-algo (not hash-source) from CPS2.
>

you are right. https://github.com/w3c/webappsec/pull/356/ fixes that.




> 8. The example script "alert('Hello, world.');" in the text of section 3.1
> uses "smart-quotes", characters U+2018 and U+2019 (LEFT and RIGHT SINGLE
> QUOTATION MARK) whereas it is supposed to use ' U+0027 (APOSTROPHE). This
> matters because the bytes are hashed. Cut-n-pasting the example fails. The
> correct U+0027 is used when the script is repeated in the note.
>

Thanks for spotting this. https://github.com/w3c/webappsec/pull/354



> 9. The examples in section 3.2.1 "Agility" have the wrong hash values.
> They should match section 3.1 where the example script "alert('Hello,
> world.');" is mentioned. Instead, 3.2.1 hashes the 13 characters "Hello,
> world." despite supposedly being the content of a javascript file
> hello_world.js.
>
>
thanks! https://github.com/w3c/webappsec/pull/355 fixes this


> 10. Options in hash-with-options at first glance look like they use the
> well known URI query parameter syntax (?name=value&name=value). For
> instance, you might expect the following to be a valid integrity value:
>
--snip--

>
> 11. The character restrictions on option-value look quite arbitrary. Where
> did the subset of 16


For this and other reasons, we have decided not to spec that part and
updated it to just be VCHAR.
https://github.com/w3c/webappsec/commit/a14b345e232108b8187b83fed9a43a1a81898d12

I think this resolves both #10, #11, right?

Thanks again for the detailed feedback.

cheers
Dev