Page MenuHomePhabricator

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

Subscribers
Tokens
"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.

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.Thu, Oct 3, 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.Thu, Oct 3, 11:31 PM
Krinkle claimed this task.
TheDJ added a subscriber: TheDJ.Fri, Oct 4, 6:04 AM

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