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:
>
> 1. 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.)
--
Ilmari Karonen