There has been some recent discussion at [[MediaWiki talk:Blockedtext]] about providing specific instructions for AOL users who find the IP of their proxy blocked, similar to how we provide instructions for users editing from China.
It seems the German Wikipedia already advises blocked AOL users to use a different browser (like Firefox), as this apparently bypasses the proxy setup the standard AOL browser is configured to use. They even held a (failed) poll to rangeblock the entire AOL proxy range, forcing anyone editing from AOL to do this.
Give this, there are a number of questions I'd like help answering:
1. Does using a different browser really help? Does it work on both Windows and Mac? If you're on AOL, you can check this by opening the link http://en.wikipedia.org/wiki/Special:Mypage in an alternative browser while not logged in to Wikipedia, and comparing the address shown to the list at http://webmaster.info.aol.com/proxyinfo.html.
2. Can the AOL browser itself be configured to bypass the proxies? Can this be done for Wikipedia only? And again, does this work on Mac OS X too, since AOL uses a different browser there?
...and finally, something I'm sure is controversial:
3. If a sufficiently easy way to circumvent the AOL proxies was found, would you support rangeblocking the proxies permanently (or until AOL fixes their proxies to provide XFF headers)? This would force anyone editing from AOL to bypass the proxies somehow, but would also make blocking AOL vandals much easier. And what would you consider "sufficiently easy"?
In any case, answers to 1 and 2 above would let us amend the block notice to suggest workarounds for AOL users accidentally caught in a block. Presumably there are people with AOL accounts on this list; if you're one of them, your help is needed.
On 3/26/06, Ilmari Karonen nospam@vyznev.net wrote:
- If a sufficiently easy way to circumvent the AOL proxies was found,
would you support rangeblocking the proxies permanently (or until AOL fixes their proxies to provide XFF headers)? This would force anyone editing from AOL to bypass the proxies somehow, but would also make blocking AOL vandals much easier. And what would you consider "sufficiently easy"?
Dear newbie, We don't like your ISP. No, that's not true. We hate your ISP. What's more, you're probably a vandal. If you'd like to contribute to Wikipedia, please jump through the following hoops. Thank you!
Steve
Steve Bennett wrote:
On 3/26/06, Ilmari Karonen nospam@vyznev.net wrote:
- If a sufficiently easy way to circumvent the AOL proxies was found,
would you support rangeblocking the proxies permanently (or until AOL fixes their proxies to provide XFF headers)? This would force anyone editing from AOL to bypass the proxies somehow, but would also make blocking AOL vandals much easier. And what would you consider "sufficiently easy"?
Dear newbie, We don't like your ISP. No, that's not true. We hate your ISP. What's more, you're probably a vandal. If you'd like to contribute to Wikipedia, please jump through the following hoops. Thank you!
That's one way of putting it, yes. Another way to describe the situation can be found in the first few paragraphs of http://meta.wikimedia.org/wiki/XFF_project.
Personally, I wouldn't support forcing users to install a new browser just to edit Wikipedia. But if we can tell them that "to edit Wikipedia, you must first open menu X, select entry Y and uncheck the checkbox labelled FOO", that might be acceptable.
G'day Ilmari,
Personally, I wouldn't support forcing users to install a new browser just to edit Wikipedia. But if we can tell them that "to edit Wikipedia, you must first open menu X, select entry Y and uncheck the checkbox labelled FOO", that might be acceptable.
Pish, posh. How long as AOL been open to the Internet now? Damn near ten years, I'd think.
It's time for these lame AOLers to realise that there's newer, better ISPs around, and that we won't hang around forever babying those recalcitrants who simply refuse to upgrade. Legacy ISPs have been a millstone (is that the right metaphor?) around our necks for too long ...
On 3/27/06, Mark Gallagher m.g.gallagher@student.canberra.edu.au wrote:
It's time for these lame AOLers to realise that there's newer, better ISPs around, and that we won't hang around forever babying those recalcitrants who simply refuse to upgrade. Legacy ISPs have been a millstone (is that the right metaphor?) around our necks for too long ...
I might almost support that view if most AOLers had been around for 10 years. However, they probably *do* move on and "upgrade" to a better ISP, leaving new, even lamer AOLers to take their place. And punishing *them* for it is just unfair.
Steve
G'day Steve,
On 3/27/06, Mark Gallagher m.g.gallagher@student.canberra.edu.au wrote:
It's time for these lame AOLers to realise that there's newer, better ISPs around, and that we won't hang around forever babying those recalcitrants who simply refuse to upgrade. Legacy ISPs have been a millstone (is that the right metaphor?) around our necks for too long ...
I might almost support that view if most AOLers had been around for 10 years. However, they probably *do* move on and "upgrade" to a better ISP, leaving new, even lamer AOLers to take their place. And punishing *them* for it is just unfair.
It sucks when a parody backfires :-(
On 3/27/06, Mark Gallagher m.g.gallagher@student.canberra.edu.au wrote:
It sucks when a parody backfires :-(
Sorry, we just went off daylight savings here and I'm a bit short of sleep. :/
Steve
Erm, we just went *onto* daylight savings. (Somehow my brain still thinks March is the end of summer...)
Steve
On 3/27/06, Steve Bennett stevage@gmail.com wrote:
On 3/27/06, Mark Gallagher m.g.gallagher@student.canberra.edu.au wrote:
It sucks when a parody backfires :-(
Sorry, we just went off daylight savings here and I'm a bit short of sleep. :/
Steve
Steve Bennett wrote:
Erm, we just went *onto* daylight savings. (Somehow my brain still thinks March is the end of summer...)
It is. In the UK.
Chris
Ilmari Karonen wrote:
There has been some recent discussion at [[MediaWiki talk:Blockedtext]] about providing specific instructions for AOL users who find the IP of their proxy blocked, similar to how we provide instructions for users editing from China.
There's a simple, non-invasive way to determine the IP address of an AOL client, which I've been looking into recently: use SSL sign-on. Make the login links go to https://secure.wikimedia.org, and redirect them back when they're logged in. SSL requests skip the proxy cluster. We would store the IP address at login in the session, and then continue to use that IP address for the user after they return to the unsecured part of the site. And of course there are security benefits for all users.
This would mean requiring that AOL users log in before edit. Sad, but more open than many proposed solutions.
-- Tim Starling
Tim Starling wrote:
There's a simple, non-invasive way to determine the IP address of an AOL client, which I've been looking into recently: use SSL sign-on. Make the login links go to https://secure.wikimedia.org, and redirect them back when they're logged in. SSL requests skip the proxy cluster. We would store the IP address at login in the session, and then continue to use that IP address for the user after they return to the unsecured part of the site. And of course there are security benefits for all users.
If that really works, couldn't we just make AOL users _edit_ over SSL? Have http links with action=edit (or action=submit) redirect to an https URL if fetched from an AOL proxy.
This would break talk message notification for unregistered AOL users, but I suppose we could use a cookie for that. After all, talk pages are public, so there's no security issue even if someone fakes the cookie.
Ilmari Karonen wrote:
Tim Starling wrote:
There's a simple, non-invasive way to determine the IP address of an AOL client, which I've been looking into recently: use SSL sign-on. Make the login links go to https://secure.wikimedia.org, and redirect them back when they're logged in. SSL requests skip the proxy cluster. We would store the IP address at login in the session, and then continue to use that IP address for the user after they return to the unsecured part of the site. And of course there are security benefits for all users.
If that really works, couldn't we just make AOL users _edit_ over SSL? Have http links with action=edit (or action=submit) redirect to an https URL if fetched from an AOL proxy.
This would break talk message notification for unregistered AOL users, but I suppose we could use a cookie for that. After all, talk pages are public, so there's no security issue even if someone fakes the cookie.
Now, that's an *excellent* idea.
1 the SSL overhead will be low, because edits are a tiny fraction of the overall traffic 2 If we only SSL the form submission, this limits the SSL overhead even further. 3 AOL browsing will still be proxied, so page-view load will not increase 4 AOL _browsing_ will still be completely anonymous 5 AOL IP editors will still be as anonymous as any other IP editors 6 Dynamic IP assignment should not be any more or less of a problem than with other ISPs
Are there any reasons why this should not work? Perhaps this could be the solution for all non-XFF-friendly ISPs?
-- Neil
Neil Harris wrote:
Ilmari Karonen wrote:
Tim Starling wrote:
There's a simple, non-invasive way to determine the IP address of an AOL client, which I've been looking into recently: use SSL sign-on. Make the login links go to https://secure.wikimedia.org, and redirect them back when they're logged in. SSL requests skip the proxy cluster. We would store the IP address at login in the session, and then continue to use that IP address for the user after they return to the unsecured part of the site. And of course there are security benefits for all users.
If that really works, couldn't we just make AOL users _edit_ over SSL? Have http links with action=edit (or action=submit) redirect to an https URL if fetched from an AOL proxy.
This would break talk message notification for unregistered AOL users, but I suppose we could use a cookie for that. After all, talk pages are public, so there's no security issue even if someone fakes the cookie.
Now, that's an *excellent* idea.
1 the SSL overhead will be low, because edits are a tiny fraction of the overall traffic 2 If we only SSL the form submission, this limits the SSL overhead even further. 3 AOL browsing will still be proxied, so page-view load will not increase 4 AOL _browsing_ will still be completely anonymous 5 AOL IP editors will still be as anonymous as any other IP editors 6 Dynamic IP assignment should not be any more or less of a problem than with other ISPs
Are there any reasons why this should not work? Perhaps this could be the solution for all non-XFF-friendly ISPs?
-- Neil
And, on re-reading, perhaps for AOL users only, the "my talk page" link could be an SSL link which would then auto-redirect to the appropriate IP address talk page, thus eliminating any need for a cookie.
A question: does the Foundation have a PKI certificate for the wikipedia.org domain?
-- Neil
Neil Harris wrote:
Neil Harris wrote:
Ilmari Karonen wrote:
If that really works, couldn't we just make AOL users _edit_ over SSL? Have http links with action=edit (or action=submit) redirect to an https URL if fetched from an AOL proxy.
This would break talk message notification for unregistered AOL users, but I suppose we could use a cookie for that. After all, talk pages are public, so there's no security issue even if someone fakes the cookie.
Now, that's an *excellent* idea.
1 the SSL overhead will be low, because edits are a tiny fraction of the overall traffic 2 If we only SSL the form submission, this limits the SSL overhead even further. 3 AOL browsing will still be proxied, so page-view load will not increase 4 AOL _browsing_ will still be completely anonymous 5 AOL IP editors will still be as anonymous as any other IP editors 6 Dynamic IP assignment should not be any more or less of a problem than with other ISPs
Are there any reasons why this should not work? Perhaps this could be the solution for all non-XFF-friendly ISPs?
It won't work for all of them, since some may tunnel SSL traffic through the proxy as well. There's very little we can do in that case without help from the user, and possibly not even then.
(From a technical viewpoint, the hardest situation is not a proxy, but a large number of users on RFC-1918 addresses behind a single NAT router. There's no way we can discover their internal IP address, and even if we could, it'd be all but useless to us.)
And, on re-reading, perhaps for AOL users only, the "my talk page" link could be an SSL link which would then auto-redirect to the appropriate IP address talk page, thus eliminating any need for a cookie.
Unregistered users don't _have_ a "my talk page" link, so the point is moot. They do, however, get those "You have new messages" notices, which is what I proposed the cookie for. I do agree with you that many if not most special pages, including Special:Mytalk, should also be served over SSL for those users.
Ilmari Karonen wrote:
Neil Harris wrote:
Neil Harris wrote:
Ilmari Karonen wrote:
If that really works, couldn't we just make AOL users _edit_ over SSL? Have http links with action=edit (or action=submit) redirect to an https URL if fetched from an AOL proxy.
This would break talk message notification for unregistered AOL users, but I suppose we could use a cookie for that. After all, talk pages are public, so there's no security issue even if someone fakes the cookie.
Now, that's an *excellent* idea.
1 the SSL overhead will be low, because edits are a tiny fraction of the overall traffic 2 If we only SSL the form submission, this limits the SSL overhead even further. 3 AOL browsing will still be proxied, so page-view load will not increase 4 AOL _browsing_ will still be completely anonymous 5 AOL IP editors will still be as anonymous as any other IP editors 6 Dynamic IP assignment should not be any more or less of a problem than with other ISPs
Are there any reasons why this should not work? Perhaps this could be the solution for all non-XFF-friendly ISPs?
It won't work for all of them, since some may tunnel SSL traffic through the proxy as well. There's very little we can do in that case without help from the user, and possibly not even then.
(From a technical viewpoint, the hardest situation is not a proxy, but a large number of users on RFC-1918 addresses behind a single NAT router. There's no way we can discover their internal IP address, and even if we could, it'd be all but useless to us.)
I agree: NAT, or transparent proxying without XFF is the worst case. However, I suspect that AOL users _do_ in general get assigned real routable IP addresses, it's just that their web traffic goes by default through transparent proxies.
The AOL FAQ for this (at http://webmaster.info.aol.com/proxyinfo.html) says:
"AOL members are assigned a dynamic IP address that is used for all requests not handled by the AOL proxy system. These IP addresses can be used to identify AOL members making requests to your site."
How about doing SSL via a non-standard port, which will miss the proxies _if_ the transparent proxying simply uses packet filtering at the network side to detect proxyable traffic?
For example:
https://en.wikipedia.org:32//w/index.php?title=Example article&action=submit
(32 being an officially unassigned port number)
Come to that, if they're just packet-filtering off the proxyable traffic, we may not even need to bother with the https: -- just use a non-standard port number for _all_ form submissions from AOL members, and set a cookie with that address so they can see their messages.
Of course, we can theorize forever about what AOL's network does or does not do... some actual experiments would be likely to find out what the actual state of affairs is.
Incidentally, if you go to https://en.wikipedia.org/, you get a slightly surprising result...
-- Neil
Neil Harris wrote:
How about doing SSL via a non-standard port, which will miss the proxies _if_ the transparent proxying simply uses packet filtering at the network side to detect proxyable traffic?
From reading between the lines, it seems AOL does _not_ use packet filtering; they've just configured their standard browser to use their proxies by default. This means that:
* Installing a different browser bypasses the proxies.
* HTTPS bypasses the proxies.
* Changing the browser configuration _might_ bypass the proxies (unless they've locked it down somehow; I don't really know).
* Using a nonstandard port for HTTP does _not_ bypass the proxies.
Tim Starling wrote:
There's a simple, non-invasive way to determine the IP address of an AOL client, which I've been looking into recently: use SSL sign-on. Make the login links go to https://secure.wikimedia.org, and redirect them back when they're logged in. SSL requests skip the proxy cluster. We would store the IP address at login in the session, and then continue to use that IP address for the user after they return to the unsecured part of the site. And of course there are security benefits for all users.
This would mean requiring that AOL users log in before edit. Sad, but more open than many proposed solutions.
While we're at it, why not have everyone sign in securely? If the technology is in place to allow this, we should take advantage of it.
Chris
Chris Jenkinson wrote:
Tim Starling wrote:
There's a simple, non-invasive way to determine the IP address of an AOL client, which I've been looking into recently: use SSL sign-on. Make the login links go to https://secure.wikimedia.org, and redirect them back when they're logged in. SSL requests skip the proxy cluster. We would store the IP address at login in the session, and then continue to use that IP address for the user after they return to the unsecured part of the site. And of course there are security benefits for all users.
This would mean requiring that AOL users log in before edit. Sad, but more open than many proposed solutions.
While we're at it, why not have everyone sign in securely? If the technology is in place to allow this, we should take advantage of it.
...that was the general idea. Sorry if I didn't make that clear.
-- Tim Starling
Tim Starling wrote:
Chris Jenkinson wrote:
Tim Starling wrote:
There's a simple, non-invasive way to determine the IP address of an AOL client, which I've been looking into recently: use SSL sign-on. Make the login links go to https://secure.wikimedia.org, and redirect them back when they're logged in. SSL requests skip the proxy cluster. We would store the IP address at login in the session, and then continue to use that IP address for the user after they return to the unsecured part of the site. And of course there are security benefits for all users.
This would mean requiring that AOL users log in before edit. Sad, but more open than many proposed solutions.
While we're at it, why not have everyone sign in securely? If the technology is in place to allow this, we should take advantage of it.
...that was the general idea. Sorry if I didn't make that clear.
http://bugzilla.wikimedia.org/show_bug.cgi?id=225 - secure login on wikimedia via ssl
IIRC Tim hinted in #wikimedia-tech that this /might/ also have something to do with single login...