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 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 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 ( and instead of, say ""
> and "".

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. 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.

> 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! 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:

> 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.

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

Thanks again for the detailed feedback.


Received on Sunday, 17 May 2015 08:16:05 UTC