1601408 - Enable security.mixed_content.upgrade_display_content (Upgrade all mixed content to https)

Status: RESOLVED DUPLICATE of bug 1633743

(Core :: Security, enhancement, P3)

Description

[Darkspirit]

https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html
Chrome 81 will upgrade all mixed content to https. Firefox should do it, too.

https://chromiumdash.appspot.com/schedule
Chrome's 81 circle begins this month, feature freeze will be 2019-01-17. It will become Beta 2020-02-13 and be released 2020-03-17.
https://wiki.mozilla.org/Release_Management/Calendar
Nightly 74: 2020-01-06, Beta 74: 2020-02-10, Stable 74: 2020-03-10.

Comment 1

[Meinert]

As long as this is implemented in a way that allows for automatic fallback if the content request that was upgraded is not available over https or users are given the option to "white-list" domains/urls so that upgrades are not performed. I still see lots of passive content served over http without the option of https and it would be annoying if all of that broke... again

Comment 2

[Darkspirit]

If you visit an https:// site, http:// resources would then be fetched via https://, otherwise fail to load. Your concern could be a strong argument to withhold this going into release by one or two versions, until server administrators have fixed their https setup. Then you could still manually turn this privacy feature off on about:config.

Chrome Blog:

Users will be able to enable a setting to opt out of mixed content blocking on particular websites

It seems you cannot whitelist such sites at the moment as this option is not present: https://support.mozilla.org/en-US/kb/mixed-content-blocking-firefox#w_unblock-mixed-content

Comment 3

[Darkspirit]

Currently implementation upgrades subresources to https before mixed content blocking kicks in.
Are you intending to keep current implementation or to replace actual blocking with upgrading to keep mixed content blocking opt out UI (though without showing a yellow triangle anymore)?

Comment 4

[Jonathan Kingston [:jkt] he/him]

We don't have immediate plans for implementing this at the moment. We may re-address this in the new year. I suspect that we would want to also add in the exemption UI much as we have for mixed content.

Comment 5

[Daniel Veditz [:dveditz]]

I'm surprised we didn't already have this bug filed. We've certainly discussed this--amongst ourselves and in the standards group that wrote the mixed-content-blocking spec--and are actively watching the results of Chrome's experiments. Our current impression is that it will break too much stuff, and we're not keen to add a fallback. We've experimented with fallback and the experience sucks -- you have to wait for the original request to time out before you try the load that's going to work.

Anyway, the engineering work is relatively simple: we already have a pref because we've experimented with it. The hard part is knowing when we could do it without causing a user revolt.

Comment 6

[monteiro]

I have found a bug? Sometimes when searching startpage.com with this setting enabled it won't return any results and the page shows this error message: "Startpage.com has encountered an error. Please try again. Many thanks for your patience and understanding. "

Anyway chrome 81 has been released with this feature.

Comment 7

[:Harald Kirschner :digitarald]

"Autoupgrade Image Mixed Content" is getting enabled in Chrome 84, after being through trials/experiments: https://blog.chromium.org/2020/05/chrome-84-beta-web-otp-web-animations.html?m=1

Comment 8

[u666667]

In latest version of Chrome Canary (at least on my Windows 10 machine) I can confirm that this change is already deployed. If you go to https://www.bennish.net/mixed-content.html while running Canary, all mixed content is autoupgraded to HTTPS without fallback (hence blocked). This includes not only images but audio and video as well

Comment 9

[Mathew Hodson]

security.mixed_content.upgrade_display_content was enabled in Nightly by bug 1633743, so I think you can mark this as a duplicate of that bug.

Bug 1672106 was filed to enable the pref for release.

Comment 10

[Darkspirit]

Yes, I would consider this as fixed. Thank you :)