Page MenuHomePhabricator

Drop IE6 and IE7 basic compatibility and security support
Closed, ResolvedPublic

Tokens
"Like" token, awarded by AlexisJazz."Like" token, awarded by ToBeFree."Like" token, awarded by Ladsgroup."Like" token, awarded by TK-999."Like" token, awarded by TheDJ."Like" token, awarded by Volker_E."Like" token, awarded by MusikAnimal."Like" token, awarded by Daimona."Like" token, awarded by Jdforrester-WMF.
Assigned To
Authored By
tstarling, Sep 11 2019

Description

I propose to remove the security features which protect IE6 and IE7 users from cross-site scripting attacks, and to remove IE6 and IE7 from "basic" support in the compatibility table.

Usage of these browsers is now 0.1% for IE6 and 0.07% for IE7 according to the last 7 days of pageviews_hourly data in Turnilo. In 2011, @demon wrote of supporting IE6: "I remain convinced that it's worth it-- at least for security issues--as long as a browser retains at least 1% market share" (ref). That threshold has evidently been passed.

Dropping security support would not necessarily mean dropping "basic" support (which mostly means CSS and HTML for readers), since the definition of basic support does not include security. However, note that IE5 basic support was dropped in October 2011. Usage at the time was 0.47% of HTML requests according to archived page view data. So IE6 is now much rarer than was IE5 when we dropped support for it.

It's previously been said that popularity in China was stopping us from dropping IE6 support. IE6 is now only 0.02% of requests from China.

Denying user login for these browsers would prevent XSS attacks on privileged users.

Consequent changes:

  • Drop WebRequest::checkUrlExtension() (T30235). This is the main rationale for this proposal since it is awkward to use with the REST API (T232556).
  • Simplify Sanitizer::normalizeCss() (T57332)

Optionally:

  • Replace IEContentAnalyzer with "X-Content-Type-Options: nosniff". IE8 retains content sniffing but introduces X-Content-Type-Options, but it would need to be sent for image requests, which we don't have full control over. We could use mod_headers in .htaccess, if available, and we could test for the header's presence in the installer. IEContentAnalyzer is a constant nuisance, as evidenced by gerrit 487527.

Related Objects

Mentioned In
T216308: RFC Process: 2019 amendments
T57332: Sanitizer::checkCss blacklist can be bypassed using vertical tab (ASCII 11)
Blog Post: Production Excellence: September 2019
T28059: Add support for KML/KMZ filetype
T5532: External link arrow doesn't appear at the start of a line
T18501: Images break text flow in IE7
T21134: IE7:Pressing enter discard selected namespaces in search box
T26378: Issues with edit box when replying to a thread in Internet Explorer 7
T20858: Can't open documents from Internet Explorer (IE) address bar thru img_auth.php
T235179: Implement workarounds in RESTBase and Flow to hit Parsoid/PHP REST API endpoints without an oldid for titles containing "."
T50189: [New form] Minor whitespace issues in IE7, for login and account create account
T124905: OOUI interfaces are hardly usable on IE 6 & 7
T124932: Look into not serving OOUI styles for IE 6 and 7
T176023: Spike: Determine whether it makes sense to implement IE7 correction for long-term trend charts
T234582: Remove IE 6 & 7 hacks and workarounds from core & extensions
T232556: Parsoid/PHP roundtrip testing: Period ( . ) in titles fail with a http 403 (Invalid file extension found in the path info or query string.) error
Mentioned Here
T27707: Allow "html" in exif tags
T30235: XSS: IE6 looks for the file extension in the query string
T57332: Sanitizer::checkCss blacklist can be bypassed using vertical tab (ASCII 11)
T232556: Parsoid/PHP roundtrip testing: Period ( . ) in titles fail with a http 403 (Invalid file extension found in the path info or query string.) error

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 11 2019, 5:10 AM

Just a note, Currently China has blocked accessing Wikipedia. On a hypothetical scenario, if they unblock it, it might increase the IE traffic back to a significant number (given that China is China, Out of top six most visited websites in the world, four them are in China). OTOH, this is very unlikely to happen.

CDanis added a subscriber: CDanis.Sep 11 2019, 8:30 PM

