A new IntegrityCheckFailure event

[ScottHelme]

Just like CSP has the SecurityPolicyViolation event, it'd be really handy for SRI to have a similar event. This could be used to replace script/link tags in the event the integrity check fails and also for monitoring to see if integrity checks are failing.

[mozfreddyb]

What would you find in a potential integrity failure event that the element's onerror does not provide, except catch-all?

[ScottHelme]

Catch-all would certainly make it easy to integrate/enable reporting, a bit like: https://report-uri.github.io/report-uri-js-demo/

[cvazac]

The ergonomics of attaching error handlers to every <SCRIPT> node are not great.

Also, error objects resulting from 404s are indistinguishable from those resulting from SRI violations.

I propose that we fire an event named integrityviolation using the SecurityPolicyViolationEvent interface (leaving violatedDirective, effectiveDirective, and originalPolicy as empty string?).

If there is consensus, I'd be happy to work on the spec changes.

[annevk]

Network errors generally being indistinguishable is a "feature". I guess it would be okay to do this, but only if all other conditions (e.g., CORS success) are already met. It would also be somewhat tricky to add given you'd need to sneak that data out of Fetch, which would require some new infrastructure.

[domfarolino]

Is there enough interest in this? This seems somewhat related to ~another issue I think on whatwg/fetch I recall seeing about generally making different types of network errors more distinguishable?~ https://github.com/whatwg/fetch/issues/526 I think.

[ScottHelme]

It'd be great to surface this issue again and see if we can make some progress on native reporting support for SRI. Magecart and other JS supply chain attacks aren't going away and more applications than ever are using SRI without any visibility into what's actually happening in the field.

[mozfreddyb]

It's not something I can put on my todo list any time soon. Maybe we could guide someone to have that end up as spec text. I should note that this doesn't help or increase the chances of it being added to browsers significantly.

[mikewest]

I similarly don't have any objection, but also don't have any bandwidth. A spec PR might be helpful, but I don't think it'd be a good idea to aspirationally add it to the spec unless we have an implementer with more concrete interest.