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
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
