Grants talk:IdeaLab/Partnership between Wikimedia community and Tor community

Past conversations

For persons not accustomed to using Wikipedia, please notice that every article and page has an associated "talk" page for discussion. If you visit any page that is interesting, check the talk page to review comments about it.

• Proposal on Jimbo Wale's talk page: Create a Wikipedia-only read Tor exit node
• en:Wikipedia_talk:Blocking_policy/Tor_nodes
• en:Wikipedia:Advice to users using Tor
• en:Wikipedia talk:Advice to users using Tor to bypass the Great Firewall/Archive 1
• en:Wikipedia:WikiProject on open proxies

I regret to say that all these discussions are messy and improperly documented or archived.

Blue Rasberry (talk) 11:57, 7 February 2014 (UTC)

Making Wikipedia writable for Tor users?

One of the goals of this project, making Wikipedia can be writable for Tor users, is controversial among the English Wikipedia community. See Wikipedia:Advice to users using Tor. For the Wikimedia (Wikimedia, not Wikipedia) policy, see No open proxies.

I would like to open a conversation about this. Is there a way that we can accommodate anonymous Tor users without encountering the abuse and vandalism that resulted in our present policy? Please note that this is not a referendum on whether we should simply enable write access without changing anything else. Realistically, that is not going to happen. This conversation is about trying to figure out a way to get the benefits of allowing Tor users to edit Wikipedia while avoiding the problems associated with doing that. Comments and Ideas Welcome. --Guy Macon (talk) 17:59, 7 February 2014 (UTC)

Do Global IP block exemptions and local IPBE bypass this restriction? PiRSquared17 (talk) 20:25, 7 February 2014 (UTC)

Proposal: Create a Wikipedia-only read-only Tor exit node

I propose that we Create a Wikipedia-only read-only Tor exit node with the following attributes:

Wikipedia-only: The proposed Tor exit node would only be able to communicate with Wikipedia (all languages), Wikimedia, Wiktionary, etc. We should not rely upon the exit node to enforce this, but rather make it so that the exit node cannot reach any IP addresses that are not controlled by the Wikimedia Foundation. For convenience, all of the Wikimedia projects that we decide to allow will be simply called "Wikipedia" for the rest of this proposal.

Read-only: The proposed Tor exit node would not have the ability to edit any of the pages that it has read access to. Again, We should not rely upon the exit node to enforce this, but rather use the standard Wikipedia blocking ability. While it may be desirable to allow write-access if the abuse problems are solved, this is outside of the scope of this proposal.

Physically located in the same room as the Wikipedia servers: In theory, the Onion network can be vulnerable to an adversary who monitors a user’s traffic as it enters and leaves the Tor network. Correlating that traffic may link the sender and receiver.[1] By denying an attacker access to the exit traffic at the ISP level, we force any attacker to get a court order forcing Wikipedia to reveal the exit traffic, thus allowing our legal team to be aware of the surveillance and to appeal it. See TOR FAQ: Can Exit Nodes Eavesdrop?. We should not depend on HTTPS to hide the exit traffic. See How does the NSA break SSL? and How the NSA, and your boss, can intercept and break SSL.

Rate limits and QoS: Rate limiting will allow us to set the amount of bandwidth that the Tor exit node uses to as small or as large as we wish, and QoS will allow us to, if we wish, prioritize Tor traffic below regular Wikipedia traffic. One researcher discovered that Tor exit nodes that use the BandwidthRate configuration option to set a limit slightly below their actual capacity were much more reliable than those that did not. If needed, Tor also allows us to set a separate limit for relayed traffic using the RelayBandwidthRate configuration option.[2] This may mitigate certain clogging attacks. See section 4.3 of On the Risks of Serving Whenever you Surf.

Reduced TCP port Exit Policy: The proposed Tor exit node would use the ExitPolicy accept option to only allow traffic on TCP ports that are needed to access Wikipedia. Traffic to all other ports should be silently dropped. Wikipedia appears to use:
TCP Port 80 (HTTP)
TCP Port 179 (Border Gateway Protocol)
TCP Port 443 (HTTPS)
TCP Port 8649 (Ganglia) [3]

