As some of you may have noted, we now have a couple of new options to choose when blocking users. Tim Starling, who implemented the feature, posted the following clarification on the wikitech-l list:
Tim Starling wrote:
A couple of people asked me about interaction between various kinds of blocks and block options, and indeed, in some cases the behaviour was undefined or accidental. I've now implemented the following rules:
- The "anon only" and "prevent account creation" options will be silently
ignored on username blocks.
- The precedence of blocks in cases of conflict, from highest to lowest, is:
- Username block
- Single IP block
- Range block
- Autoblock
This holds regardless of the anon-only option. This means that anon-only range blocks or IP blocks can be used to mitigate the effects of autoblocks on shared IP addresses, because an anon-only block will allow logged in users to edit regardless of the presence of a matching autoblock. This has a potential to be counterintuitive -- unblocking someone's IP can in fact cause them to be blocked. But I thought it was better than the other solutions.
Given the above, would it now be advisable to block the entire AOL proxy pool from editing by unregistered users? This would have the side effect that AOL users would no longer be hit by random autoblocks.
(If you're unfamiliar with the AOL proxies and why they're a problem for us, please see [[Wikipedia:Advice to AOL users]] and [[Wikipedia:Dealing with AOL vandals]], plus the associated talk pages.)
On 7/11/06, Ilmari Karonen nospam@vyznev.net wrote:
As some of you may have noted, we now have a couple of new options to choose when blocking users. Tim Starling, who implemented the feature, posted the following clarification on the wikitech-l list:
Tim Starling wrote:
<snip> > > This holds regardless of the anon-only option. This means that anon-only > range blocks or IP blocks can be used to mitigate the effects of autoblocks > on shared IP addresses, because an anon-only block will allow logged in > users to edit regardless of the presence of a matching autoblock. This has a > potential to be counterintuitive -- unblocking someone's IP can in fact > cause them to be blocked. But I thought it was better than the other solutions.
Given the above, would it now be advisable to block the entire AOL proxy pool from editing by unregistered users? This would have the side effect that AOL users would no longer be hit by random autoblocks.
My initial opinion on this would be to do so. It would be great if we could replace the entire advice section of [[Wikipedia:Advice to AOL users]] with "Register an account" and no longer have to deal with the headaches of AOL vandalism affecting valid users.
On 7/12/06, Ilmari Karonen nospam@vyznev.net wrote:
Given the above, would it now be advisable to block the entire AOL proxy pool from editing by unregistered users? This would have the side effect that AOL users would no longer be hit by random autoblocks.
AOL have agreed to set XFF headers for Wikimedia sites, so this won't be necessary. However, that was a few weeks ago now and I'm not aware of it having been implemented yet. I'll follow up and see if there's any response. I suggest holding off on the blocks for a while longer to see whether we can avoid this.
Angela.
Angela wrote:
On 7/12/06, Ilmari Karonen nospam@vyznev.net wrote:
Given the above, would it now be advisable to block the entire AOL proxy pool from editing by unregistered users? This would have the side effect that AOL users would no longer be hit by random autoblocks.
AOL have agreed to set XFF headers for Wikimedia sites, so this won't be necessary. However, that was a few weeks ago now and I'm not aware of it having been implemented yet. I'll follow up and see if there's any response. I suggest holding off on the blocks for a while longer to see whether we can avoid this.
That's *great* news! I suppose Tim is also in on this, given that he maintains the trusted XFF list?
That said, it might still make sense to block anon editing from the proxies until this is implemented, assuming we feel the blocking is a good idea at all. Once the XFF feature has been enabled on both ends, those blocks will then (as far as I understand the system) simply stop having any effect.
As an implementation detail, if we do this, we should probably set up a helpful template and use it in the range block summaries. That way the users affected by the blocks will know exactly what's going on and what to do.
Regardless of the fate of AOL users. It is great for Tor users who are already blanket blocked due to abuse of the proxies.
On 11/07/06, Ilmari Karonen nospam@vyznev.net wrote:
Angela wrote:
On 7/12/06, Ilmari Karonen nospam@vyznev.net wrote:
Given the above, would it now be advisable to block the entire AOL proxy pool from editing by unregistered users? This would have the side effect that AOL users would no longer be hit by random autoblocks.
AOL have agreed to set XFF headers for Wikimedia sites, so this won't be necessary. However, that was a few weeks ago now and I'm not aware of it having been implemented yet. I'll follow up and see if there's any response. I suggest holding off on the blocks for a while longer to see whether we can avoid this.
That's *great* news! I suppose Tim is also in on this, given that he maintains the trusted XFF list?
That said, it might still make sense to block anon editing from the proxies until this is implemented, assuming we feel the blocking is a good idea at all. Once the XFF feature has been enabled on both ends, those blocks will then (as far as I understand the system) simply stop having any effect.
As an implementation detail, if we do this, we should probably set up a helpful template and use it in the range block summaries. That way the users affected by the blocks will know exactly what's going on and what to do.
-- Ilmari Karonen _______________________________________________ WikiEN-l mailing list WikiEN-l@Wikipedia.org To unsubscribe from this mailing list, visit: http://mail.wikipedia.org/mailman/listinfo/wikien-l
Angela wrote:
On 7/12/06, Ilmari Karonen nospam@vyznev.net wrote:
Given the above, would it now be advisable to block the entire AOL proxy pool from editing by unregistered users? This would have the side effect that AOL users would no longer be hit by random autoblocks.
AOL have agreed to set XFF headers for Wikimedia sites, so this won't be necessary. However, that was a few weeks ago now and I'm not aware of it having been implemented yet. I'll follow up and see if there's any response. I suggest holding off on the blocks for a while longer to see whether we can avoid this.
Angela.
That's fantastic news! AOL supporting XFF should remove the need for a _lot_ of blocking.
-- Neil
I've just had confirmation that this should be working. From AOL this morning:
I have just now added all the domains you have listed below to our config to get XFF headers. You should see them sometime later today when the process is finished updating all of our web proxies.
Thanks to Jim Sheafer for setting this up, and to Mike Wise for putting me in contact with him.
Hopefully this means you can now block one AOL user without affecting another one. http://en.wikipedia.org/wiki/Wikipedia:Advice_to_AOL_users should probably be updated when we're sure this is working.
Angela.
If this works, this is literally a new era of wikipedia vandal-fighting.
On 7/11/06, Angela beesley@gmail.com wrote:
I've just had confirmation that this should be working. From AOL this morning:
I have just now added all the domains you have listed below to our config to get XFF headers. You should see them sometime later today when the process is finished updating all of our web proxies.
Thanks to Jim Sheafer for setting this up, and to Mike Wise for putting me in contact with him.
Hopefully this means you can now block one AOL user without affecting another one. http://en.wikipedia.org/wiki/Wikipedia:Advice_to_AOL_users should probably be updated when we're sure this is working.
Angela. _______________________________________________ WikiEN-l mailing list WikiEN-l@Wikipedia.org To unsubscribe from this mailing list, visit: http://mail.wikipedia.org/mailman/listinfo/wikien-l
Fantastic.
- nathanrdotcom
On Wed, 12 Jul 2006, Angela wrote:
I've just had confirmation that this should be working. From AOL this morning:
I have just now added all the domains you have listed below to our config to get XFF headers. You should see them sometime later today when the process is finished updating all of our web proxies.
Thanks to Jim Sheafer for setting this up, and to Mike Wise for putting me in contact with him.
Hopefully this means you can now block one AOL user without affecting another one. http://en.wikipedia.org/wiki/Wikipedia:Advice_to_AOL_users should probably be updated when we're sure this is working.
Angela.
This tool will certainly help a lot, but we mustn't get carried away with its power by blocking whole swathes of the Internet. Anons are valuable, and their editing Wikipedia is a fundamental principle of ours. Anons should be afforded as many rights as are possible without exposing ourselves to too much vandalism.
On 12/07/06, Nathan lists@home.nathanr.com wrote:
Fantastic.
- nathanrdotcom
On Wed, 12 Jul 2006, Angela wrote:
I've just had confirmation that this should be working. From AOL this morning:
I have just now added all the domains you have listed below to our config to get XFF headers. You should see them sometime later today when the process is finished updating all of our web proxies.
Thanks to Jim Sheafer for setting this up, and to Mike Wise for putting me in contact with him.
Hopefully this means you can now block one AOL user without affecting another one. http://en.wikipedia.org/wiki/Wikipedia:Advice_to_AOL_users should probably be updated when we're sure this is working.
Angela.
WikiEN-l mailing list WikiEN-l@Wikipedia.org To unsubscribe from this mailing list, visit: http://mail.wikipedia.org/mailman/listinfo/wikien-l
Angela wrote:
I've just had confirmation that this should be working. From AOL this morning:
I have just now added all the domains you have listed below to our config to get XFF headers. You should see them sometime later today when the process is finished updating all of our web proxies.
We still seem to be getting edits from some AOL proxies, at least in the 195.93.21.*, 152.163.100.* and 207.200.116.* ranges. Maybe some of the proxies are still not providing the headers, or perhaps they're missing from our trusted XFF list?
Given that the XFF setup doesn't seem to work perfectly, the question remains whether we should apply anon-only range blocks to those proxies.
On 7/27/06, Ilmari Karonen nospam@vyznev.net wrote:
Angela wrote:
I've just had confirmation that this should be working. From AOL this
morning:
I have just now added all the domains you have listed below to our config to get XFF headers. You should see them sometime later today when the process is finished updating all of our web proxies.
We still seem to be getting edits from some AOL proxies, at least in the 195.93.21.*, 152.163.100.* and 207.200.116.* ranges. Maybe some of the proxies are still not providing the headers, or perhaps they're missing from our trusted XFF list?
Given that the XFF setup doesn't seem to work perfectly, the question remains whether we should apply anon-only range blocks to those proxies.
If you look at my history of me and AOL users...I think AOL is a shithole that should be banned from accessing any website.
However, it's much easier to ban an IP address for vandalism than a username. People get bitchy. No one cares about blocking IP users, and I want to keep it that way for ease of blocking.
mboverload wrote:
On 7/27/06, Ilmari Karonen nospam@vyznev.net wrote:
We still seem to be getting edits from some AOL proxies, at least in the 195.93.21.*, 152.163.100.* and 207.200.116.* ranges. Maybe some of the proxies are still not providing the headers, or perhaps they're missing from our trusted XFF list?
Given that the XFF setup doesn't seem to work perfectly, the question remains whether we should apply anon-only range blocks to those proxies.
If you look at my history of me and AOL users...I think AOL is a shithole that should be banned from accessing any website.
However, it's much easier to ban an IP address for vandalism than a username. People get bitchy. No one cares about blocking IP users, and I want to keep it that way for ease of blocking.
...
Except this is AOL: for all practical purposes, AOL proxy IPs *can't* be effectively blocked, not unless you block the entire range. And if you don't make the block anon-only, you get heavy collateral damage, which *does* cause serious bitching; we've just gotten so used to it we don't really notice the constant complaints any more.
To repeat my argument earlier in this thread, an anon-only range block of the AOL proxies would actually reduce the annoyance, since it would override autoblocks, allowing registered users to edit without being hit by them. And, of course, once the XFF setup starts working fully, the range blocks will cease to have any effect.
Oh, I was under the impression that they just enabled XFF (which I don't understand) and that was that.
On 7/28/06, Ilmari Karonen nospam@vyznev.net wrote:
mboverload wrote:
On 7/27/06, Ilmari Karonen nospam@vyznev.net wrote:
We still seem to be getting edits from some AOL proxies, at least in the 195.93.21.*, 152.163.100.* and 207.200.116.* ranges. Maybe some of the proxies are still not providing the headers, or perhaps they're missing from our trusted XFF list?
Given that the XFF setup doesn't seem to work perfectly, the question remains whether we should apply anon-only range blocks to those proxies.
If you look at my history of me and AOL users...I think AOL is a
shithole
that should be banned from accessing any website.
However, it's much easier to ban an IP address for vandalism than a username. People get bitchy. No one cares about blocking IP users, and
I
want to keep it that way for ease of blocking.
...
Except this is AOL: for all practical purposes, AOL proxy IPs *can't* be effectively blocked, not unless you block the entire range. And if you don't make the block anon-only, you get heavy collateral damage, which *does* cause serious bitching; we've just gotten so used to it we don't really notice the constant complaints any more.
To repeat my argument earlier in this thread, an anon-only range block of the AOL proxies would actually reduce the annoyance, since it would override autoblocks, allowing registered users to edit without being hit by them. And, of course, once the XFF setup starts working fully, the range blocks will cease to have any effect.
-- Ilmari Karonen _______________________________________________ WikiEN-l mailing list WikiEN-l@Wikipedia.org To unsubscribe from this mailing list, visit: http://mail.wikipedia.org/mailman/listinfo/wikien-l
On 11/07/06, Ilmari Karonen nospam@vyznev.net wrote:
As some of you may have noted, we now have a couple of new options to choose when blocking users. Tim Starling, who implemented the feature, posted the following clarification on the wikitech-l list:
Tim Starling wrote:
A couple of people asked me about interaction between various kinds of blocks and block options, and indeed, in some cases the behaviour was undefined or accidental. I've now implemented the following rules:
- The "anon only" and "prevent account creation" options will be silently
ignored on username blocks.
- The precedence of blocks in cases of conflict, from highest to lowest, is:
- Username block
- Single IP block
- Range block
- Autoblock
This holds regardless of the anon-only option. This means that anon-only range blocks or IP blocks can be used to mitigate the effects of autoblocks on shared IP addresses, because an anon-only block will allow logged in users to edit regardless of the presence of a matching autoblock. This has a potential to be counterintuitive -- unblocking someone's IP can in fact cause them to be blocked. But I thought it was better than the other solutions.
Given the above, would it now be advisable to block the entire AOL proxy pool from editing by unregistered users? This would have the side effect that AOL users would no longer be hit by random autoblocks.
It would also mean they wouldn't be continually bombarded by warning messages... which is a great worry for a lot of them, judging by the emails we get.