This header currently results in Chrome changing all HTTP requests opened from the page to use HTTPS. It is not limited to requests to same host origin.

That will break user scripts interacting with third-party services that may not support HTTPS.

In T101002#1326438, @Krinkle wrote:

This header currently results in Chrome changing all HTTP requests opened from the page to use HTTPS. It is not limited to requests for to same host origin.

That will break user scripts interacting with third-party services that may not support HTTPS.

Do we have or even want third-party services hosted outside of our control hooked into our primary wiki domains via JS? I would've thought not, but I donno! Even if so, I think if they lack HTTPS they're even more of a risk.

Also, we may want to merge tasks one direction or the other with T36670. Personally, I'm a fan of setting this for all the wikis, perhaps doing it from the Varnish clusters and covering virtually all services in one fell swoop.

In T101002#2500137, @BBlack wrote:

In T101002#1326438, @Krinkle wrote:

This header currently results in Chrome changing all HTTP requests opened from the page to use HTTPS. It is not limited to requests for to same host origin.

That will break user scripts interacting with third-party services that may not support HTTPS.

Do we have or even want third-party services hosted outside of our control hooked into our primary wiki domains via JS?

No, not by default in any WMF-maintained code. And any user gadgets I'm thinking of don't hand over control in anyway, either. They don't load scripts, but rather just display images or load JSON from an API. There's no real risk there. These are opt-in gadgets and the only concern there is the third-party getting general client information and the page referer (sometimes) - which is unavoidable and allowed if the user opted-in.

I'm not defending this and any individual could obviously work around or mitigate it. The problem is that whenever a bold restriction like this is added across the entire spectrum there is a very long tail of smaller gadgets and user scripts affected that literally takes years to resolve.

In 2011 wikibits.js and sajax.js were deprecated. Sajax was only removed after 5 years later in 2016, and Wikibits is mostly being removed in this year. And those were relatively easy migrations!

Basically, adding Upgrade-Insecure-Requests (UIR) has the same problems as CSP (T135963: Add support for Content-Security-Policy (CSP) headers in MediaWiki). Users would likely want a way to opt-out, which certain gadgets would require the user to enable first.

The alternative is to proactively reach out and help migrate the vast majority of impacted gadgets before we enabled UIR. In that scenario we'd never need any opt-out and could just remove support for insecure interactions. The only downside is that it requires migration before instead of after we enable it for most users. I'd prefer to have UIR enabled sooner rather than later.

As such, applying it to logged-out users first would be good start.

The swap of Traffic for Traffic-Icebox in this ticket's set of tags was based on a bulk action for all such tickets that haven't been updated in 6 months or more. This does not imply any human judgement about the validity or importance of the task, and is simply the first step in a larger task cleanup effort. Further manual triage and/or requests for updates will happen this month for all such tickets. For more detail, have a look at the extended explanation on the main page of Traffic-Icebox . Thank you!