Disable Javascript and other executable files: (Note: this is desirable but requires discussion about technical feasibility and possible collateral damage.) For security reasons, it would be desirable to not allow any Wikipedia editor to be able to place executable files (Javascript, .exe files, etc.) on Wikipedia that run on a Tor users machine. See JavaScript anonymity attack on Freedom Hosting users.

Strengthen HTTPS/SSL: (Note: this is desirable but requires discussion about technical feasibility and possible collateral damage.) As far as is feasible, we should address the issues identified at sslcheck.globalsign.com.

Coordinated with the Tor community and with the Wikimedia engineers: This proposal should not just be evaluated by the Wikipedia or Wikimedia community. Although that sort of input is desirable, it should also be examined closely by technical experts from the Tor project and by the WMF engineers.

Comments/corrections welcome. --Guy Macon (talk) 23:15, 7 February 2014 (UTC)

This is similar to a suggestion that was made on Jimbo Wales' talk page. The comment there by Yawnbox, dated 19:09, 24 January 2014, explains why such an exit node would be unwelcome on the Tor network:

Tor routing is based on ports, like port 80 (HTTP) and 443 (HTTPS). Tor Exit Routers have to explicitly allow specific ports to allow the passage of traffic over said port, which is done in a configuration policy on the Tor Exit Router (the TORRC file), which tells the rest of the Tor network which traffic you're willing to accept. If you accept only port 443 for example (presuming that only HTTPS traffic should pass), and then on Wikipedia's side block all other https-web traffic that is not a Wikimedia domain, you will literally censor the rest of the internet for any Tor client presuming that port 443 traffic will resolve through that Tor Exit Router. Nothing in the current Tor protocol would allow the Tor network to say-- "only this Tor Exit Router can pass traffic to these specific domains". This would not greatly affect the Tor network, as it would take a little bit of time for said Tor Exit Router to gain consensus, but more importantly, the Tor protocol would recognize said blocking and mark said router as a 'bad router', and it wouldn't pass any Tor Exit traffic at all.

However, the desired effect of this proposal could be achieved by setting up a hidden service (how it works, setup instructions). Although a hidden service is normally used to conceal the location of a server, it also affords greater anonymity for those visiting the site, since the communication travels on the Tor network from end to end. Rybec (talk) 15:41, 10 February 2014 (UTC)

Social barriers to implementation

As I understand, the major barrier to implementing this is social. The thought is that if Wikipedia is writable by Tor users then Tor users could be empowered to vandalize Wikipedia in new ways. This is because one of the tools to fight vandalism on Wikipedia is to block IP addresses, but it will never be able to block any Tor user by IP address because all users will share a limited number of the addresses.

This is a serious concern but I think that it can be managed. There is a lot of vandalism from IP addresses but the current policing tools manage it mostly well. Also, if Tor use somehow becomes out of control, one safeguard is that we could set up a changes patrol for Tor users so that anyone editing with Tor would have their Tor use disclosed on Wikipedia and their contributions would go into a special feed for review. I am not sure what is right, but this should be considered.

Are their other social barriers? Blue Rasberry (talk) 12:20, 10 February 2014 (UTC)

Given how rampant surveillance is these days, especially because Wikipedia is targeted by XKeyscore, it is crucial to allow Tor user to edit Wikipedia anonymously. Alonso McLaren (talk) 17:26, 21 February 2014 (UTC)

Benefits of allowing users to edit Wikipedia using Tor

Tor allows users to use Internet services without revealing their IP addresses. If the Wikimedia community supported Tor, that could mean that users who did not reveal their IP address even to the Wikimedia Foundation could be able to edit Wikipedia and contribute to Wikimedia projects. The following classes of people face barriers and risks to contributing to Wikipedia without using a de-identification service like Tor:

