It's not clear to me from the spec what character encoding the script/style is in before it's hashed. The spec seems to describe running a hash algorithm on a string, when I think the hash algorithms are defined on a sequence of bytes. It seems like it should be clearer about character encoding here.

Oh, actually, I missed the note that says:

Note: source will be interpreted with the encoding of the page in which it is embedded. See the integration points in §4.2 Integration with HTML for more detail.

...which isn't normative, and which also seems pretty hard to implement since it requires undoing the character encoding conversion into the character encoding the implementation is using (generally UTF-16LE, UTF-16BE, or UTF-8).

Hey @andypaicu; thank you so much for the detailed explainer!

I have a pretty dumb question: in the examples provided, what is being hashed? Is it the text of the attribute value (e.g., performTransaction()), the full source of the attribute (onclick=”performTransaction()”), the full text of the element's outerHTML (<a onclick=”performTransaction()” ... />), or the source of the script which lexically resolves the current value of window.performTransaction?

Wasn't able to quickly understand the behavior based on the definition of source-lists.

Thanks in advance.

One other thought was whether the name should have more information (e.g., unsafe-inline-hashes) in case there might be some other unsafe feature involving hashes?

Also, generally, curious if @andypaicu or @mikewest have thoughts on any of the above comments.

Apologies for the delay, I went on vacation and I totally forgot about this when I got back:

Character encoding: Yeah the encoding when computing hashes in general in CSP is not properly implemented we currently have these two issues open which I will get to eventually: https://github.com/w3c/webappsec-csp/issues/110 https://github.com/w3c/webappsec-csp/issues/109

Currently (as far as I know) user agents that implement hashing convert to UTF-8 and then hash on those bytes and the spec should be updated to match this behaviour.

example in chrome where this happens: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/frame/csp/content_security_policy.cc?l=462

What is being hashed: In the example <a onclick=”performTransaction()” ... /> what is being hashed is the attribute value peformTransaction().

Naming suggestion unsafe-inline-hashes was the name for a long time, the only problem is that it does not make it clear that javascript: url navigations are also allowed based on this (regardless of whether they are in an attribute or not). So eventually unsafe-hashes ended up being the name of choice as being the most specific thing that covers inline event handlers, inline style attributes and javascript navigations. Still open to suggestions on this of course but I think unsafe-inline-hashes does not include all the things it affects. I personally doubt there will be any more unsafe features in CSP in the future period so I'm not really concerned with other unsafe hash features popping up.

Just want to confirm: as far as I can tell, unsafe-hashes directives mean that the user agent must now start hashing all event handler's text it encounters before attempting to execute them to see if the hash matches the directive. I suppose that's not too bad from a performance angle since modern parsers and the spec say to defer processing of event handlers until such time as the UA might need to dispatch said event. At that time, the UA would ordinarily process the inline handler's text (send it to the JS engine in order to get an executable handler and/or throw an error), and this new feature adds a hash computation to the process.

I don't suppose there's any way for the developer to flag which elements are potentially allowed by the directive, e.g., by using the integrity attribute?

User agents can optimize this process by not computing hashes for event handlers if unsafe-hashes is not present.

If unsafe-hashes is present the hashing will have to be done on all elements as there is no other sane mechanism for allowing event handlers (by sane I mean not unsafe-inline which basically provides no defense at all).

So if there was for example a check for the integrity attribute value, developers using unsafe-hashes would basically put it on all of their elements that have event handlers, otherwise those event handlers would not be allowed to run.

We discussed this during yesterday's teleconference (but GitHub was being very flaky so we couldn't comment at the time), and concluded that this spec seems fine. We're going to close this for now. But it might be worth another round of review when this is close to shipping, given some of the concerns we had about the spec's language being precise enough to lead to interoperable implementations. So could you either file a new issue or reopen this one when that's the case? Thanks for requesting TAG review.