Intent to Implement and Ship: 'unsafe-hashed-attributes' in CSP3

Skip to first unread message

Andy Paicu

Oct 5, 2017, 6:22:01 AM10/5/17

Contact emails,



'unsafe-hashed-attributes' is a feature in CSP3 which allows developers to enable specific event handlers without needing to use the less safe 'unsafe-inline' keyword.

If 'unsafe-hashed-attributes' is present, inline event handlers are allowed to match against hashes specified by the 'script-src' directive (or its fallback if not present).

Link to “Intent to Implement” blink-dev discussion

I don't think there has been a I2I for this feature.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?



Interoperability and Compatibility

To my knowledge we are the first browser to implement this. There seem to be positive feelings towards this in the spec discussion.

Edge: No signals

Firefox: No signals

Safari: No signals

Web developers: Positive

Is this feature fully tested by web-platform-tests? Link to test suite results from

Tests will be written as part of this. When they will exist they will reside in:

Entry on the feature dashboard


Oct 5, 2017, 6:30:14 AM10/5/17
to Andy Paicu,
It would be great if you tried to gather signals from other vendors first.


You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Mike West

Oct 5, 2017, 7:23:33 AM10/5/17
to PhistucK, Andy Paicu,, Devdatta Akhawe, Brad Hill, Frederik Braun, Artur Janc
I'd also like to get some more explicit feedback from folks at other vendors before shipping this (sorry that I gave you confusing advice when you asked about it earlier in the week!). We've had the feature implemented for quite some time, basically in a holding-pattern. My impression is that developers want the feature, and that no vendor was dead-set against it, but we never resolved the question of whether we care about backwards compatibility.

Why don't we put this intent on hold for a moment, take this back to the PR you submitted to the spec, and get explicit feedback from folks who were concerned about it in the past? I don't expect we'll have to wait too long.

CCing some folks who had thoughts explicitly here, and I'll loop them into the PR as well.


Reply all
Reply to author
0 new messages