• persons who have an anonymous persistent personal identity elsewhere online, and wish to use that identity on Wikipedia without sharing their IP address
• persons who participate in the witness protection program in their countries
• persons who wish to contribute social content which is culturally suppressed, as for social rights movements for LGBT interests or gender rights
• persons contributing media in and about places with legal enactment of censorship against political criticism
• persons who are concerned about contemporary mass surveillance and wish to opt out of being under surveillance

I have had discussions with people who have experienced harm from not using sufficient online protection of their identities and as the result of the harm they suffered they have asked me about Tor and Wikipedia without my prompting. There is no way for me to know how many people want this service but I have met several who have expressed a need for it, and I feel that thoughtful consideration should be made to either grant people a right to edit Wikipedia anonymously with an account which does not reveal their IP, or to consciously exclude these people. Right now I feel that Tor users are excluded but not with much thought. Blue Rasberry (talk) 12:47, 10 February 2014 (UTC)

Everybody, not just people who have experienced harm from not using anonymization tools, need to right to edit Wikipedia anonymously. Remember that Wikipedia is among the sites that are targeted by XKeyscore. Alonso McLaren (talk) 17:31, 21 February 2014 (UTC)

An edit space for blocked users

I think what a lot of these ideas come down to is a need to create a place where blocked users can edit, which is monitored by ordinary users who can do something with material they submit. We would permit:

• Access for open-proxy exit nodes (perhaps any Tor exit node, though a same-room exit node does have some reassurances)

• The otherwise quixotic ability to create a blocked account starting from a blocked IP.

• If material from a blocked account is useful, after a while an admin can take a chance and unblock it and see what happens, allowing normal editing throughout the wiki.

Such a mechanism requires interested normal users to volunteer, which admittedly is easier to postulate than to make happen. And it does raise the bureaucratic bugaboo that some formerly blocked user might evade checkuser detection and get a "clean start" this way. Which shouldn't be a surprise - one cannot be fully committed both to fighting mass surveillance and to practicing it. Wnt (talk) 13:32, 10 February 2014 (UTC)

• Wnt What you propose sounds like the en:Wikipedia:Pending changes restriction which can be placed on individual articles, except that you are proposing a mechanism for this to be put on individual users. Does that capture the intent of what you are saying? If Tor users could have their edits just be flagged as pending changes, then that would eliminate the need for a creation of a new and specialized moderation community. Blue Rasberry (talk) 14:34, 10 February 2014 (UTC)

Bluerasberry Ugghhh... I have a longstanding dislike for Pending Changes, and the notion of polluting otherwise PC-free articles with edits pending review is disturbing. In other contexts the effect of these edits can be that ordinary users find their contributions awaiting review even though they are supposed to be free to edit. Also, I'm not sure reviewers would realize that they were reviewing the contributions of blocked and therefore quite questionable users while approving, say, an external link to an informative but virus infected site. So I'd say stick to one or a few narrow forums that people can browse with "shields up". Wnt (talk) 14:00, 18 February 2014 (UTC)

Wnt Definitely some Tor users would do vandalism, but still your posturing is a bit more defensive than I think there is evidence to justify. Tor users include persecuted demographics who face discrimination in using Wikipedia due to their circumstances. People who want privacy should not be assumed to be out of the ordinary, "quite questionable", or needing to be corralled to protect the community. Many of these people need protection themselves, and in light of government surveillance disclosures, I think that it is more mainstream now than ever before to treat people who wish for privacy with less discrimination. I am not sure how to technically implement this but if there is will then we could find a way. Perhaps you are reading the story about persecution in Greece. I also know of Wikipedians who support LGBT causes in countries where this is illegal, and at a conference I met someone who had a believable claim to be a political exile from their country for what they posted on Wikipedia. It may not be possible to support Tor users but if we do not make a path for them, then I think at least we should talk about them in positive terms and acknowledge that our lack of support for them is our own shortcoming and not because people who want privacy are a danger to others. Blue Rasberry (talk) 12:34, 19 February 2014 (UTC)

