Change Details

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 [[https://www.mediawiki.org/wiki/Compatibility|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" ([[https://lists.wikimedia.org/pipermail/wikitech-l/2011-June/053690.html|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 [[https://stats.wikimedia.org/archive/squid_reports/2011-10/SquidReportClients.htm|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 [[https://gerrit.wikimedia.org/r/c/mediawiki/core/+/487527|gerrit 487527]].

(NOTE) Updated compatibility policy at: **<https://www.mediawiki.org/wiki/Compatibility#Browsers>** 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 [[https://www.mediawiki.org/wiki/Compatibility|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" ([[https://lists.wikimedia.org/pipermail/wikitech-l/2011-June/053690.html|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 [[https://stats.wikimedia.org/archive/squid_reports/2011-10/SquidReportClients.htm|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 [[https://gerrit.wikimedia.org/r/c/mediawiki/core/+/487527|gerrit 487527]].

(NOTE) Updated compatibility policy at: **<https://www.mediawiki.org/wiki/Compatibility#Browsers>** 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 [[https://www.mediawiki.org/wiki/Compatibility|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" ([[https://lists.wikimedia.org/pipermail/wikitech-l/2011-June/053690.html|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 [[https://stats.wikimedia.org/archive/squid_reports/2011-10/SquidReportClients.htm|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 [[https://gerrit.wikimedia.org/r/c/mediawiki/core/+/487527|gerrit 487527]].