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.