Intent to Implement & Ship: SRI support for link preloads
Dominic Farolino
Contact emails
Explainer
https://github.com/w3c/preload/issues/127
Spec
https://github.com/whatwg/html/pull/4699; https://github.com/w3c/preload/pull/137
We believe this was a small-enough addition to a pre-existing feature that it does not warrant a TAG review.
Summary
Currently, subresource integrity verification (SRI) is not supported on link preloads, which means that resources with an integrity attribute cannot be preloaded without it resulting in a double download. This feature allows developers to specify subresource integrity on link preloads, so that they can be properly reused. One important result from this is that preloads that fail subresource integrity verification will stick around in the preload cache, so that a request in the future that matches the entry in the preload cache will fail to load, instead of accidentally loading the potentially-insecure resource from the network.
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Demo link
https://preload-sri.glitch.me/double-download.html
Debuggability
Chrome only shows SRI-verification failure messages in the console when an integrity-failed resource is about to be applied to the page. This feature does not change that; Chrome will not show these messages when a preloaded resource fails SRI verification, until the resource is about to be applied.
Risks
Interoperability and Compatibility
Other browsers have agreed to ship this feature as a result of meetings during TPAC 2018, and no browser has expressed negative signals. Chrome will not interoperate any worse with other browsers as a result of this feature.
The compatibility risk for this low as well, since we're just expanding the surface area of SRI verification. If a developer sets the `integrity` attribute on their subresource request, and starts adding the same attribute to their preload requests, this will not break anything, but will let them effectively use preloads with SRI.
It is remotely possible that a developer is already putting `integrity` on their preloads, but not on their main subresource requests. In this case, they may be loading resources that do not match their expected integrity, and would not know. After this feature has shipped, SRI verification on the preload would prevent these resources from loading, potentially breaking things. This is a reasonable breakage, as the developer is explicitly opting into using SRI for protection, where it previously did not work.
Agreement at TPAC: https://docs.google.com/document/d/1bYMLTkjcyOZR5Jt3vrulzMSoS32zOFtwyH33f6hW_C8/edit#heading=h.pkbnoc88hs8z
Edge: Public support
Firefox: No signals
Safari: Public support
Web / Framework developers: Positive (https://github.com/w3c/webappsec-subresource-integrity/issues/26)
Ergonomics
N/A
Activation
In order for developers to immediately begin fully utilizing SRI + Link Preload, they will need to specify the `integrity` attribute on their preloads, and optionally on their main subresource request, as opposed to *just* their subresource request.
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
Yes, we are going to add web platform tests before shipping the feature. The WIP test branch is found here, and the design doc for the tests is here.
Entry on the feature davshboard
Daniel Bratell
--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f0825570-3b5e-4604-a0d6-ebf42a6c5c1f%40chromium.org.
Domenic Denicola
On Thursday, June 20, 2019 at 11:05:39 PM UTC+9, Daniel Bratell wrote:
Makes sense, but I'd like the change to actually enter the [html] spec before deciding to ship it.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f0825570-3b5e-4604-a0d6-ebf42a6c5c1f%40chromium.org.
Yoav Weiss
On Thursday, June 20, 2019 at 11:05:39 PM UTC+9, Daniel Bratell wrote:Makes sense, but I'd like the change to actually enter the [html] spec before deciding to ship it.This is actually already supported in the HTML spec's processing model; preload links go through SRI as part of the default fetch and process the linked resource algorithm. The linked HTML pull request just fixes an oversight by changing the authoring requirements to ensure that putting integrity="" on <link rel=preload> links is allowed by conformance checkers (HTML validators)./DanielOn Wed, 19 Jun 2019 10:52:16 +0200, Dominic Farolino <d...@chromium.org> wrote:Contact emails
Explainer
https://github.com/w3c/preload/issues/127
Spec
https://github.com/whatwg/html/pull/4699; https://github.com/w3c/preload/pull/137
We believe this was a small-enough addition to a pre-existing feature that it does not warrant a TAG review.
Summary
Currently, subresource integrity verification (SRI) is not supported on link preloads, which means that resources with an integrity attribute cannot be preloaded without it resulting in a double download. This feature allows developers to specify subresource integrity on link preloads, so that they can be properly reused. One important result from this is that preloads that fail subresource integrity verification will stick around in the preload cache, so that a request in the future that matches the entry in the preload cache will fail to load, instead of accidentally loading the potentially-insecure resource from the network.
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Demo link
https://preload-sri.glitch.me/double-download.html
Debuggability
Chrome only shows SRI-verification failure messages in the console when an integrity-failed resource is about to be applied to the page. This feature does not change that; Chrome will not show these messages when a preloaded resource fails SRI verification, until the resource is about to be applied.
Risks
Interoperability and Compatibility
Other browsers have agreed to ship this feature as a result of meetings during TPAC 2018, and no browser has expressed negative signals. Chrome will not interoperate any worse with other browsers as a result of this feature.
The compatibility risk for this low as well, since we're just expanding the surface area of SRI verification. If a developer sets the `integrity` attribute on their subresource request, and starts adding the same attribute to their preload requests, this will not break anything, but will let them effectively use preloads with SRI.
It is remotely possible that a developer is already putting `integrity` on their preloads, but not on their main subresource requests. In this case, they may be loading resources that do not match their expected integrity, and would not know. After this feature has shipped, SRI verification on the preload would prevent these resources from loading, potentially breaking things. This is a reasonable breakage, as the developer is explicitly opting into using SRI for protection, where it previously did not work.
----Agreement at TPAC: https://docs.google.com/document/d/1bYMLTkjcyOZR5Jt3vrulzMSoS32zOFtwyH33f6hW_C8/edit#heading=h.pkbnoc88hs8z
Edge: Public support
Firefox: No signals
Safari: Public support
Web / Framework developers: Positive (https://github.com/w3c/webappsec-subresource-integrity/issues/26)
Ergonomics
N/A
Activation
In order for developers to immediately begin fully utilizing SRI + Link Preload, they will need to specify the `integrity` attribute on their preloads, and optionally on their main subresource request, as opposed to *just* their subresource request.
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
Yes, we are going to add web platform tests before shipping the feature. The WIP test branch is found here, and the design doc for the tests is here.
Entry on the feature davshboard
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 blin...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f0825570-3b5e-4604-a0d6-ebf42a6c5c1f%40chromium.org.
--/* Opera Software, Linköping, Sweden: CEST (UTC+2) */
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d6d11038-5780-4085-85bd-c679697c26f0%40chromium.org.
Kinuko Yasuda
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEii7k7A86HFTBXpVSn7e9F3tX094%3DBr%2BVUKKPL6SyOtJw%40mail.gmail.com.
Rick Byers
Non-owner LGTM :)
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMWgRNaivsh%2B1PvtukkLgd08TQCxfp5dEQveOgQ7P6X8wVowLg%40mail.gmail.com.
Darin Holloway
--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f0825570-3b5e-4604-a0d6-ebf42a6c5c1f%40chromium.org.
Chris Harrelson
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFDL_jjnME6v1Jhkr3RPtOP5YOBN-5TLno%3Dur%3D47kyURgkyuJg%40mail.gmail.com.
Dominic Farolino
LGTM3
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f0825570-3b5e-4604-a0d6-ebf42a6c5c1f%40chromium.org.
--
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+unsubscribe@chromium.org.