Re: [w3ctag/design-reviews] TAG review request of the CSP feature 'unsafe-hashes' (#291)

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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/291#issuecomment-414965408