In an attempt to use TLS with external sites where possible, MW rewrites HTTP to HTTPS for all links to names rooted in those on a certain list maintained by Chromium.org.

Crucially, these websites have explicitly *asked* Chromium to be included in that list by virtue of adding the preload tag to their HTTP headers.

This strategy fails in two respects:

• forcing TLS where it is not available, as with icecast.rte.ie

This website misconfigured their HSTS unfortunately, and still hasn't gotten it fixed in the Chromium/Firefox lists. Whenever that happens, MediaWiki will pick up the change and roll it out within a month-ish. That's roughly what's to be expected in the HSTS guidelines.

• not using TLS where it is available, as with www.gnu.org

This is the status quo, so it's not really a loss.

Furthermore, what security it does provide is already matched exactly by many popular browsers.

Indeed, so we're not doing anything unique here. But there is a shrinking set of users who use browsers that don't support HSTS, and this provides a very small security benefit for them. Given the low complexity of SecureLinkFixer, it seems like a good win. Maybe in a few years we can turn off SecureLinkFixer, that would be pretty cool.

In T309959#7982486, @antichrome wrote:

Note: It is important that HSTS should be completely disregarded, and only HTTPS considered. E.g. if you request https://en.wikipedia.org/ and do not follow the location header (which is to the same domain), you will not receive the strict-transport-security header. (Seriously! Well, I didn't, anyway.)

What?

curl -I 'https://en.wikipedia.org/' | grep strict
strict-transport-security: max-age=106384710; includeSubDomains; preload

HSTS itself is so badly designed and badly implemented that the safest bet is to ignore it entirely. The same comments apply to the list.

No thanks.

In T309959#7982503, @antichrome wrote:

Suggestions for wikitext:

• <nohttps> tag by analogy with <nowiki> tag
• rewrite force-http to http
• rewrite <force>http or <forcehttp> or some other weird macro to http (could make future changes to parsing easier)

No thanks, the whole point of this is to do transparent rewrites.