I can definitely picture Wikipedia being a lot less like a spy agency itself, not making so much effort to track down "sock puppets" and block whole ranges of IP addresses. The problem is that if we make this mechanism a workaround for that, all the abuse that would have come out anywhere else could come out here. Also bear in mind that if this mechanism actually becomes a significant workaround for people from any repressive regime, they will soon enough be sending provocateurs with the deliberate intention of ruining things. Wnt (talk) 13:06, 21 February 2014 (UTC)

An onion domain for research purposes

Since Tor is currently blocked alongside other anonymous proxies its hard to make an estimate of how much vandalism might caused by Tor users or if their behaviour is different . Its important to remember that the motivation for using Tor over one of the many one-hop proxies out there might result in a completely different user base and I think there is a case to be made that they should not necessarily be treated equally or at the very least that this is question that would be useful to have the answer to.

The easiest solution to enable Tor users, and not users of other open proxies, to edit wikipedia would be to set up a .onion domain, as described above, and apply additional speed bumps. These could come in the form of dynamically scaling CAPTCHAs, marking edits as "Done by Tor user" and perhaps adding dynamic article cool-down periods. Initially speed bumps would be configured aggressively, being relaxed slowly over time until a equilibrium is reached. — The preceding unsigned comment was added by 130.225.96.226 (talk) 16:41, 21 February 2014 (UTC)

Proposal: Try to allow Tor for one week and see what happens

Pretty self explanatory. Alonso McLaren (talk) 17:25, 21 February 2014 (UTC)

I would actually support this a lot. Everyone I have talked to about Tor and Wikimedia has asked for data to back up the abuse anecdotes. We don't have any data though, so we don't actually know for sure how big of a problem we'd have and what needs done to mitigate it. Zellfaze (talk) 13:15, 2 October 2014 (UTC)

Registered users, IP editors, and anonymous users

Whenever anyone edits Wikimedia projects the Wikimedia Foundation and some trusted volunteers, the "checkusers", has access to their IP address. In the case of so-called IP editors, who are those editing without logging into a Wikimedia account, their IP address is displayed publicly in the history logs of the page which undoubtedly discloses more public information to more people than can ever happen with a logged-in user's edits.

There is a long history of calling "IP editors" "anonymous editors", under the common mistaken premise that if the only thing that is known about a person is their IP address, then one knows less about that user than if they only shared the username they chose during registration. This confusion should be clarified, as anyone editing with an IP address is doing less to preserve their privacy than a person who is logged into an account.

There are some discussions about this in these place -

• Recent changes to Anoneditwarning on the English Technical Village Pump
• Addition of stop hand on the Mediawiki template
• MediaWiki:Anoneditwarning on Jimbo Wales' English Wikipedia talk page

These links are all to archived versions of these conversations, and the conversations will likely continue to update. There is no way to make a permanent link to the latest version of these discussions so interested persons should search for these discussions in the relevant forums.

I am sharing this here because this proposal is about making it possible for people to preserve their privacy while editing Wikipedia. The community has already tolerated many years of misinformation in the community culture and bad advice being spread about the best way for users to make decisions about sharing their personal information. Many people are under the impression that if they do edit while only revealing their IP address, then this is the especially protective, when actually it discloses more publicly than would ever happen on any other website which people commonly use.

I feel that this proposal should include plans to educate the Wikimedia community on personal online privacy. Blue Rasberry (talk) 14:05, 23 May 2014 (UTC)

Original ambiguous proposal

I am archiving the original ambiguous proposal here. It did not make a specific enough request to be useful, so I rewrote it.

