2008/6/5 Platonides <Platonides(a)gmail.com>om>: I fear that would be much-needed on en:wp. Tor edits have been less and less tolerated as we discover how much rubbish comes through them. Is there a way to allow exempt IPs to edit through Tor anyway? Oh yesss :-) - d.

You could always create a ipblockexempt flag linked to the permission and give that out when a Tor user with a valid reason shows up. ~Daniel Friesen(Dantman) of: -The Nadir-Point Group (http://nadir-point.com) --It's Wiki-Tools subgroup (http://wiki-tools.com) --Games-G.P.S. (http://ggps.org) -And Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) David Gerard wrote:

On Fri, Jun 6, 2008 at 6:51 AM, David Gerard <dgerard(a)gmail.com> wrote: See http://en.wikipedia.org/wiki/Special:ListGroupRights You'll notice an extra permission under User, called torblock-unblocked, or something. All that would need to be done is for that to be reassigned to a user group given out. However, I don't like the idea of hard-blocking tor, even when we do give out flags to people who need to use it. I maintain that we are best to come up with some other form of novel handling that balances the need to prevent vandalism with other needs. I think that, for users who don't have a certain permission, marking tor edits as such in recentchanges would be an excellent step in that direction. -- Andrew Garrett

2008/6/5 Andrew Garrett <andrew(a)epstone.net>et>: Not many people do like the idea of blocking it. The hard-blocking on en:wp is because people like the realities of not blocking it even less. - d.

On Fri, Jun 6, 2008 at 7:16 AM, jayjg <jayjg99(a)gmail.com> wrote: Can't speak for the other person, but assuming good faith, not biting newcomers, and the recognition that many legitimate reasons exist for using tor under repressive governments as the reasons for not liking hard blocks. As for other needs, id say, you know, being Wikipedia, the free encyclopedia that *anyone* can edit is a pretty important need. The more we close off the club, the more we stagnate. -- -Brock

On Fri, Jun 6, 2008 at 4:47 PM, Brock Weller <brock.weller(a)gmail.com> wrote: I appreciate why someone in China would want to use tor. Would any of that apply to someone in a Western democracy?

On Fri, Jun 6, 2008 at 6:01 PM, Chad <innocentkiller(a)gmail.com> wrote: Browsing via TOR is not blocked.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simetrical wrote: I think it's also because there have been vandal related issues. - --CWii

jayjg schrieb: Living in a Western democracy doesn't necessarily mean that you can surf the web or use internet services freely, look at all those blocks for Bittorrent, the dozens of blocks for Nazi hosters, and especially the German court decision about YouPorn, which actually led to >2 million websites being invisible by Arcor customers; they can only be helped through proxys (though I don't think watching porn via proxys is good). And please also do not forget that some people indeed care about their privacy - what many people unfortunately do not, and so freedom passes more and more away. Marco

Hoi, We are discussing a tool that is to be implemented WMF wide. There are projects that are utterly different, there are languages spoken in countries where the sheer audacity of printing the historic election communiques of the ruling government can get you killed. They are largely the less and least resourced languages and consequently these projects are comparatively tiny. There are people I am aware off who want to contribute to Wikinews but it is EXACTLY their need to be outside of their country and to be anonymous that may give them the courage to start doing a journalistic job.. We all now how great our community is at keeping secrets, there are people who insist that everything should be available to them. I am fearful that removing the option for these people to use TOR will kill off what is essential to our goal; bring information to our public.. Even our public figures, people living in the "free world" are harassed, stalked, threatened...Rape, murder, the use of sulphuric acid they are the kind of threats that are issued. This is in my opinion the greatest threat that we face. This threatens our NPOV. For some people safety exists in anonymity but there are people who are loose lipped, who think that the issue is not that dire and who as a consequence will carelessly endanger their fellow wikimedians. There is a balance between on the one hand the vandals, the sock puppeteers, the insane and on the other hand the people who need the anonymity that TOR can offer. At this moment I am afraid that only one side of the picture has been considered. Thanks, GerardM On Sun, Jun 8, 2008 at 7:58 PM, jayjg <jayjg99(a)gmail.com> wrote:

2008/6/8 Gerard Meijssen <gerard.meijssen(a)gmail.com>om>: So leave it entirely off unless and until it's asked for and there's a clear and checkable consensus, one wiki at a time. Not blithely switched on by default. - d.

