Page MenuHomePhabricator

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

Assigned To
Authored By
tstarling
Sep 11 2019, 5:10 AM
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.

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
T178356: Raise Grade A JavaScript requirement from ES5 (2009) to ES6 (2015)
T254061: intersection parser test failures
T248061: RFC: Remove IE 8 from basic support
T134068: Bump browser compatibility for Safari 5 and 6 from Modern to Basic.
T216308: RFC: 2019 Process amendments
T57332: Sanitizer::checkCss blacklist can be bypassed using vertical tab (ASCII 11)
Blog Post: Production Excellence #15: 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
rMW164a3ac1f099: Remove IE 6 security features from server-side code
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

There are a very large number of changes, so older changes are hidden. Show Older Changes

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.EditedNov 17 2019, 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.Nov 17 2019, 7:39 AM
CKoerner_WMF edited subscribers, added: CKoerner_WMF; removed: Ckoerner.Nov 17 2019, 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.Nov 26 2019, 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

Change 558763 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[operations/mediawiki-config@master] Follows-up 164a3ac1f099 which removed IEUrlExtension from MediaWiki and has been deployed to all wikis since.

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

Change 558763 merged by jenkins-bot:
[operations/mediawiki-config@master] CommonSettings.php: Remove 'SERVER_SOFTWARE' override

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

Mentioned in SAL (#wikimedia-operations) [2020-02-12T20:49:40Z] <krinkle@deploy1001> Synchronized wmf-config/CommonSettings.php: T232563 - Remove SERVER_SOFTWARE override (duration: 01m 03s)

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

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

Change 584677 had a related patch set uploaded (by Tacsipacsi; owner: Tacsipacsi):
[mediawiki/core@master] Remove IE6 & IE7 from the list of Grade C browsers in startup.js

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

Change 584677 merged by jenkins-bot:
[mediawiki/core@master] resourceloader: Remove IE6 & IE7 from the Grade C comment in startup.js

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

Change 596915 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/core@master] EditPage: Remove IE6 supporting useInputTag use

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

thiemowmde reopened this task as Open.EditedMay 18 2020, 6:16 PM
thiemowmde added a subscriber: thiemowmde.

I was just looking up the compatibility matrix. Google suggested https://www.mediawiki.org/wiki/Compatibility/Software_for_using_MediaWiki#Grade_B. IE6 is still listed for basic support there.

Is this a mistake? Yes and no. The page was marked as being obsolete, but this was very easy to miss. We made it a redirect now.

I was just looking up the compatibility matrix. Google suggested https://www.mediawiki.org/wiki/Compatibility/Software_for_using_MediaWiki#Grade_B. IE6 is still listed for basic support there. Is this a mistake?

https://www.mediawiki.org/wiki/Compatibility/Software_for_using_MediaWiki#Grade_B is obselete, https://www.mediawiki.org/wiki/Compatibility#Browsers is the current standard: basic for IE8, modern for IE11

Change 597140 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/core@master] Remove more IE6 and IE7 compatibility and notes

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

Krinkle closed this task as Resolved.May 18 2020, 8:12 PM

Change 597140 merged by jenkins-bot:
[mediawiki/core@master] Remove more IE6 and IE7 compatibility and notes

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

Change 596915 abandoned by DannyS712:
EditPage: Remove IE6 supporting useInputTag use

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

Change 614090 had a related patch set uploaded (by Thiemo Kreuz (WMDE); owner: Pwirth):
[mediawiki/extensions/NSFileRepo@master] Remove usage of deprecated IE6/IE7 XSS protection

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

Change 614090 merged by jenkins-bot:
[mediawiki/extensions/NSFileRepo@master] Remove usage of deprecated IE6/IE7 XSS protection

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