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