Extended content
Ultimate goals: Develop Wikipedia as an educational resource using the Tor community's expertise and resources related to freedom of speech and personal rights Give members of the Tor community the support they need to be able to collaborate with the Wikimedia community Establish partnership and communication channels Notify the community supporting Tor that the Wikimedia community would like to collaborate on something with them. Ask the Tor community if they have any ideas for collaboration which seem clever. Once proposals are made, document them in such a way that they can be understandable by both the Wikimedia community and the Tor community Get community feedback Establish the partnership. The end goal is sharing of resources between the two communities Grant the Tor community the resources it needs to be able to contribute to Wikipedia in a way that does not compromise the Tor mission Tor users should be able to interact with Wikipedia and all Wikimedia projects in a useful way. This means presenting a path through which Wikipedia can be writable for Tor users. A January 2014 proposal was to "create a Wikipedia-only read-only Tor exit node". The Wikimedia community offered support for the idea but the implications of this are unclear, as are the necessary actions to realize this. Document Tor on Wikipedia so that Wikimedia users can more easily join the Tor project Wikimedia users should get resources to teach them to use Tor services correctly if they choice to do so Wikipedia already is the place where everyone in the world goes to get basic information. All articles related to Tor and privacy should be developed, and it seems right to have good external links in relevant Wikipedia articles of all languages to help people access Tor. Perhaps the Tor project currently has problems with making itself understood, even to natural supporters like the Wikipedia community.

Blue Rasberry (talk) 17:00, 8 June 2014 (UTC)

Allowing Tor Relay Operators Access to Wikimedia

There is a bug that was just opened on Bugzilla that relates, at least a little bit, to this project. https://bugzilla.wikimedia.org/show_bug.cgi?id=71551 Currently we block all exit relays. This bug proposes that we should unblock exit relays that reject connections destined for port 80, port 443, or any Wikimedia servers, as these exit relays will never allow Tor users to connect to Wikimedia projects. Even if blocking Tor is a good idea, blocking these relays is just collateral damage. Zellfaze (talk) 13:24, 2 October 2014 (UTC)

Cataloging all ways to grant Tor users Wikipedia editing ability

