Intent to Ship: Tighten `prefetch` mixed content checks.

[Mike West]

Contact emails

mk...@chromium.org

Spec

https://w3c.github.io/webappsec-mixed-content/#should-block-fetch

Bug against Resource Hints at https://github.com/w3c/resource-hints/issues/70.

Summary

Currently, Blink treats non-secure usage of `<link rel="prefetch">` as "optionally-blockable" content, similar to `<img>`. We'd like to align with Firefox's behavior, which blocks non-secure prefetch by default.

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

Yes.

Demo link

https://w3c-test.org/mixed-content/link-prefetch-tag/no-opt-in/same-host-https/top-level/no-redirect/allowed/allowed.https.html

Debuggability

Blocked mixed content shows up as an error in the console, and in the network waterfall.

Risks

Interoperability and Compatibility

Firefox ships this behavior today. We discussed the issue at TPAC, and agreed both that the spec supports that behavior, and that vendors generally should align to it.

Edge: Public support

Firefox: Shipped

Safari: Public support

Web developers: Web developers are not generally fans of mixed content checks, but the least we can do for them is ensure consistent behavior cross-browser.

Ergonomics

No ergonomic concerns.

Activation

No activation concerns.

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

It is! We have a robust test suite at https://wpt.fyi/mixed-content, and this is the only point on which Firefox and Chrome disagree.

Entry on the feature dashboard

Reusing https://www.chromestatus.com/feature/6263395770695680 for this minor bug fix.

-mike

[Mike West]

On Wed, Nov 15, 2017 at 8:59 AM, Mike West <mk...@chromium.org> wrote:

Contact emails

mk...@chromium.org

Spec

https://w3c.github.io/webappsec-mixed-content/#should-block-fetch

Bug against Resource Hints at https://github.com/w3c/resource-hints/issues/70.

Summary

Currently, Blink treats non-secure usage of `<link rel="prefetch">` as "optionally-blockable" content, similar to `<img>`. We'd like to align with Firefox's behavior, which blocks non-secure prefetch by default.

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

Yes.

Demo link

https://w3c-test.org/mixed-content/link-prefetch-tag/no-opt-in/same-host-https/top-level/no-redirect/allowed/allowed.https.html

Debuggability

Blocked mixed content shows up as an error in the console, and in the network waterfall.

Risks

Interoperability and Compatibility

Firefox ships this behavior today. We discussed the issue at TPAC, and agreed both that the spec supports that behavior, and that vendors generally should align to it.

Edge: Public support

Firefox: Shipped

Safari: Public support

Web developers: Web developers are not generally fans of mixed content checks, but the least we can do for them is ensure consistent behavior cross-browser.

I should have mentioned the use counter here: non-secure prefetch happens on ~0.018% of page views (https://www.chromestatus.com/metrics/feature/timeline/popularity/617).

I should also have mentioned that I anticipate basically no user-visible effect of this change, as any non-secure resource that we'd actually display on the page (an image, for example), will simply be requested later if we block the prefetch.

[mk...@chromium.org]

On Wednesday, November 15, 2017 at 9:17:49 AM UTC+1, Mike West wrote:

On Wed, Nov 15, 2017 at 8:59 AM, Mike West <mk...@chromium.org> wrote:

Contact emails

mk...@chromium.org

Spec

https://w3c.github.io/webappsec-mixed-content/#should-block-fetch

Bug against Resource Hints at https://github.com/w3c/resource-hints/issues/70.

Summary

Currently, Blink treats non-secure usage of `<link rel="prefetch">` as "optionally-blockable" content, similar to `<img>`. We'd like to align with Firefox's behavior, which blocks non-secure prefetch by default.

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

Yes.

Demo link

https://w3c-test.org/mixed-content/link-prefetch-tag/no-opt-in/same-host-https/top-level/no-redirect/allowed/allowed.https.html

Debuggability

Blocked mixed content shows up as an error in the console, and in the network waterfall.

Risks

Interoperability and Compatibility

Firefox ships this behavior today. We discussed the issue at TPAC, and agreed both that the spec supports that behavior, and that vendors generally should align to it.

Edge: Public support

Firefox: Shipped

Safari: Public support

I should also have pointed to evidence here: the minutes at https://www.w3.org/2017/11/06-webappsec-minutes.html#item05 aren't brilliant, but we did resolve together at TPAC last week that this was the behavior we wanted.

[Jochen Eisinger]

lgtm1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4b927b5b-9a63-4bea-a2fe-a62fd0bc08ae%40chromium.org.

[Yoav Weiss]

LGTM2

Aligning behavior with Firefox makes sense, and good to see other browsers are onboard.

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/CALjhuidtMUbdV0Wg-YnTE4cTAG2iEpDg2253X3AvmfFTRXrKJA%40mail.gmail.com.

[Rick Byers]

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/CALjhuidtMUbdV0Wg-YnTE4cTAG2iEpDg2253X3AvmfFTRXrKJA%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjnbg1pEVKbKpxTR2fsmLdCdVTF8e73MLB2sHiDWK_M6w%40mail.gmail.com.