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