Everything below here was originally posted by Zellfaze to the Wikitech-l mailing list, Tor and Anonymous Users (I know, we've had this discussion a million times).

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. Relevant Quotes
2. Ideas
   1. Nymble
   2. Blind Signing
   3. FlaggedRevs
   4. Tor Exemption Userright
   5. Policy Changes
   6. OAuth
   7. Donate for Access
   8. Account creation off Tor
   9. Fingerprinting
   10. Tor Hidden Service
3. A Note on Current Policy
4. References

Relevant 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

Again, everything above here was originally posted by Zellfaze to the Wikitech-l mailing list, Tor and Anonymous Users (I know, we've had this discussion a million times). Lots of comments on this proposal are ain the mailing list archives. Blue Rasberry (talk) 20:26, 16 December 2014 (UTC)

Archiving from other version of proposal

I am moving this discussion about moderating damage here. It seems like too much to present in the main proposal.

---

While some years ago an inability to moderate damage from vandals might have been likely, the development of Mediawiki software and the social infrastructure of the Wikimedia community itself are more developed as compared to when the policy was implemented. There must be some balance of moderation which would permit good Tor users to contribute to Wikipedia while protecting the Wikimedia community from its major concern, vandals. If Tor users are granted Wikimedia userrights to edit, any of the following strategies could be used to both give them the right to join the Wikimedia community while retaining community protection:

1. Tor users never gain the right to edit as unregistered users, but must always edit from a user account
2. (optional, this already exists in Mediawiki software) Tor users are automatically flagged as "open proxy editors", and logs of such users' contributions go into a public feed to assist recent changes patrol of the contributions of Tor users. The presumption is that Tor users as a population will cause more vandalism, and as such, their contributions should be isolated for metrics study about vandalism and the cost/benefit analysis of this program.
3. Tor users can have all of their contributions flagged as pending changes. Right now, "pending changes restriction" is a characteristic of certain Wikipedia articles in which any user's contributions must be reviewed by another person. Instead of applying this restriction to articles, it could be applied to Tor users until, perhaps, they have a certain number of good contributions reviewed.
4. Tor users cannot create their own accounts, but can be invited to edit Wikipedia through some process in which a trusted third party "Account creator" makes an account for them which is flagged to be able to edit even from an open proxy. This kind of flagging can currently be granted through the process described at en:Wikipedia:IP_block_exemption#Used_for_anonymous_proxy_editing, but it is not currently connected to a process by means of which a Tor user may request an account. There is already a queue for requesting accounts at en:Wikipedia:Request an account, and this would just need to be tied to the account creator userright and the userright to grant IP exemption for this process to work for Tor users.

---

Blue Rasberry (talk) 03:17, 17 December 2014 (UTC)

Feburary 2017 discussion on English Wikipedia

See en:Wikipedia:Village_pump_(policy)#IP_Block_Exemptions_should_be_expanded_to_include_accounts_.285.2B_years.29_in_good_standing Blue Rasberry (talk) 22:23, 2 March 2017 (UTC)

July 2024 mailing list question

Robert Levenstein in the Wikimedia-l mailing list asks about "Blocking anonymous IP addresses"

• https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/thread/LTLT6M366O42MYTNZ4TNT4FRX2MS4NOS/#GFDU32KV4GDRN2CR3CIWX4PQIERP2BYH

instead of answering by email, I am answering here.

Here is my opinion: there is going to be no progress on updating policy to grant permission for editing Wikipedia from VPNs until someone curates the Wikipedia / Wikimedia documentation on this. That could happen either through a single volunteer's heroic effort, which would be a big sacrifice, or through a sponsored effort with a Wikimedia grant or external partnership.

Briefly, the Wikimedia community makes decisions based on documentation, and the documentation for this issue is mostly from 2006. That 2006 documentation seems like established canon, but actually it is based on even older, more casual conversations.

I tried to sort some of this out about 10 years ago. There was a major Wikimedia Foundation addition to it a few years ago through the IP masking project, but that project mostly ignored the existing documentation and wrote parallel guidance, which further complicates some things.

Here is a plan that I think would lead to progress:

1. Someone gathers all guidelines on this issue, probably about 20 of them, and all major conversation threads, probably an additional 20
2. Redesign one of the purported main guidelines, and list all the previous conversationsInterpret the sum of it all.
3. With all of this together, there will be insight on what the guides cover and what they neglect to cover
4. Now propose a contemporary update. The usual problem is that people dismiss proposals because they supposed that the documentation already covers the issue, but with documentation at hand, this misconception will not occur

Here is some existing documentation to get started

• Grants:IdeaLab/Partnership_between_Wikimedia_community_and_Tor_community
• Meta:Open proxy detection
• mw:Trust and Safety Product/Temporary Accounts
• WikiProject_on_open_proxies
• en:Wikipedia:WikiProject_on_open_proxies
• No_open_proxies
• en:Wikipedia:Open_proxies
• en:Wikipedia:Blocking_IP_addresses

Bluerasberry (talk) 12:35, 30 July 2024 (UTC)

@Bluerasberry@WereSpielChequers from the Trust & Safety Product side, I am interested in this conversation! It would be good to discuss together. I wrote this note on enwiki yesterday outlining some work we're doing to try to reduce the need for IP blocks, and instead to use IP address information as an additional signal in deciding how to deal with an incoming edit/account creation/request. KHarlan (WMF) (talk) 16:26, 15 August 2024 (UTC)

Happy to do a Zoom call. I don't know much about open proxies, so I'd keep that discussion separate from this. But as with other areas I suspect it would be worth to do some research, and I seem to remember one key issue was identifying and unblocking former open proxies. WereSpielChequers (talk) 10:56, 16 August 2024 (UTC)

I read the same mailing list post, but I'm not sure which reason the IP block came about. It could be from our intolerance of open proxies and VPN editing, but there are at least two other possible reasons for the block. When we have unusually problematic vandals and other miscreants we sometimes do range blocks - not just the IP addresses that have been problematic but a whole range of IP addresses that are run by the same Internet Provider, the justification being that the need to deal with one problematic editor is greater than the potential value of other IP edits from the same range. At least with range blocks the blocking admin can get an idea of what useful edits come from that range. We also do hardblocks, not only is your account blocked but also any IP address that you try to login on with that account. Of course in this case there is no way to evaluate what we have lost, the assumption is that we are dealing with household IPs and if the first block was when someone was at school the second IP block will come when they go home and try to edit there. But it could just as easily be that we've blocked someone at school and now they've tried to login at their neighbourhood cafe and we have just blocked that IP address becasue the account is on a hardblock.

Many of these decisions, especially the hardblocking of accounts, were decisions made early in the life of the project, back in days when vandalisms might stay up for minutes and had to be reverted by a human volunteer. Things are different now, we have edit filters that prevent much of the vandalism from happening and bots that revert much of what gets through in real time. We still get a little bit of vandalism that gets through to the point where backstops like me pick it up. But given the highly automated way we deal with the vast majority of vandalism maybe now is a good time to be more circumspect about blocking IP addresses that haven't yet done a bad edit. Though I'd feel more comfortable if we first made our recent changes patrol more efficient as we still get some blatant vandalism coming through because some new edits aren't looked at by anyone. So whether we lower our guard re open proxies or some other are of IP editing I would like us to first implement something such as Invisible flagged revisions WereSpielChequers (talk) 11:21, 1 August 2024 (UTC)

@WereSpielChequers: Yes I agree with all. Our blocking of IP addresses includes all VPN use, range blocks which can indiscriminately affect many users, and hard blocks on individuals including those who have a legitimate need for VPN privacy and must go through the confusing IP-block exemption process to gain editing rights. Yes also, we need protection policies, but there are some technology and policy changes which merit reconsideration of some of our practices.

A few years ago at my school we did a project called Research:Automatic Detection of Online Abuse. The technical part of this is outdated but trivial to replicate, and as you say, now we use automation to detect misconduct at scales which equal tens of thousands of human labor hours annually. That technical change justifies discussing social change. I particularly want a path for users with sensitive issues (like editing while LGBT+, doing activism, or facing oppression) to register VPN for personal safety while also complying with Wikimedia security needs.

I am not sure how all this looks but yes, your idea for invisible flagged revisions totally could work. A VPN-using editor could be monitored with flags either indefinitely for extra scrutiny or until they establish a trusted online pseudo-anonymous persona. This idea is fine; perhaps others have other ideas, but regardless yes I want more discussion.

It seems like we two are interested. I am standing by if and when others want to join to advance the conversation. Thanks for sharing a workable proposal for going forward. Bluerasberry (talk) 18:21, 1 August 2024 (UTC)

Thanks. I've replied re the invisible flagged revisions idea on its talkpage. So just sticking to IP editing ideas here, I'd have thought most people would be relaxed if we find some ways to make it easier for vulnerable editors to get VPN rights. Allocating it on request to anyone whose IP geolocates to certain oppressive countries might be one practical route. As for a general amnesty for old IP blocks from hardblocking and range blocks, I think one approach would be to do it for some countries. We all know that the movement has some pretty extreme geographic skews, even the WMF would buy into that. Clearing old IP blocks in say Nepal, Jamaica or even South Africa would be unlikely to seriously inconvenience the whole community, it might give a real boost to editing in the countries we test this in. If it works in small English speaking countries we might get consensus to test this in Nigeria or India. Obviously if we do this in some smaller countries and we don't get extra goodfaith editors then at least we have tested it. But if it works we have a way to make it slightly easier for new editors to join us in some countries where we are badly underrepresented. WereSpielChequers (talk) 19:58, 1 August 2024 (UTC)

Just want to flag that since Wikipedia community's voice is the loudest, it tends to drown out other sister projects' POV. We have a documented example of someone who wanted to improve Wikivoyage while travelling but cannot do so because of the whole VPN block across all projects. With the improvements on AI bot detecting vandalism, we should examine whether projects with lower risks (e.g. Wikisource, Wikinews, Wikivoyage, Wikispecies) should not be subjected to blanket VPN block and instead shift towards behavioral detection? OhanaUnited^{Talk page} 15:49, 25 September 2024 (UTC)