Open jayaddison opened 10 months ago
It should not be to hard to implement, but first need to have some js code which works. Code which modifies DOM tree or calls document.write does not work well yet, so it is too early to add such features like this one.
Yes, it is possible to add integrity checks, but is not so easy. Added test cases jqfind_ok.html, jqfind_bad.html. It worked for mozjs. openssl must be enabled (1.1 or newer)).
Thanks @rkd77 for considering this and enabling initial support for it. I notice the config option in some more recent commits.
I'm particularly interested in some aspects of how sufficiently-strong integrity hashes can -- to some extent -- be used as cache keys. However I would also mention that there are some privacy and cross-site security issues that go along with that.
I had hoped to find more time to read into the details and then respond here with useful feedback; instead I'm closing out and unsubscribing from a bunch of threads so that I can refocus/recuperate -- but I do want to mention that https://github.com/w3c/webappsec-subresource-integrity/issues/22 could be worth a read.
Thanks again, James
SubResource Integrity (acronym SRI) is a W3C recommendation that provides web publishers with a way to add the hash checksums of content referenced from their HTML pages, by adding an
integrity
attribute to the relevant HTML elements.The attribute value contains one or more hyphen-joined conjunctions of a hash algorithm (such as
sha256
) and a base64-encoded hash of the content of the linked resource.When multiple of these algorithm-and-hash conjunctions are present, then a space is used to separate each atomic conjunct.
Furthermore, there is logic in the specification that says that stronger algorithms take precedence over weaker algorithms - but it is up to the user agent to provide the ranking. So if we have an integrity attribute with value
sha256-x sha256-y sha384-z
, then -- assuming thatsha384
is stronger thansha256
-- we should ignore thex
andy
hash values entirely and only validate fetched content against thesha384
hash.However, within equal-strength algorithms, the logic is that any of the equal-strength hashes are permitted. So if we removed
sha384-z
from the previous example, then eitherx
ory
are valid base64-encoded SHA256 values for the referenced content.The specification is relatively strict in that it suggests that integrity check failures should prevent the referenced resource from being loaded by the user agent.
There are no doubt other relevant details in the W3C specification; this is my attempt to summarize what I understand to be the most important aspects of the feature from my understanding of it so far.