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:monomium@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 <innocentkiller(a)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" <monomium(a)gmail.com> wrote:
Why not?
On Fri, Jun 3, 2011 at 1:19 PM, Huib Laurens <sterkebak(a)gmail.com> wrote:
> Thats completly not the point.
>
> 2011/6/3, Mono mium <monomium(a)gmail.com>om>:
>> 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 <markwdilley(a)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 <tstarling(a)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(a)lists.wikimedia.org
>>>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l(a)lists.wikimedia.org
>>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org