Deathphoenix wrote:
I have some success with Lancaster University. I originally slapped one of their proxies with a 6 month AO block due to persistent, long term vandalism, but one of the sysadmins contacted me and told me they have XFF headers. After some fruitful discussion/negotiation, I removed the block and put up a header on the talk pages for their four proxies asking anyone who blocks the IP (or issues a warning) to also send an email to their abuse email, or to ask me to send and email. FYI, I have links to the four proxies at [[User talk:Deathphoenix/Lancaster]] (the IP talk page header is at [[User:Deathphoenix/Lancaster]]).
[snip]
My suggestions for the school network admins and staff would be:
- Implement XFF headers and make sure students have to log in using a
unique user ID (easiest would be based on student number) before using school computers.
On the subject of XFF ("X-Forwarded-For") headers, I'd like to note a few important technical details that one should keep in mind:
1. Having a proxy provide XFF headers isn't enough; the address of the proxy also needs to be added to the list of trusted proxies that Wikimedia servers will accept such headers from. That's because such headers would otherwise be trivially easy to fake. To get an address added to the list, you can post a request on [[meta:Talk:XFF project]] or contact a developer with shell access (such as Tim Starling, who's been doing most of the work on the XFF project) directly.
2. One of the requirements for getting a proxy added to the trusted list is that the individual computers behind it have public IP addresses of their own. If the school network is using [[private IP addresses]] internally, XFF headers won't help.
3. Once the address of a proxy has been added to the trusted XFF list, no edits should be seen from that address ever again, and blocking the address of the proxy should have no effect. That's because, as far as MediaWiki is concerned, the edits made via that proxy will no longer be seen as coming from the proxy, but from the IP address of the computer behind the proxy.
I'll repeat that, since it's important: Once a proxy is on the trusted XFF list, *any blocks on it will have no effect*.
4. If the computers behind the proxy are public workstations in, say, a school computer lab, XFF headers may not help prevent vandalism much. By making edits from different workstations be seen as coming from different IPs, they may reduce collateral damage from blocking one workstation; but if the vandals can just switch to another computer, this may end up doing more harm than good. At best, they may make tracking down the vandals easier, if the school requires users to log in to workstations and keeps logs of who used which workstation when; this may often be true at college level schools, but much less so at high schools or even elementary schools.
That last point is also important; to catch vandals, it's not enough that students log in, it's also necessary to keep a log of who used which workstation when _and_ to make said log available to whoever is tasked with handling network abuse issues. Of course, there are significant privacy issues here that need to be considered too.
So, to summarize, XFF headers are only useful for catching school vandals if the school has:
1. their proxy/ies listed in the trusted XFF list, 2. public IP addresses for each workstation, 3. workstations requiring students to log in to use them, 4. a log of who was using which workstation when, and 5. a person with access to said log who can handle complaints.
Of course, it should go without saying that the contact information for the person or department responsible for handling net abuse issues must also be easy to find, if it's to do anyone any good.
(This is all based on my understanding of the XFF implementation in MediaWiki as it was when I last looked at it. If you find any incorrect or outdated information above, please correct me. To increase the odds of this happening, I've crossposted this to wikitech-l in addition to wikien-l.)