Fair, I had thought that the decision to make the block had primarily been made by us in the technical community as I imagine the average editor knows little to nothing about Tor or other anonymising services. I'll bring up the topic in another venue. Thank you for that list Sumana. I'll give it a look over and might continue to use this thread for anything that comes up from that that does seem appropriate for this list. Based on the number of times this has come up, it does at least appear there is at least some merit to discussing it, or aspects of it, on this list. Thank you, Derric Atzrott

Alright, this is a long email, and it acts to basically summarise all of the discussions that have already happened on this topic. I'll be posting a copy of it to Mediawiki.org as well so that it will be easier to find out about what has already been proposed in the future. There is a policy side to this, Meta has the "No open proxies" policy, which would need to be changed, but I doubt that such policies will be changed unless those of us on this list can come up with a good way to allow Tor users to edit. If we can come up with a way that solves most of the problems the community has, then I think there is a good chance that this policy can be changed. Table Of Contents ================================================================================ 1. Relavent Quotes 2. Ideas 2.1. Nymble 2.2. Blind Signing 2.3. FlaggedRevs 2.4. Tor Exemption Userright 2.5. Policy Changes 2.6. OAuth 2.7. Donate for Access 2.8. Account creation off Tor 2.9. Fingerprinting 2.10. Tor Hidden Service 3. A Note on Current Policy 4. References ================================================================================ Relavent Quotes -------------------------------------------------------------------------------- "Not every Tor user is vandal or troll, and assuming that all of them are by default is not assuming good faith. Some people are just really paranoid about their internet anonymity or live in restrictive countries (both of which I sympathize with), so this idea would let them edit in good faith while filtering out vandal/troll edits." -- Arcane 21 "Well the issue is not whether we want Tor users editing or not. We do. The issue is finding a software solution that makes it possible." -- Tyler Romeo (Though Risker disagrees with the quote above, I get the feeling Tyler encapsulates the overall consensus, based on the discussions I've read.) "Many people believe that Wikipedia has become so socially important that being able to edit it even if just to leave talk page comments is an essential part of participating in worldwide society. Unfortunately, not all people are equally free and some can only access Wikipedia via anti-censorship technology or can only speak without fear of retaliation via anonymity technology." -- Gregory Maxwell "'Preventing' abuse is the wrong goal. There is plenty of abuse even with all the privacy smashing new editor deterring convolutions that we can think up. Abuse is part of the cost of doing business of operating a publicly editable Wiki ... The goal needs to merely be to limit the abuse enough so as not to upset the abuse vs benefit equation. Today, people abuse, they get blocked, they go to another library/coffee shop/find another proxy/wash rinse repeat. We can't do any better than that model, and it turns out that it's okay" -- Gregory Maxwell "My personal view is that we should transition away from tools relying on IP disclosure, given the global state of Internet surveillance and censorship which makes tools like Tor necessary." -- Erik Moller "The vast majority of socks are blocked without checkuser evidence, and always have been, on all projects; the evidence is often in the edits, and doesn't need any privacy-invading tools to confirm." -- Risker Ideas: -------------------------------------------------------------------------------- ==Nymble== http://cgi.soic.indiana.edu/~kapadia/nymble/overview.php Users get a psuedonym from a Psuedonym Manager which maps a psuedonym to an IP address for a defined duration (linkability window, default 24 hours). This must be done from a unanonymised connection. All steps after this can be done anonymised. The user passes that psuedonym to a Nymble Manager to get a Nymble ticket which is good for a defined duration (time period, default 5 minutes). This ticket is passed to the service anytime an action is performed. If a Nymble user acts up, the service can contact the Nymble Manager and get a Linkability Token which allows the service to link all Nymble tickets that a psuedonym used and uses during a single linkability window. The Psuedonym Manager, the Nymble Manager, and the Service would have to cooperate to deanonymise a users actions. Assuming that they do not, and that all three maintain minimal logs, this should protect the users privacy while still allowing them to perform actions and be blocked for misbehaving. It additionally appears that with its default settings, the Nymble Manager rate limits the user to a single action per time period. This means that they should in theory only be able to make a single Wikipedia edit every five minutes, which while not great, is a definite improvement. There is a negative in that misbehaving users could only be blocked for a single linkability window (so one day) using this scheme. Still blocking was never meant to be punitive, so perhaps that might be acceptable. I don't know, and it really isn't a discussion for this list. Wikimedia would likely have to run our own servers for this too, which could have some implications for user privacy. Its also possible for us to use something other than IP addresses for the non-anonymous item that the Psuedonym Manager collects. ==Blind Signing== For this we'd have non-anonymised users submit a token to Wikimedia which would be blind signed. They would then represent this token when editing through Tor. You would only be allowed to request a token every say week, which would allow for blocks up to that amount of time by blocking the token. Apparently Tyler Romeo actually has this solution pretty much completely ready to go, or did as of the end of 2013. See Extension:TokenAuth. There do appear to be some concerns about figuring out how to hand out tokens to folks. It seems that its basically the same sorts of problems that we face with IPBEs or Tor Exemptions (see below) though. ==FlaggedRevs== As I brought up in my first email, we could just put all Tor edits into a queue to be reviewed by non-Tor users. This idea has been brought up plenty of time and I believe that the biggest problem with it is that such a queue would put a lot of strain on already strained editors. This seems like the easiest solution to implement. I suspect that the review queues will be a lot smaller than people expect too. We have fancy things like AbuseFilter and CluebotNG now that can filter out the vast majority of the junk. ==Tor Exemption Userright== Make Tor Exemption a different userright than IP Block Exemption. The biggest reason that IPBEs are not given out is that it allows people to bypass a block if they are blocked for socking. This would reduce the risk of that somewhat significantly. If we created a Tor Exemption right that people could ask for, I imagine it would see a lot more use than the IPBE right does. It still doesn't fix the problem that Tor users would have to register their account from a non-Tor connection and also ask for the exemption from a non-Tor connection. Still, its an improvement. Apparently this is trivially easy to do as well. It seems the rights are already seperate, we just have them in the same usergroup. ==Policy Changes== IPBEs could just be given out more liberally than they currently are. This though is a policy change, and not really a great fit for this list. Nevertheless this is a viable option. ==OAuth== Chris Steipp describes this one better than I could summarise it. "I was talking with Tom Lowenthal, who is a tor developer. He was trying to convince Tilman and I that IP's were just a form of collateral that we implicitly hold for anonymous editors. If they edit badly, we take away the right of that IP to edit, so they have to expend some effort to get a new one. Tor makes that impossible for us, so one of his ideas is that we shift to some other form of collateral-- an email address, mobile phone number, etc. Tilman wasn't convinced, but I think I'm mostly there. We probably don't want to do that work in MediaWiki, but with OAuth, anyone can write an editing proxy that allows connections from Tor, ideally negotiates some kind of collateral (proof of work, bitcoin, whatever), and edits on behalf of the tor user. Individuals can still be held accountable (either blocked on wiki, or you can block them in your app), or if your app lets too many vandals in, we'll revoke your entire OAuth consumer key." It was suggested that email addresses would be a good form of collateral as they take pretty much the same amount of effort to change as an IP address does. Possibly blocking email addresses from "throw-away" providers like Guerrilla Mail that require no effort to get an address. Whatever the collateral that is used is, it would have to be verified in some fashion, so we send them an email or call their mobile or something. ==Donations for Access== Create a new special page that accepts an unblocked username and a random number signed by a Wikimedia controlled key. If the signature passes and the number entered has not ever been used before, the account gets a Tor block exemption or an IPBE. The donation page is then changed such that for every $10 donation the user's browser is allowed to submit a single randomly generated value to be blind signed by Wikimedia's servers. These signed tokens can then be used to allow folks to access Tor. There would be no restriction on what the user could do with them (perhaps they could donate them to the Tor project to give out). In the case of any abuse, the token would be blocked, which would remove the exemption from the account it was given to. If they really wanted to, they could donate another $10 to get another, but chances are most attackers aren't made of money. This idea does have some problems though in that those who use Tor may not be able to or may not want to pay to be unblocked, and in general the scheme seems somewhat unfair. Marc A. Pelletier described this idea as a "pay to get an untracable sockpuppet system". This solution may present some legal issues for the fundraising team as well. Still the idea has some merits and certainly might inspire some better ideas. ==Account creation off Tor== Easy to implement, we could just allow all registered accounts to edit via Tor and make sure that registration is disabled when using Tor. This means that we can still block problematic users and that CheckUsers will at least still have one useful data point to go off of when deciding to do IP Blocks. This solution is by no means perfect as it still exposes data that Tor users consider sensative, and additionally its not hard to just make an account somewhere that you don't care if it is blocked. Its entirely possible that this solution will just lead to more abuse as Tor users seem like the type of people who would tend to want to avoid revealing their IP address at all, even if only for registration. If the WMF were ever served with a court order from say the Chinese or Iranian government, that single IP address could have drastic consequences still. ==Allow Tor Users to only access Talk Pages== Allowing Tor users to only edit talk pages would limit any potential damage that they could do to an area that is out of the public eye. This would still allow them to make suggestions to articles though. Essentially we would treat every page as a protected page when dealing with Tor users. ==Fingerprinting== Come up with some way to finger print various Tor users and block them based off of those finger prints when they appear. This seems like it would be hard to do as the Tor Browser Bundle is designed specifically to make this hard. There are other human elements though that can be fingerprinted. I once knew a man who set up the login for his website to monitor how he typed and how long it took him to fill out the login form. If it didn't approximately match his usual timings it required him to visit a link sent to his email in order to login. Similar fingerprinting could likely be done. ==Tor Hidden Service== We could create a Tor hidden service that allows people to view and edit Wikipedia and disable edit access to it if a large scale attack happens. This solution doesn't really fix the problem of abuse really, but it might not be a bad idea to set up a read-only Wikipedia mirror as a hidden service. :) A Note on Current Policy -------------------------------------------------------------------------------- We do currently have a process in place for Tor users to request account and then to request IPBE for those accounts. In the beginning of 2014 Erik Moller tested this process (http://www.gossamer-threads.com/lists/wiki/wikitech/425124) and found that it wasn't adequate. He was able to get the account created, but he was not able to get the IPBE. When emailing in he gave the following reasoning: "My reason for editing through Tor is that I would like to write about sensitive issues (e.g. government surveillance practices) and prefer not to be identified when doing so. I have some prior editing experience, but would rather not disclose further information about it to avoid any correlation of identities." Nathan Awrich also attempted to get an IPBE, this time for his account so that he could edit while using an anonymising proxy. This is actually something I myself have attempted to do as well. He was denied initially because he could simply turn it off. An admin who knew him did eventually step in and give him the IPBE, but that is not going to be the case with the vast majority of users. I don't think that our current policy of allowing folks to email in is really the way to go. Nor do I think that unilaterally blocking Tor solves anyone's problems. So clearly something needs to be done. References -------------------------------------------------------------------------------- "Can we help Tor users make legitimate edits?" 2012. http://www.gossamer-threads.com/lists/wiki/wikitech/323006 "Jake requests enabling access and edit access to Wikipedia via TOR" 2013. http://www.gossamer-threads.com/lists/wiki/wikitech/420039 "Tor exemption process" January 2014. http://www.gossamer-threads.com/lists/wiki/wikitech/425124 "Anonymous editors & IP addresses" July 2014. http://www.gossamer-threads.com/lists/wiki/wikitech/482562 "No Open Proxies" https://meta.wikimedia.org/wiki/No_open_proxies "Editing with Tor" https://meta.wikimedia.org/wiki/Editing_with_Tor "Bug 59146 - Enabling also edit access to Wikipedia via TOR" December 2013. https://bugzilla.wikimedia.org/show_bug.cgi?id=59146

