Intent to Ship: mixed content autoupgrading for images

[Carlos IL]

Contact emails

carl...@chromium.org, est...@chromium.org, eric...@google.com

Spec

https://w3c.github.io/webappsec-mixed-content/level2.html

(intro of spec is meant to act as the explainer, since the spec is pretty small)

TAG review at https://github.com/w3ctag/design-reviews/issues/420.

Summary

Mixed content -- http:// subresources on https:// pages -- threatens users’ security and privacy, and also leads to a poor/confusing security UX, because the page is presented as somewhere between secure and insecure. 

Chrome blocks mixed scripts, iframes, and other “active” content by default, and autoupgrades mixed audio/video to HTTPS (since M80) without a fallback if the content fails to load over HTTPS.

In M81, we plan to start autoupgrading images too. Images are the only remaining type of mixed content that isn’t blocked or autoupgraded by default (excluding plugin-loaded mixed content, which will be removed with Flash support in M87).

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/ZJxkCJq5zo4/4sSMVZzBAwAJ

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

Yes

Debuggability

Upgraded requests for mixed content are shown in the DevTools network panel. We also have a console message alerting developers when a resource is autoupgraded. This message is already shown for users on beta that have autoupgrades for images enabled, and for audio/video autoupgrades (which launched in M80).

Developers can also use CSP reporting to discover mixed content that they need to fix on their site.

Risks

Interoperability and Compatibility

Mixed content images occur on 2.02% of navigations, leaving a fairly high upper bound for breakage.

From our data from running image autoupgrades for 50% of Beta users, around 60% of image autoupgrades result in a 200 response. If the autoupgrade success rate holds for stable, this would mean around 0.8% of navigations would be affected.

Since 0.8% is still relatively high, we’ve analyzed a sample of websites from HTTP Archive in order to determine how visible the mixed content is. In a random sample of 1500 mixed image requests, 14% of them resulted in network errors when fetched over HTTP, which are also counted as part of the mixed content use counter. Assuming the failure rate in real usage is similar to that of the sample, this reduces the percentage of affected navigations to 0.69% (since the rest were fetches already broken over HTTP). 

Aditionally 10% of the images in the sample were 50x50 pixels or smaller, which renders to approximately 15x15mm on an average 75 DPI monitor. This category may contain tracking pixels that are not user-visible, or very small parts of UI which won’t affect the webpage experience as much if they fail to load. After accounting for these small images, we estimate that 0.62% of navigations may be affected.

As an additional signal, we haven’t received any bug reports or user complaints since enabling mixed image autoupgrading in Beta, suggesting that much of the breakage may be user-invisible.

Despite the high compatibility impact, we think this change is still worth shipping for the following reasons:

• Mixed images are a privacy and security risk. We’re aware that mixed images are being actively used to inject headers for cross-site communication (“header enrichment”), which runs counter to the goals of the Privacy Sandbox project. We also see mixed content blocking as a step to removing HSTS supercookies.

• A user workaround is available for broken sites (mixed content can be unblocked via a setting). Enterprises can also disable mixed content blocking with a policy.

• Developers can work around the breakage by hosting images on HTTPS. Developers don’t typically face a high performance or monetary cost to host images over HTTPS today. We notified developers of this change in early October.

We plan to roll this change out slowly (likely 1%->10%->25%->50%->100%) in order to identify any large breakages. We plan to roll back if we observe higher-than-expected breakage, if developer or user complaints are overwhelming, or if we observe a spike in users bypassing mixed content blocking via settings (which would indicate that much of the breakage is in fact user-visible).

Edge: "Eh" (neither positive nor negative)

Firefox: Somewhat public support

Safari: Public support

Web / Framework developers: We haven’t heard much specifically about images. We had 3 bugs filed since autoupgrades started, along with a few emails from web developers, but all concerning mixed audio.

Ergonomics

n/a

Activation

n/a

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

Blink layout tests are pending upstreaming.

Entry on the feature dashboard

https://www.chromestatus.com/feature/4926989725073408

[Yoav Weiss]

LGTM1

There's no interoperability risk in us leading the pack here, and it will enable other browsers to follow once we see breakage is manageable.

Tracking pixels mixed with header enrichment could be one reason why usage hasn't gone down (and why it won't, unless we force it to). Autoupgrading seems like a plausible path to weed that out.

• We also see mixed content blocking as a step to removing HSTS supercookies.

• A user workaround is available for broken sites (mixed content can be unblocked via a setting). Enterprises can also disable mixed content blocking with a policy.

• Developers can work around the breakage by hosting images on HTTPS. Developers don’t typically face a high performance or monetary cost to host images over HTTPS today. We notified developers of this change in early October.

