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