@Krinkle pointed out that IE6 and IE7 attempting to visit Wikipedia are typically redirected to an error page due to not supporting current TLS ciphers. I confirmed that this is the case using the webrequest_sampled_128 table in analytics via Turnilo. For UAs containing "MSIE 6.0", 71% of requests result in a 301 status code, whereas for all UAs, 3% of requests result in a 301 status code. So IE6 and IE7 are already thoroughly broken for readers.

The same kind of query also confirms that IE7 users are mostly seeing redirects, whereas IE8 still works. Of course it would be possible to extend support for non-WMF users of MediaWiki, but I don't think we should do that.

Just a note, Currently China has blocked accessing Wikipedia. On a hypothetical scenario, if they unblock it, it might increase the IE traffic back to a significant number (given that China is China, Out of top six most visited websites in the world, four them are in China). OTOH, this is very unlikely to happen.

In page views from Hong Kong, IE6 is 0.3%. I don't think there is any chance of IE6 usage significantly increasing due to China being unblocked, and like I say above, it is completely broken for Wikipedia readers.

From today's meeting we had general consensus to move forward with this RFC. The RFC author (Tim) nor the rest of those present found any concerns.

For WMF traffic, our understand is that IE6 and IE7 are already unable to access the wikis. This is due to modern HTTPS requirements being mutually exclusive with supporting IE6. In a nut shell: So long as WMF servers advertise the outdated TLS ciphers from IE6 and allow new connections to be established with it. any attacker (MITM, public wifi, various agencies) could proxy a user with a modern browser as part of a downgrade attack. As such, in years past the SRE Traffic team has already removed networking support for IE6 and IE7.

There are a few open questions and stakeholders we do want to have answers/heard from before approving it:

  • Despite these TLS protections for WMF traffic, the Analytics's browser usage reports still include IE6 and IE7 (and as such being above the 0.01% cut off used for the report). We should confirm where these come from. The suspicion is that maybe this report includes stats for non-pageview urls (such as our TLS redirect), or page views for Wikitech. In which case that might explain where the numbers come from.
  • From a product perspective, we'd like to hear from Core Platform Team PMs whether we are comfortable dropping Grade C support for third-party wikis for IE6/IE7. Specifically this would mean the semantic HTML and CSS layout might start to show visible defects in future releases, and it would mean we no longer employ proactive security measures for users of these browsers. For example, we currently have logic in place for all web requests in PHP that detect possible bugs in IE6 that could misinterpret a user-generated asset as HTML to prevent execution of insecure JavaScript. We would no longer have these protections in place and thus treat these users the same way we already treat users of IE5 and Firefox 2. (Ping for PMs and third-party stakeholders: @CCicalese_WMF, @Osnard, @TK-999).
  • From a community perspective, we'd like to hear if we know of anyone in the Wikimedia movement still able to use IE6 or IE7 to access Wikimedia projects and whether they are dependent on those browsers. (See also wikitech:HTTPS recommendations). (Ping @Trizek-WMF, @Ckoerner, @WhatamIdoing)
Krinkle triaged this task as High priority.Sep 11 2019, 10:17 PM
Krinkle moved this task from Inbox to Under discussion on the TechCom-RFC board.

Thank you for the notice :) From our (Wikia) standpoint, we have been requiring[1] TLS >= 1.2 for some time now like WMF does, preventing IE6/7 from accessing our sites. So dropping official support for these browsers should not be an issue from our perspective.

[1] https://www.fastly.com/blog/phase-two-our-tls-10-and-11-deprecation-plan

Trizek-WMF removed a subscriber: Trizek.Sep 12 2019, 9:50 AM

Browsers are not the pain point for users when they report bugs and issues (more local scripts and changes in design and workflows). For cases I remember and I've checked on quickly, users are all up to date when we ask about their browser.