We've also had console warnings for the last X years, right? 

 

We plan to roll this change out slowly (likely 1%->10%->25%->50%->100%) in order to identify any large breakages. We plan to roll back if we observe higher-than-expected breakage, if developer or user complaints are overwhelming, or if we observe a spike in users bypassing mixed content blocking via settings (which would indicate that much of the breakage is in fact user-visible).

Edge: "Eh" (neither positive nor negative)

Firefox: Somewhat public support

Safari: Public support

Would be great to get more recent views regarding auto-upgrading and how likely they are to follow, specifically regarding images. Non-blocking though, as this poses no interop risk on them.

Web / Framework developers: We haven’t heard much specifically about images. We had 3 bugs filed since autoupgrades started, along with a few emails from web developers, but all concerning mixed audio.

Ergonomics

n/a

Activation

n/a

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

Blink layout tests are pending upstreaming.

Entry on the feature dashboard

https://www.chromestatus.com/feature/4926989725073408

--
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/CAABgKfVkZaV6%3D-8ykW1bScjWJLx7CFXhasgv5goc6uDXLEKs1A%40mail.gmail.com.

[Jochen Eisinger]

lgtm2

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

[Mike West]

LGTM3 \o/

I would like to see y'all follow up on Anne's suggestion around the spec in https://github.com/w3c/webappsec-mixed-content/issues/25#issuecomment-561521540. I think the changes you'd like to make are quite clear, but it would be ideal to capture them in an update to MIX. Is that on y'all's radar?

-mike

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

[Joe Medley]

Carlos,

Are you planning to ship without the flag in 82 or 83? Either way, please update the status entry.

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Carlos IL]

Thanks all for reviewing, to address the questions:

Yoav: Yes, there has been an insecure content console message at least since 2012 (which was as far back as I could go in source). We've also had one specific for autoupgrades since we started experimenting (this past November).

Mike: I do plan to update the spec to address the comments, will bump that to the top of my TODO now.

Joe: The plan is to roll this out slowly as mentioned in 81, we'll want to keep the flag around at least one more release, so it likely won't be removed until at least 83. 

Since we're soon starting to roll out in 81, should it remain behind a flag for 81 as of now, or is there a different status that's more appropriate?

Thanks all,

Carlos

[Yoav Weiss]

Did we end up shipping this? I noticed that the status entry says this is still in dev trial.

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

[Eric Lawrence]

This appears to be enabled by finch for all channels and platforms at 100% [1].

If CodeSearch is to be believed, two orphaned variables were left hanging around:

  const char kMixedContentAutoupgradeModeParamName[] = "mode";

  const char kMixedContentAutoupgradeModeAllPassive[] = "all-passive";

[1] "name": "AllPassiveMixedContentAutoupgrade",

            "consistency": "PERMANENT",

            "experiment": [

                {

                    "name": "EnabledLaunch",

                    "probabilityWeight": 100,

                    "param": [

                        {

                            "name": "mode",

                            "value": "all-passive"

                        }

                    ],

                "minVersion": "83.*",

                "maxVersion": "88.0.4295.0",

                "channel": [

                    "CANARY",

                    "DEV",

                    "BETA",

                    "STABLE"

                ],

                "platform": [

                    "PLATFORM_WINDOWS",

                    "PLATFORM_MAC",

                    "PLATFORM_LINUX",

                    "PLATFORM_CHROMEOS",

                    "PLATFORM_ANDROID"

[Carlos IL]

We did ship this, I've fixed the status now.

[Daniel Bratell]

Is it also enabled by default in the code and not just through Finch? There have been misunderstandings in the past where code has been left disabled by default which has resulted in features going missing in all non-Google variants of Chromium.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABgKfX0aM0ttS6eECja6EH%2BRSG-CADyNPS2C%2B_tuuHinBbKdQ%40mail.gmail.com.

[Eric Lawrence]

I believe it's on-by-default in 88+. It's on in Edge and we haven't enabled it via our ECS (Finch).

https://source.chromium.org/chromium/chromium/src/+/7e606471236e4a7eda1727334ddd44fe802b816a

const base::Feature kMixedContentAutoupgrade{"AutoupgradeMixedContent",

base::FEATURE_ENABLED_BY_DEFAULT};

[Carlos IL]

Yes, the feature flag is enabled by default in code.

-Carlos

[Stephen McGruer]

Apologies for the drive-by, but did the upstreaming of the tests to WPT happen here? https://crbug.com/1002571 appears to be outstanding still (with no CLs or activity on the bug itself).

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/CAABgKfVkZaV6%3D-8ykW1bScjWJLx7CFXhasgv5goc6uDXLEKs1A%40mail.gmail.com.

--
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.

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

--
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.