On Mon, Jun 9, 2008 at 6:08 AM, David Gerard <dgerard(a)gmail.com> wrote: Certainly, I see quite significant benefit in tor - more than most do. However, I strongly object to your insinuation that my extension was not written with the best interests of the Wikimedia projects at heart. The extension was not written for the tor people (although they were quite happy when I spoke to them of my plans - as I needed their technical co-operation to produce the list in software), and I reject any insinuation that I am somehow writing code to benefit tor, rather than the foundation. I saw a problem - in this case, the fact that tor is now blocked using a hodgepodge of blocks by various bots, scripts, and people, many of which are no longer tor nodes, and many tor nodes are not blocked. It is suboptimal that tor nodes are hard-blocked, and it was my impression (perhaps mistaken?) that the general consensus is that while we are loathe to hard-block tor, we are forced to do it by the amount of nonsense that comes through it. I recognised that a solution was possible - in-software handling of tor exit nodes. I realised that I could kill two birds with one stone here - both standardise the treatment of Tor by Wikimedia wikis, AND remove the hard-blocks on Wikimedia wikis by instituting some kind of special treatment of tor, which balances the needs of individuals who require privacy, and Wikipedia as a whole, which needs to have this sort of nonsense removed. I must note that those checkusers who indicated that most of what comes through tor is nonsense have the sample they're working with skewed - they will only ever see the bad tor nodes, because (I hope) they don't go running checkusers on random users to see if they're using tor. I would imagine that we get quite a considerable amount of good editing from tor, which goes unnoticed because we have some semblance of a privacy policy. Evidently, this is a situation requiring compromise, and I would like to see some suggested compromises from those who still maintain that hard-blocks are the only option. Remember that this is being implemented in software (something FT2 indicated that he had not realised), and therefore the sky's the limit. ANY special technical handling of tor nodes is possible. Here are a few ideas to get started: * A special page listing all recent tor users/contributions/edits. * Special marking in recentchanges, checkuser, contribs, diff pages. * Allow disabling tor per-page or per-user. * Allow temporary disabling of tor site-wide with good cause (through a special page). * Require a user to be autoconfirmed before using tor (causes a catch-22 situation, though). As I've stated before, ipblock-exempt or a similar process will be ineffective unless torblock-unblocked is granted liberally, as a catch-22 situation is produced. -- Andrew Garrett

I had a discussion with FT2 on IRC a few hours ago. He said that he would be happy to have a soft-block, with these provisions: 1. A special page exists which allows the monitoring of recent tor edits. Perhaps Special:Recentchanges/tor? 2. A new protection level is added, which allows tor users to be prevented from editing an article, which, for instance, has concerns with regard to sockpuppeting and so on. What do others think of these? -- Andrew Garrett

Andrew Garrett wrote: With the extended Tor autoconfirm requirements, the second doesn't really seem necessary, semi-protection should work. If there are still problems with Tor abuse on semi-protected articles, the Tor autoconfirm restrictions can be raised without having to worry about significant impact to most users. As for the first, would users who meet the extended autoconfirm requirements or have ipblockexempt still be listed? -- Alex (w:en:User:Mr.Z-man)

On Sat, Jun 7, 2008 at 4:28 AM, Andrew Garrett <andrew(a)epstone.net> wrote: Actually, FT2 has said that he did not, in fact, say this, and apologizes if that was the impression you were left with. As for me, I don't see any reason why TOR proxies should be afforded any special consideration; like all proxies, they should be hard banned, per policy, and developers shouldn't implement ways of over-turning the actions of wikis that quite properly do so. On the contrary, they should be implementing extensions that automatically block TOR exit nodes. And I don't see any particular reason why we should be adding layer upon layer of complexity to this scheme whose underlying premise is fatally flawed. I'm not sure why the IP block exemption wouldn't work for the incredibly small number of wiki-en editors who actually have a *legitimate* reasons to use TOR.

On Sun, Jun 8, 2008 at 2:16 PM, David Gerard <dgerard(a)gmail.com> wrote: I would imagine that detecting Tor is easier than detecting anonymous proxies in general, although I haven't looked at the extension.

On Sun, Jun 8, 2008 at 4:26 PM, Platonides <Platonides(a)gmail.com> wrote: You just do a portscan. It's fairly straightforward. (Also not *totally* reliable, but what is in life?) Wikimedia could then maintain its own DNSBL, if it were feeling nice. Each view would trigger a portscan on that IP, although no more than once every X days. Any hit would be added to a table of proxies that would be checked on edits, etc. This would happen asynchronously, because portscans take time. That's not really a problem effectiveness-wise; even on a fresh hit, at most one quick edit should be able to get through before the IP gets blocked. This would all require a substantial amount of server setup, and would be considerably more complicated than just writing an extension. Probably the web servers are firewalled such that they can't portscan, and even if not, people's firewalls would freak out and block them. (Although that might not matter, since the actual traffic goes through the Squids. Doesn't really matter if the Apaches get blocked.) Of course, you could also use an existing DNSBL, but those aren't necessarily reliable. An in-house solution might be a better idea here. Which says to me that vandalism handling needs to be made easier.

On Sun, Jun 8, 2008 at 7:35 PM, Andrew Garrett <andrew(a)epstone.net> wrote: ISPs don't care if you portscan as long as it's for legitimate purposes. IRC networks, for instance, do it routinely. I doubt you're going to have to portscan anywhere near 20% of the Internet, even allowing for some hyperbole, given that scanning is only needed on edit, and can be cached for a quite long time (say, a month) for confirmed non-proxies. You could also manually skip ranges that are known to be dynamic, which would kill a ton more of the load, in fact quite possibly almost all of it.