(Please don't use my personal account if you have questions that are related to community relations work, thanks! :))

  • From a product perspective, we'd like to hear from Core Platform Team PMs whether we are comfortable dropping Grade C support for third-party wikis for IE6/IE7. Specifically this would mean the semantic HTML and CSS layout might start to show visible defects in future releases, and it would mean we no longer employ proactive security measures for users of these browsers. For example, we currently have logic in place for all web requests in PHP that detect possible bugs in IE6 that could misinterpret a user-generated asset as HTML to prevent execution of insecure JavaScript. We would no longer have these protections in place and thus treat these users the same way we already treat users of IE5 and Firefox 2. (Ping for PMs and third-party stakeholders: @CCicalese_WMF, @Osnard, @TK-999).

From the Core Platform Team PM perspective, this is fine. I've also reached out to some third-party stakeholders who confirm this should not be a problem for them.

RhinosF1 added a subscriber: RhinosF1.EditedSep 17 2019, 3:24 PM

Spoke to other members of Miraheze and no issue from us as we require TLS 1.2 + which isn't supported by these IE versions and a quick scan of our statistics systems isn't coming up with many visits from these browsers.

So +1 from me on dropping support, just make sure to make it clear in release notes.

daniel added a subscriber: daniel.

This RFC has entered the Last Call period per the TechCom meeting on September 18. The last call will end on October 2nd. If no issues remain unaddressed by that time, this RFC will be approved as proposed.

Volker_E added a subscriber: Volker_E.
TK-999 awarded a token.Oct 3 2019, 7:30 PM

The proposed outcome to approve this RFC, based on the consensus from two weeks ago, is now official. There were no objections or concerns raised.

Thanks everyone.

The guideline document at mw:Compatibility has been updated to reflect this decision.

Krinkle closed this task as Resolved.Oct 3 2019, 11:31 PM
Krinkle claimed this task.
TheDJ added a subscriber: TheDJ.Oct 4 2019, 6:04 AM

Note: Without contentanalyzer, we probably can also support KML uploads.

Krinkle updated the task description. (Show Details)Oct 24 2019, 11:57 PM

Change 546306 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] Add release notes for discontinuation of IE6/7 support

https://gerrit.wikimedia.org/r/546306

Change 546311 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@REL1_34] Add release notes for discontinuation of IE6/7 support

https://gerrit.wikimedia.org/r/546311

Change 546311 merged by jenkins-bot:
[mediawiki/core@REL1_34] Add release notes for discontinuation of IE6/7 support

https://gerrit.wikimedia.org/r/546311

Change 546306 merged by jenkins-bot:
[mediawiki/core@master] Add release notes for discontinuation of IE6/7 support

https://gerrit.wikimedia.org/r/546306

AlexisJazz added subscribers: revi, AlexisJazz.EditedSun, Nov 17, 7:38 AM

@tstarling @Krinkle thanks to the both of you! What surprises me is that it seems the discussion on Commons at the beginning of this year (which was quite heated) and the resolving of T27707 as a result only a few months before this task was created happened, seemingly, completely independent from each other. Also, I'm surprised to see it actually is possible to drop support for dead browsers. We were lead to believe it was impossible.. Also see comments like the one from @revi : "I'm sure WMF will reject this. Don't waste your time. Bye."

It seems there is a severe disconnect between the community and the Phabricatorians/WMF. I don't really have a solution, we'd be happy to reach out but don't know how. You guys should know where our Village Pump is, but we don't hear very often from you. And a ticket like this one is essentially invisible for us. I just found this by accident, way after it was implemented.

Btw, in T27707 it was also found (which everyone here appears to have missed) that IE7 should still work.. on Vista. So that's pretty irrelevant, because most people would rather be found dead in a ditch than admit they're running Windows Vista. :-P

revi removed a subscriber: revi.Sun, Nov 17, 7:39 AM
CKoerner_WMF edited subscribers, added: CKoerner_WMF; removed: Ckoerner.Sun, Nov 17, 7:34 PM

we don't hear very often from you.

If you wish to be informed in technical decisions happening within the movement, there are many methods to do so. One I would recommend all technically-minded volunteers subscribe to is Tech News. Which is published weekly to over 800 pages in over a dozen languages. Commons Village Pump included. This news was communicated on October 14th, a month ago.

I'm sorry you feel left out of the loop and I hope this advice proves fruitful for your continued involvement.

Change 552679 had a related patch set uploaded (by Tim Starling; owner: Tim Starling):
[mediawiki/core@master] Remove IE 6 security features

