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: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@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@gmail.com wrote:
Why not?
On Fri, Jun 3, 2011 at 1:19 PM, Huib Laurens sterkebak@gmail.com wrote:
Thats completly not the point.
2011/6/3, Mono mium monomium@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 markwdilley@gmail.com
wrote:
<aside from main conversation>
Would it be a good community gesture to join Microsoft in trying to eradicate IE6?
or to not join them and put up a more general banner
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@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