Intent to Ship: mixed content autoupgrading for audio and video

[Emily Stark]

Contact emails

carlosil@google,com, est...@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 -- threaten users’ security and privacy, and also lead 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, but allows mixed images, audio, and video to load. We are planning to gradually move towards blocking all mixed content by default. To minimize breakage, we plan to autoupgrade mixed content to https:// rather than block it outright.

Since mixed audio and video are much less common than images, we would like to start by shipping autoupgrading for audio and video in M79.

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 mixed requests are shown in the DevTools network panel. We currently have a console message alerting developers when a request is upgraded due to the autoupgrading experiment (currently enabled at 50% of beta), and we’ll adapt the console message wording when we ship for real. Developers can also use CSP reporting to discover mixed content that they need to fix on their site.

Risks

Interoperability and Compatibility

We have two data sources to estimate breakage. One is the prevalence of mixed audio and video, and the other is the results of our autoupgrading experiment on beta.

Mixed audio occurs on 0.029% of page loads, so that is an upper-bound on breakage from shipping autoupgrading for audio. On beta, ~7.5% of mixed audio successfully upgrades to https://. We propose to ship first as a 1% experiment on stable (M79) to check that breakage numbers are in line with beta rather than shipping to 100% immediately.

Mixed video occurs on 0.080% of page loads. This is more significant, but on beta, mixed video autoupgrades much more successfully: ~75% of mixed video successfully upgrades to https://.

These numbers point to a non-trivial amount of breakage -- somewhere around 0.05% of page loads in total. However, we still think this change should be shipped for several reasons:

1. Mixed content presents a security/privacy risk to users. In addition to the immediate privacy gain from blocking cleartext traffic, blocking mixed content is a critical step in providing a robust defense against HSTS fingerprinting.

2. Users will be able to opt out when a webpage is broken, by toggling a setting.

3. We plan to precede the change with targeted outreach to affected sites (Search Console notifications, direct outreach to partners) as well as broad outreach (blog posts, press, etc.). We’ve found that such outreach is most effective when coupled with a firm timeline, which is why we’d like to have this I2S approved before we begin outreach in earnest.

Edge: "Eh" (neither positive nor negative)

Firefox: Somewhat public support

Safari: Public support

Web / Framework developers: We haven’t heard much. One bug filed in ~6 months that the experiment has been enabled on pre-stable channels.

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 to be upstreamed shortly.

Entry on the feature dashboard

https://www.chromestatus.com/features/5557268741357568

[EricLaw-MSFT]

To confirm, the plan is to ship this upgrade without the automatic "Fallback to HTTP" mode mentioned in the I2I, is that correct? We'll instead get the shield icon in the omnibox and an affected user can manually unblock?

Will the elements themselves (e.g. the <video> canvas and/or the <audio> controls, if present) have any indication of what's gone wrong when HTTP content has been blocked?

[Emily Stark]

On Wed, Sep 11, 2019 at 2:35 PM 'EricLaw-MSFT' via blink-dev <blin...@chromium.org> wrote:

To confirm, the plan is to ship this upgrade without the automatic "Fallback to HTTP" mode mentioned in the I2I, is that correct? We'll instead get the shield icon in the omnibox and an affected user can manually unblock?

That's correct. We are separately working on some changes to the bypass-mixed-content-blocking UI (moving it to settings) but those aren't finalized yet; we plan to publish that plan once the UI is finalized. (Via blog post, not blink-dev, since it's purely a Chrome UI change.)

 

Will the elements themselves (e.g. the <video> canvas and/or the <audio> controls, if present) have any indication of what's gone wrong when HTTP content has been blocked?

Nope, unless you convince me they should :)

 

--
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/7cae50a3-78b9-4d50-a539-b1da620909d8%40chromium.org.

[Mike West]

LGTM1.

As Emily notes, there will be some user-visible breakage due to this change. From a security perspective, it seems to me both that the risk of breakage is clearly outweighed by the benefits of protecting users from non-secure traffic, and that Emily and Carlos have done the legwork with experiments in pre-stable channels to show that the theoretical breakage isn't, practically, a show-stopper.

(I'm also confident that if it turns out to be a horrible disaster in stable in ways that their experimentation missed, they can quickly roll the change back and try again later. They've developed a good amount of experience with this model via other address bar experiments, and have a long record of keeping a careful eye on the right metrics.)

Blocking (or upgrading) all mixed content is the right endstate to aim for. I'm looking forward to y'all landing this step in that direction.

All that said: it would be helpful for y'all to put together some documentation about the enterprise configuration that would be necessary for sysadmins to centrally exclude MegaCorp, Inc.'s internal video and podcast server that will certainly be affected by this change. I assume that's possible via the content settings policy options they already have access to?

-mike

[Daniel Bratell]

LGTM2 - but please read the rest as well:

1) A lot of this change depends on being agile and reacting appropriately. I think that your actions so far shows that you are listening to affected parties and I am not surprised when you say that getting enough attention requires a firm date and not just some "in the future" hand waving. So if the breakage turns out to be more severe than expected, I'm convinced you'll take appropriate action.

2) Many of the changes mentioned, that make the initial phase into an acceptable experience, seems to involve the UI of Chrome/Chromium. There is a bunch of other Chromium based products around with different UIs. If you have any information and suggestions for those, can you please post that, along with necessary technical information, to embedd...@chromium.org ?

3) The chromestatus entry might need a clearer message since that is what will reach web developers through the beta blog post, but that might not matter if you're writing pieces that will be used instead of the chromestatus entry.

Good luck!

/Daniel

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

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Yoav Weiss]

LGTM3

The numbers look a bit high, but turning this on by default seems required as a forcing function for affected media providers to upgrade their servers.

And like Mike said, if we're seeing that breakage is higher than what we initially thought it would be, we can roll it back. For that purpose, it could be useful to roll this out gradually, so that if breakage is higher than expected, it won't hit all users before we catch it.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.z70alql8rbppqq%40cicero2.linkoping.osa.

[robo...@gmail.com]

Will there be a flag in chrome://flags/ to control this behaviour (for the time being)?

[Carlos IL]

Yes, I'll add a temporary flag to chrome://flags for the first few releases that have the behavior.

[Mark Scott]

When we started pushing HTTPS for video content ~4 years ago, a consistent objection of service providers was around cost; at least at that time, CDN providers charged somewhere around 30% more to serve an asset over HTTPS vs. what they charged for HTTP (actual costs were nominal, but CDNs were still charging for it).  A quick skim of North American CDNs seems to indicate that this has largely died out, and that there's no longer a premium for HTTPS.  Do we have good confidence that this is true, and that it holds worldwide?  It'd be nice for video sites not to receive an unexpectedly large bill at the end of the month because we auto-upgrade to HTTPS.

[David Benjamin]

This isn't quite the question you asked, but the numbers from the intent suggest that 75% of mixed video upgrades and mixed video occurs on 0.080% of page loads. That suggests that any impact here is limited to around 0.060% of page loads.

--
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/8c16cb0e-9032-4996-baf6-d633c3078f97%40chromium.org.

[Stephen McGruer]

It's not clear to me whether this ever shipped or not (the Chromestatus entry implies yes), but I happened to be perusing old blink intents and would like to note that the 'upstream tests' bug appears to never have been actioned: https://bugs.chromium.org/p/chromium/issues/detail?id=1002571

Assuming the feature did ship - were the tests ever upstreamed to WPT? If not, why not? (Having upstreamed tests is a big part of the Blink strategy for ensuring interoperability !)