Anyone who has control of the computer they use can upgrade, but a surprising (depressing?) number of people don't have that kind of control. In particular, schools and libraries are notorious for being stuck with failbrowsers of one sort or another, and a significant number of people depend on these sorts of places for their only Internet access. I'm not sure we're yet at the stage where *most* people using IE6 don't have the ability to upgrade, but as time goes on that proportion is only going to get larger. What's the use in annoying people to try and get them to do something they can't do?
You're right that any sane IT department should have upgraded years ago. Unfortunately, many IT departments are not driven by sanity, and even those that are, sometimes their bosses are not. -----Original Message----- From: Mono mium [mailto:[email protected]] Sent: Friday, June 03, 2011 4:36 PM To: Wikimedia developers Subject: Re: [Wikitech-l] IE6 Anyone can upgrade, Chad. It's not hard and any sane IT department should have done it six years ago. On Fri, Jun 3, 2011 at 1:34 PM, Chad <[email protected]> wrote: > We shouldn't throw annoying text/graphics at people who > probably *cant* upgrade. > > -Chad > On Jun 3, 2011 4:27 PM, "Mono mium" <[email protected]> wrote: >> Why not? >> >> On Fri, Jun 3, 2011 at 1:19 PM, Huib Laurens <[email protected]> wrote: >>> Thats completly not the point. >>> >>> 2011/6/3, Mono mium <[email protected]>: >>>> We don't want to use Microsoft's, whatever we do, because it promotes > their >>>> own borked browser IE9. >>>> >>>> On Fri, Jun 3, 2011 at 11:30 AM, Mark Dilley <[email protected]> > wrote: >>>> >>>>> <aside from main conversation> >>>>> >>>>> Would it be a good community gesture to join Microsoft in trying to >>>>> eradicate IE6? >>>>> >>>>> http://TheIE6Countdown.com >>>>> >>>>> or to not join them and put up a more general banner >>>>> >>>>> http://IE6NoMore.com >>>>> >>>>> and move on? >>>>> >>>>> </aside from main conversation> >>>>> >>>>> >>>>> On 03Jun2011, at 10:53 AM, Brion Vibber wrote: >>>>> >>>>> > On Thu, Jun 2, 2011 at 5:21 PM, Tim Starling <[email protected] >>>>> >wrote: >>>>> > >>>>> >> On 03/06/11 06:56, Brion Vibber wrote: >>>>> >>> For 1) I'm honestly a bit willing to sacrifice a few IE 6 users at >>>>> >>> this >>>>> >>> point; the vendor's dropped support, shipped three major versions, > and >>>>> is >>>>> >>> actively campaigning to get the remaining users to upgrade. :) But > I >>>>> get >>>>> >>> protecting, so if we can find a workaround that's ok. >>>>> >> >>>>> >> We can't really do this without sending "Vary: User-Agent", which >>>>> >> would completely destroy our cache hit ratio. For people who use > Squid >>>>> >> with our X-Vary-Options patch, it would be possible to use a very > long >>>>> >> X-Vary-Options header to single out IE 6 requests, but not everyone >>>>> >> has that patch. >>>>> >> >>>>> > >>>>> > I'm really thinking more along the lines of: if someone's an IE >>>>> 6-or-below >>>>> > user they have hundreds of other exploit vectors staring them in the >>>>> > face >>>>> > too, and we can't protect them against many of them -- or ANY of them > if >>>>> > they're visiting other sites than just an up-to-date MediaWiki. >>>>> > >>>>> > The cost of this fix has been immense; several versions of the fix > with >>>>> > varying levels of disruption on production sites, both for IE 6 users >>>>> > and >>>>> > non-IE 6 users, and several weeks of delay on the 1.17.0 release. >>>>> > >>>>> > I'd be willing to accept a few drive-by downloads for IE 6 users; > it's >>>>> not >>>>> > ideal but it's something that their antivirus tools etc will already > be >>>>> > watching out for, that end-users already get trained to beware of, > and >>>>> that >>>>> > will probably *still* be exploitable on other web sites that they > visit >>>>> > anyway. >>>>> > >>>>> > >>>>> > The main issue here is that we don't a wide variety of web servers > set >>>>> >> up for testing. We know that Apache lets you detect %2E versus dot > via >>>>> >> $_SERVER['REQUEST_URI'], but we don't know if any other web servers > do >>>>> >> that. >>>>> >> >>>>> >> Note that checking for %2E alone is not sufficient, a lot of >>>>> >> installations (including Wikimedia) have an alias /wiki -> >>>>> >> /w/index.php which can be used to exploit action=raw. >>>>> >> >>>>> > >>>>> > Well that should be fine; as long as we can see the "/wiki?/foo.bat" >>>>> > then >>>>> we >>>>> > can identify that it doesn't contain an unencoded dot in the path. >>>>> > >>>>> > It sounds like simply checking REQUEST_URI when available would >>>>> > eliminate >>>>> a >>>>> > huge portion of our false positives that affect real-world > situations. >>>>> > Apache is still the default web server in most situations for most >>>>> > folks, >>>>> > and of course runs our own production servers. >>>>> > >>>>> > >>>>> >> >>>>> >>> Are there any additional exploit vectors for API output other than >>>>> >>> HTML >>>>> >> tags >>>>> >>> mixed unescaped into JSON? >>>>> >> >>>>> >> Yes, all other content types, as I said above. >>>>> >> >>>>> > >>>>> > Only as drive-by downloads, or as things that execute without >>>>> interaction? >>>>> > >>>>> > >>>>> >> I think the current solution in trunk, plus the redirect idea that >>>>> >> I've been discussing with Roan, is our best bet for now, unless >>>>> >> someone wants to investigate $_SERVER['REQUEST_URI']. >>>>> >> >>>>> > >>>>> > *nod* Checking REQUEST_URI is probably the first thing we should do > when >>>>> > it's available. >>>>> > >>>>> > >>>>> >> If there is an actual problem with ForeignAPIRepo then we can look > at >>>>> >> server-side special cases for it. But r89248 should allow all API >>>>> >> requests that have a dotless value in their last GET parameter, and > a >>>>> >> quick review of ForeignAPIRepo in 1.16 and trunk indicates that it >>>>> >> always sends such requests. >>>>> >> >>>>> > >>>>> > Yay! That's one less thing to worry about. :D >>>>> > >>>>> > >>>>> >> Since we're talking about discarded solutions for this, maybe it's >>>>> >> worth noting that I also investigated using a Content-Disposition >>>>> >> header. The vulnerability involves an incorrect cache filename, and >>>>> >> it's possible to override the cache filename using a >>>>> >> Content-Disposition "filename" parameter. The reason I gave up on it >>>>> >> is because we already use Content-Disposition for wfStreamFile(): >>>>> >> >>>>> >> header( "Content-Disposition: >>>>> >> inline;filename*=utf-8'$wgLanguageCode'" . urlencode( basename( > $fname >>>>> >> ) ) ); >>>>> >> >>>>> >> IE 6 doesn't understand the charset specification, so it ignores the >>>>> >> header and goes back to detecting the extension. >>>>> >> >>>>> > >>>>> > Good to know. >>>>> > >>>>> > -- brion >>>>> > _______________________________________________ >>>>> > Wikitech-l mailing list >>>>> > [email protected] >>>>> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l >>>>> >>>>> >>>>> _______________________________________________ >>>>> Wikitech-l mailing list >>>>> [email protected] >>>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >>>>> >>>> _______________________________________________ >>>> Wikitech-l mailing list >>>> [email protected] >>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >>>> >>> >>> -- >>> Verzonden vanaf mijn mobiele apparaat >>> >>> Kind regards, >>> >>> Huib Laurens >>> WickedWay.nl >>> >>> Webhosting the wicked way. >>> >>> _______________________________________________ >>> Wikitech-l mailing list >>> [email protected] >>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >>> >> >> _______________________________________________ >> Wikitech-l mailing list >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
