Good point Ronald, The more people who are constantly told this message - the more will put pressure on their IT departments to change.
That is how lots of change happens. Pressure. I think that Wikipedia's place in the internet community as all things encyclopedic will help this change. How much time would it save WikiMedia engineers (volunteer & staff) if we did something like this instead of engineering for IE6? /me done with this line of thought, thanks for the consideration --- Mark On 03Jun2011, at 1:47 PM, Greenman, Ronald (NIH/CIT) [C] wrote: > 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:monom...@gmail.com] > 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 <innocentkil...@gmail.com> wrote: >> We shouldn't throw annoying text/graphics at people who >> probably *cant* upgrade. >> >> -Chad >> On Jun 3, 2011 4:27 PM, "Mono mium" <monom...@gmail.com> wrote: >>> Why not? >>> >>> On Fri, Jun 3, 2011 at 1:19 PM, Huib Laurens <sterke...@gmail.com> wrote: >>>> Thats completly not the point. >>>> >>>> 2011/6/3, Mono mium <monom...@gmail.com>: >>>>> 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 <markwdil...@gmail.com> >> 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 <tstarl...@wikimedia.org >>>>>>> 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 >>>>>>> Wikitech-l@lists.wikimedia.org >>>>>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Wikitech-l mailing list >>>>>> Wikitech-l@lists.wikimedia.org >>>>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >>>>>> >>>>> _______________________________________________ >>>>> Wikitech-l mailing list >>>>> Wikitech-l@lists.wikimedia.org >>>>> 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 >>>> Wikitech-l@lists.wikimedia.org >>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >>>> >>> >>> _______________________________________________ >>> Wikitech-l mailing list >>> Wikitech-l@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> _______________________________________________ >> Wikitech-l mailing list >> Wikitech-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