Might you have been talking about Bug #30716? [1] It happened in September of 2011. In May of 2012 the bug was re-opened and it hasn't yet been closed. Thank you, Derric Atzrott

On 9/30/14, Derric Atzrott &lt;datzrott(a)alizeepathology.com&gt; wrote: I'd like to add an idea I've been thinking about to make TOR more acceptable. A big part of the problem is that there are hundreds (thousands?) of exit nodes, so if someone is being bad, they just have to wait 5 minutes to get a new one, making it very hard to block them. So what we could do, is map all tor connections to appear (To MW) as if they are coming from a few private IP addresses. This way its easy to block temporarily (in case of a whole slew of vandalism comes in), the political decision on whether to block or not becomes a local problem (The best kind of solution to a problem is the type that makes it somebody else's problem ;) I would personally hope that admins would only give short term block to such an address during waves of vandalism, but ultimately it would be up to them. To be explicit, the potential idea is as follows: *User access via tor *MediaWiki sees its a tor request *Try to do limited browser fingerprinting, to perhaps mitigate the affect of an unclued user not using tor browser being bad ruining it for everyone. Say take a hash of the user-agent and various accept headers, and turn it into a number between 1 and 16. *Make MW think the IP is 172.16.0.<number from previous step> Then all the tor edits are all together, and easy to notice if somebody is abusing them, and easy for a local admin to block all at once if need be. This would also make most of the rate limiting apply against all people accessing via tor instead of doing rate limiting per exit node, which is probably a good thing, and would prevent repetitive abuse, people registering 10 billion accounts, etc. If we did this, we may also want to make pretty much every action trigger a captcha for those addresses (perhaps even if you are logged in from those addresses), instead of the current lax captcha triggering (On the bright side, our captchas are actually readable by people, unlike say cloudflare's (recaptcha) which I can't make heads or tails of). If there are further concerns about potential abuse, we could tag all edits coming from TOR (including if user is logged in) with an edit tag of "tor" (Although that might be in violation of privacy policy by exposing how a logged in user is accessing the site). Thoughts? Would this actually make TOR be acceptable to the Wikipedians? --bawolff

I still believe that Nymble is the way to go here. It is the only solution that successfully allows negotiation of a secure collateral that can still be blacklisted after abuse has occurred. Although, as mentioned, it is all about the collateral. Making the user provide something that requires work to obtain. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science On Tue, Sep 30, 2014 at 3:40 PM, Risker &lt;risker.wp(a)gmail.com&gt; wrote:

On 30 September 2014 15:46, Derric Atzrott &lt;datzrott(a)alizeepathology.com&gt; wrote: I suspect it's the most well known anonymizer amongst a limited group of technically knowledgeable people. There is an absolute proliferation of anonymizing services out there today, many with millions of users, and stunningly inexpensive ones are regularly advertised in mainstream media. I don't have the imagination to try to come up with an overall solution, although I agree that IP/IP range-specific blocking is becoming increasingly problematic as these systems proliferate. IPv6 notwithstanding, we're shutting off an ever-increasing percentage of internet users from participating because of the behaviour of a comparatively few commercially- or philosophically-driven problem editors. Unfortunately, with our limited human resources (what with everyone being volunteers, and most editors just editing), it doesn't take a lot of problem editors to overwhelm our resources. Risker/Anne

There are some possible alternatives but none of them will apply to our overall (non-geek) audience. Vito Inviato con AquaMail per Android http://www.aqua-mail.com Il 30 settembre 2014 23:39:50 Brian Wolff &lt;bawolff(a)gmail.com&gt; ha scritto:

This is demonstrably not true. I for one have a good reason to use Tor and have not been granted an IPBE. Contact me off-list for more information, I'd be happy to talk about it in a less public venue. The lack of an IPBE is one of the primary reasons I don't use Tor or my anonymous proxy all the time when using the web at home. I hate to say it but I am often times willing to give up the privacy I get when browsing the rest of the web just to not have to disconnect from Tor or my VPN in order to fix a typo on Wikipedia. Actually makes me feel like quite the hypocrite at times as that very behaviour is something I'm always nagging folks about... Additionally in the environment we currently live in, with the NSA doing their thing, I feel we shouldn't be punishing those who care about their privacy. You don't need to have anything to hide to want to protect yourself. Thank you, Derric Atzrott (Also, and not to nitpick, "Tor" not "TOR", please see https://www.torproject.org/docs/faq#WhyCalledTor)

The impact of Tor upon editors' accountability must be, anyway, clearly discussed with the Foundation as maintainer (from a legal pov too). I can be considered a sort of "stakeholder" for patrollers and what I want is "something" lowering Tor risk of vandalism/sockpuppeting at an ADSL-like level. Once that level would be reached, to me, you can even block every non-Tor user ;p Vito Inviato con AquaMail per Android http://www.aqua-mail.com Il 01 ottobre 2014 09:23:08 Giuseppe Lavagetto &lt;glavagetto(a)wikimedia.org&gt; ha scritto:

I would be curious to see what percentage of problematic edits are caught by running all prospective edits through AbuseFilter and ClueBotNG. I suspect those two tools would catch a large percentage of the vandalism edits. I understand that they catch most of such edits that regular IP users make. This would be a good start and would give us a little bit of data as to what other sorts of measures might need to be taken to make this sort of thing work. AbuseFilter has the ability to tag edits for further review so we could leverage that functionality to tag Tor edits during a trial. I could reach out to the maintainer of ClueBotNG and see what could be done to get it to interface with AbuseFilter such that any edits it sees as unconstructive are tagged, and if that isn't possible maybe just have it log such edits somewhere special. If I approached Wikimedia-l with the idea of a limited trial with the above approach for maybe two weeks' time with all Tor edits being tagged, do you think they might bite? I suspect one exists somewhere. I'll reach out to the folks at the Tor project and see if they have any suggestions for ways to prevent abuse from a technical standpoint. Especially in regards to Sockpuppet abuse. I agree with Giuseppe that the measures that will need to be put in place will make editing via Tor more difficult than editing without Tor, but that's acceptable so long as they are not as prohibitively difficult as they are currently. Without having spoken to the Tor Project though, the Nymble approach seems like a reasonable way to go to me. The protocol could potentially be modified to accept some sort of proof of work rather than their public facing IP address as well. If we had a system where in order to be issued a certificate in Nymble you had to complete a proof-of-work that took perhaps several hours of computation and was issued for a week, that might be a sufficient barrier to stop most socks, though definitely some more data needs gathered. Thank you, Derric Atzrott

On Oct 1, 2014 10:55 AM, "Risker" &lt;risker.wp(a)gmail.com&gt; wrote: Unless people want to trial on mw.org (assuming there is dev buy in, not sure we are there yet) Which problem is that? I agree that any such trial should have local community buy in. --bawolff

On Wed, Oct 1, 2014 at 10:40 AM, Brad Jorsch (Anomie) &lt;bjorsch(a)wikimedia.org I'd agree with this. I've never understood why we even hardblock open proxies at all instead of just softblocking with account creation disabled.

And any kind of account creation block will cause issues with users who work across multiple projects as SUL auto account creation is also blocked. On Wed, Oct 1, 2014 at 10:57 AM, John &lt;phoenixoverride(a)gmail.com&gt; wrote:

On Wed, Oct 1, 2014 at 11:05 AM, Jackmcbarn &lt;jackmcbarn(a)gmail.com&gt; wrote: That would rather defeat the purpose of using Tor, if you had to sign in from a non-Tor IP every month or so. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation

On Oct 1, 2014 3:56 PM, "Derric Atzrott" &lt;datzrott(a)alizeepathology.com&gt; wrote: The problem with proof of work things is that they kind of have the wrong kind of scarcity for this problem. *someone legit wants to edit, takes them hours to be able to. (Which is not ideal) *someone wants to abuse the system, spend a couple months before hand generating the work offline, use all at once for thousand strong sock puppet army. (Which makes the system ineffective at preventing abuse) --bawolff

Indeed, this isn't ideal, but its better than the current situation, and at least it is only a one-time thing. I mean, I know we have some crazy socks, but "spend a couple months" seems to me to indicate a fairly expensive attack. I imagine that this might be enough of a deterrence. If someone is willing to invest months of effort to sockpuppet on Wikimedia projects, I don't really think that there is anything we can do to stop them. We could probably reduce this risk slightly as well by providing software that provides a GUI for generating the GPG keys for the user. This software could impose a high-rate limit on how often new keys are made. This could be easily worked around by anyone who knows how to make their own GPG keys, or has access to several computers, but it would stop a lot of would-be-sockpuppeteers. Thank you, Derric Atzrott

Prior to TOR being enabled we need to be able to flag both logged in and logged out edits made via TOR. On Wed, Oct 1, 2014 at 11:00 AM, Brian Wolff &lt;bawolff(a)gmail.com&gt; wrote:

On 10/1/14 8:02 AM, John wrote: There's a $wgTorTagChanges option which does exactly that, except it's currently disabled in CommonSettings.php. -- Legoktm

The abuse filter has no way of identifying TOR exit nodes, thus it cannot be used for this. Some developer will need to interface with the TOR blocking code and use the same TOR identification methods to ID and label both logged in and logged out edits made via TOR.

Realistically there is no reasonable prospect of tracing back an individual IP to a real person 80% of the time without a court order, which is extremely unlikely to ever happen. Even then you can only really link the IP to who's paying the bill, which is only weakly circumstantially related to who really "owns" the edit. If we're going to consider the theoretical possibility that we can might be able to link back an IP to a person with certainly, we might as well start considering that we might be able to do the same if we get everyone in the tor circuit to collude... --bawolff

The folks over at the Tor project actually pride themselves on making a browser that is hard to fingerprint. If we came up with any way to fingerprint individual browser sessions, they'd likely fix it pretty quickly. And of course, this is where the difficulty comes in. All of our current blocking measures are based around using information that is specifically hidden by Tor. The idea is to find a way to block individuals on Tor without having any information about those individuals that might be useful to someone trying to kill them (or at least identify their real world identity). Thank you, Derric Atzrott

On Wed, Oct 1, 2014 at 11:27 PM, Kevin Wayne Williams &lt;kwwilliams(a)kwwilliams.com&gt; wrote: I used to do this for a living in the name of "credit card fraud prevention". Not only is it a difficult problem, but it is also evil. You will not find a method that is fool proof. It is completely possible to partition the browser space into 90% known good and 10% "looks funny". Separating the wheat from the chaff in that 10% is the hard problem however. In the retail space this grey area ends up being managed by heuristics, ad hoc rules that only apply for a brief period of time and labor intensive manual review. Ultimately in the retail space it comes down to letting in enough bad actors that you don't exclude more sales than necessary. You figure out what your acceptable loss rate is and manage the real time transaction approval stream to maximize sales while keeping losses at or below an acceptable threshold. That threshold is typically something between 1% and 1.5% of your total sales volume by both transaction count and dollar value. In a space where we are actually arguing that there is a potential of loss of life for exposed actors, I don't think that it is reasonable at all to discuss ways to increase the risk of exposure by creating and publishing (oh yeah, we are open source and open config for most things here) a recipe for tracking users in a durable fashion based on device fingerprints and other sticky token techniques. Bryan -- Bryan Davis Wikimedia Foundation &lt;bd808(a)wikimedia.org&gt; [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855

On 10/02/2014 09:07 PM, Kevin Wayne Williams wrote: I wouldn't have put it that way, but I've been saying something to that effect to sockmasters for some time when they pull out the "my security is in peril" card -- editing Wikipedia is an intrinsically *public* activity, and if doing so places you at risk of harm then you should not be editing at all as no technology or privacy policy will protect you to that level. That, on the other hand, is a both unfair and unwarranted slur on the work of countless volunteers. Even those that /do/ work on topics of popular culture bring value, but that characterization is nothing short of a demeaning insult to all -- including those volunteers who slave away on the parts of the encyclopedia even the snottiest of elitist must admit has value to mankind. Please read he (coincidentally topical) https://lists.wikimedia.org/pipermail/wikimedia-l/2014-October/074792.html before you embarass yourself further. (And a worth of thanks perhaps couched as an apology to those volunteers might be in order). -- Marc

On 10/02/2014 09:57 PM, Kevin Wayne Williams wrote: I would expect that most of the people who (sincerely) feel strongly about a putative right to edit anonymously are more likely to be looking for edits about political topics than pop culture; few people are hunted down for spewing trivia about the Mousketeers, tarnishing the image of one's Glorious Leader might be more perilous. Which is, IMO, a good reason to not attempt to do so. -- Marc

Thanks for initiating the conversation Derric. I've tried to put together a proposal addressing the general problem of allowing edits from a proxy. Feedback is appreciated. Proposal: * Require an account to edit via proxy. * Allow creating accounts from proxies but globally rate limit account creations from all proxies (to once per five mins? or some data driven number that makes sense). * Tag any edits made through a proxy as such and put them in a queue. * Limit the amount of edits in that queue per account (to one? again, look at the data). * Apply a first pass of abuse filtering on those edits before notifying a human of their presence to approve. * Rate limit global proxy edits per second to something manageable (see data) This limits the amount of backlog work a single user can create to how many captchas they can solve / accounts they can create. But I think it's enough a deterrent in that 1) their edits aren't immediately visible, 2) if they're abusive, they won't show up on the site at all, and 3) it forces the act to premeditated creation of accounts which can be associated at the time of an attack and deleted together. Rate limiting account creation seems to open a DOS vector but combining that with the captcha hopefully helps. Attribution / Licensing: As a consequence of requiring an account to edit via proxy, we avoid the issue of attributing edits to a shared IP. Sybil attack: Or, as it's called around here, sockpuppeting. CheckUser would presumably provide less useful information but the edit history of the accounts would still lend themselves to the same sorts of behavioural evidence gathering that is undertaken at present. Class system: This makes a set of users concerned about their security and privacy trade off some usability but that seems acceptable. A reputation threshold for proxy users can be introduced. After a substantial amount of edits and enough time has lapsed, the above edit restrictions can be lifted from an account. Admins would still have recourse to block/suspend the account if it becomes abusive. Blacklisting: Anonymous credential systems (like Nymble) are interesting research directions but the appropriate collateral to use is still unsolved.

Thanks Tyler. I kept the discussion going here because it sounded above like Derric may already be in the process of doing that and I wanted to keep a unified voice there. Although my suggestion is similar in kind to what had already been proposed, the main object to it was that it would create too much work for our already constrained resources. The addition of rate limiting is a technical solution that may or may not be feasible. The people on this list can best answer that.

On Sunday, October 12, 2014 at 4:45 PM, Marc A. Pelletier wrote: The “that” I was referring to was whether the rate limiting, as I described it above, was technically feasible. Sorry if that wasn’t clear.

On Mon, Oct 13, 2014 at 9:10 AM, Derric Atzrott &lt;datzrott(a)alizeepathology.com&gt; wrote: AbuseFilter can rate limit per account globally, and edits via tor have an abuse filter variable set. So a global filter (and all wikis would have to enable global filters... which is another political discussion) could be used to rate limit tor edits, and also tag any that are made. The review queue I'm not sure about.. not sure if FlaggedRevs can keep a queue of edits with a particular tag.