https://gerrit.wikimedia.org/r/552679

Change 552931 had a related patch set uploaded (by Tim Starling; owner: Tim Starling):
[mediawiki/core@master] Remove IE 6 security features from JS code

https://gerrit.wikimedia.org/r/552931

I'll reply to @AlexisJazz by private email.

CKoerner, Aklapper, thanks. I still see room for improvement, perhaps something like a separate section in the newsletter for stuff that can still be commented on and hasn't been decided yet.

I'll reply to @AlexisJazz by private email.

I'd rather keep communication public, be it here or on a wiki discussion page. But as we're here.. In the email (if you want to share the whole mail I'll leave that to you) you call the discussion on Commons a waste of time and suggest we should have just filed an RFC. To this I say:

"YOU CAN FILE RFCs ON PHABRICATOR?"

You assume everyone knows everything. But how you work is a mystery for us. If Forrester had said I should file an RFC (and how), I would have! And well, I guess he *kinda* did: "You can file a technical RfC in Phabricator to stop checking for security vulnerabilities in uploaded files, but I would point out that there's no way we're dropping basic security controls like this, sorry."

So why in the name of all that's holy would I have bothered to figure out how to file a technical RfC? It would be ignored anyway!

You also comment on how impractical a local exception for Commons would be. You might be surprised to hear that I agree. It was absolutely ridiculous, but Forrester told us a technical RfC would be futile, so guess what? We go guerrilla and just make noise. Because there was nothing else we could do. And you can't deny: it worked. I would have preferred the civil solution, really. I literally asked "How to propose a change to the MediaWiki software?" and was basically told to bugger off. You really can't blame me, the Commons community or the drama on our noticeboards for this. This is entirely on you guys. We tried.

brion added a comment.Tue, Nov 26, 6:22 PM

@AlexisJazz sorry about any frustration from the on-Commons discussion in January. It took some discussion of our own on Phabricator to decide what to do, both about the incorrect HTML security trigger and about the more general removal of obsolete checks, and communication wasn't and still isn't very consistent. Sometimes you get advice on-wiki that's based on the current general state of things, but the state of things changes -- we have indeed decided that the IE 6/7 content-type-sniffing vulnerability is no longer a serious security consideration, but in January we hadn't decided that yet so you were given advice based on the current state of the world.

The one thing I will say is that Commons is only one affected site; this is part of MediaWiki core and affects all sites. It would have been wise to drop a visible note early on to our most populous file-upload wiki's community when we started talking about this again a few weeks ago, though. Including it in Tech News was good, but we could probably do better about reaching users where they are.

If there's anything else concrete we can do for this particular case, please let us know.

As far as filing RfCs etc -- keep in mind that different wikis and areas of work have different "RfC" processes. Some are more ordered than others, some use the wikis, some use phab. (I'm pretty sure Commons has some kind of RfC process on-wiki?) I recommend if you're not sure where to start, don't worry about the process yet -- but *DO* file a task in Phabricator. Otherwise us techies will not easily be able to track it or tell what past discussion has already occurred, and getting something done becomes very unlikely unless it's independently raised later (as happened here).

If there's anything else concrete we can do for this particular case, please let us know.

Thank you. For this case, I think everything is fine now. I was just surprised to see how discussions about virtually the same subject took place without them being connected. It would perhaps have been more efficient if there had been a link. (T27707 contained plenty of relevant information)

As far as filing RfCs etc -- keep in mind that different wikis and areas of work have different "RfC" processes. Some are more ordered than others, some use the wikis, some use phab. (I'm pretty sure Commons has some kind of RfC process on-wiki?)

Yes, while https://commons.wikimedia.org/wiki/Commons:Requests_for_comment is abandoned, we use https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals for this purpose now.

I recommend if you're not sure where to start, don't worry about the process yet -- but *DO* file a task in Phabricator. Otherwise us techies will not easily be able to track it or tell what past discussion has already occurred, and getting something done becomes very unlikely unless it's independently raised later (as happened here).

Thank you, I will.

Change 552679 merged by jenkins-bot:
[mediawiki/core@master] Remove IE 6 security features from server-side code

https://gerrit.wikimedia.org/r/552679