Complex web applications often need to keep tabs of the subresources that they download, for security purposes. In particular, upcoming industry standards and best practices (e.g. PCI-DSS v4) require that web applications keep an inventory of all the scripts they download and execute. This feature builds on the Reporting API to report the URLs and hashes (for CORS/same-origin) of all the script resources that the document loads.
Web developers load many different script assets to their sites, and those scripts can then load other assets. Some of those assets are versioned and their content's integrity can be validated using Subresource Integrity or using Content Security Policy hashes. But other assets are dynamic, ever-green scripts that can be updated by their provider at any moment. The web platform has no means of validating the integrity of such scripts, neither in reporting nor in enforcement mode. At the same time, upcoming security standards require web developers to maintain an up to date inventory of all scripts that execute in the context of their payment page documents, and have a mechanism to validate their integrity. In the absence of better mechanisms, developers and merchants will need to settle for lower fidelity security guarantees — e.g. offline hash verification through crawling. Such mechanisms leave a lot to be desired in terms of their coverage, while at the same time add a lot of implementation complexity.
As this is a new feature activated through an HTTP header, I don't believe there's any compatibility risk associated with it.
As for interoperability, it's a bit early to say but casually talking to Mozilla and Webkit folks about it didn't trigger any alarms on their end.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
None
M133
--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSK_3rddBZ16wCBCuJR3f2a9%3DGSWDH-azFbmHi5dQK%2BPqw%40mail.gmail.com.