Editing with Tor
|This page is kept for historical interest. Any policies mentioned may be obsolete. If you want to revive the topic, you can use the talk page or start a discussion on the community forum.|
Tor, The Onion Router, (https://www.torproject.org/) is an anonymous distributed gateway to the public Internet. However, if you use Tor, you will sometimes be blocked from editing Wikimedia projects. Some details and discussion links follow.
|Wikipedia has more about this subject:
|Wikipedia has more about this subject:
What Tor does
Tor is a technology to conceal a user accessing the Internet. Tor users are trying to be anonymous. Tor works by relaying TCP streams through "onion layers" called Tor nodes.
- The Tor client on the user's own computer will make an encrypted connection to a Tor entrance node, the first onion layer.
- The Tor entrance node makes another encrypted connection to an intermediate Tor node, the second onion layer.
- Most connections use three layers, so that node makes a third encrypted connection to a Tor exit node, the third onion layer.
- The Tor exit node, or Tor proxy, then makes a direct, unencrypted connection to Wikinews.
Wikinews sees the Tor proxy, not the Tor user, make the connection. Meanwhile, other persons will observe a connection between the Tor proxy and Wikinews, a connection between two Tor nodes, or a connection between a Tor client and a Tor node. They will not know which Tor users are connecting to Wikinews; thus the Tor users who do connect to Wikinews are anonymous. (There are weaknesses, for example attackers could watch both ends of a connection and match them.)
Vandals can use Tor. Users can and do hide behind Tor to make malicious edits on Wikimedia projects. When this happens, wiki sysops will try to block the attacker. However, Tor is hiding the attacker, so sysops can only block the apparent source of the attack: the Tor exit node, the Tor proxy.
To safeguard anonymity, Tor often switches exit nodes. So the attacker will quickly start to attack from a different Tor proxy. Sysops will block that proxy, and eventually many or all Tor proxies are blocked.
A block against a Tor proxy, unlike certain types of blocks used for shared or dynamic IP addresses, blocks all users (logged in or not) from editing the wiki. Although it is highly improbable that every Tor node will be blocked due to the ever-changing nature of the network, there is no way to guarantee that the node you are assigned has not been or will not be, used by a vandal.
Meanwhile, users who help Tor by running a Tor relay will find themselves blocked from editing the wiki unless: i) their Tor relay is not an exit node. ii) they block exits to the wiki or iii) they edit from a different IP address.
The blocking of tor is unfortunately not an assault on trolls or people with a barrow to push (POV-pushers) but rather on the right to anonymity by anyone requiring it. The problem of vandalism is deeper than the band-aid approach of blocking tor users from access to Wikipedia. Instead of this blunt instrument, the types of pages that are being vandalised should be analysed and stricter measures taken against the editing and vandalism on those pages rather than a blanket ban on all tor users. There are good reasons why a genuine user needs to edit anonymously as he/she may be residing in a country which does not allow them to express rival political opinions and has draconian laws to punish those who do.
- English Wikipedia tends to block many Tor exit nodes.
- Meta and Wikimedia Commons block some Tor exit nodes, but not most of them.
- Tor users can still edit some other Wikimedia projects unimpeded. This includes some English-language projects.
- Some users must disable Tor to edit; these users thus lose protection against traffic analysis.
- Some users cannot edit Wikimedia projects from computers that are also Tor exit nodes.
- There is a poorly-documented, IP blacklist file maintained by Brion Vibber for Tor nodes and open proxies.
Tor cannot protect the anonymity of users who reveal their own personal information, for example by editing under a user account with their real name and personal info on their user page. So those users do not benefit much from Tor.
If you run a Tor exit node, you can choose to block exits to port 80 and/or to Wikimedia IP addresses. Tor users then will not exit to read or edit Wikimedia from your node, and your node should not be blocked.
The troubles with Tor
- March 2006, Wikitech-l Tor and "X-Forwarded-For"
- links to many other threads: https://phabricator.wikimedia.org/T71333#728636
Related policies, guidelines and essays
- Meta:No open proxies - note that unlike Tor, most open proxies do not protect against traffic analysis.
- Meta:WikiProject on open proxies blocks open proxies on multiple Wikimedia projects, potentially including Tor exit nodes.
- The XFF project
- Actually, the XFF project cannot help Tor users edit Wikimedia projects. Tor exit nodes protect anonymity, so they do not provide X-Forwarded-For headers revealing the Tor user! However, it can help in one case – when there is a Tor exit node behind an ISP proxy (when the proxy handles all outgoing web, port 80 connections but does not stop incoming connections to the Tor exit node). By trusting the XFF header from the ISP proxy, the Wikimedia projects can block the Tor proxy while allowing connections from other users behind the ISP proxy.
- Tor hidden service
- Suppose that Wikimedia took the effort to set up a hidden service to access and edit Wikimedia projects. A Tor hidden service conceals its own location while allowing only Tor users to connect. For example, the hostname "6ua4nhltph56henu.onion" connects to the IRC network Freenode. Give Wikimedia a "*.onion" hostname, which corresponds to an IP address on the projects like "127.0.0.1" or "192.168.0.18", and tell all Tor users to edit through the hidden service; then sysops have a way to block Tor edits during attacks and unblock at other times. A Wikimedia hidden service would require extra maintenance and consume extra resources on the Wikimedia servers. A hidden service probably provides less benefit than the cost of setup, as Tor users would still be blocked from editing during attacks, and sysops would not know when an attack ends and thus when to unblock the hidden service.
- Suppose that there was a checkbox so that a sysop could block an IP address without blocking (autoconfirmed) user accounts editing from that address, analogous to how a cloaked Freenode user can connect through Tor even when Freenode blocks Tor connections. (For example, Rob's mockup of a new blocking interface for MediaWiki, screenshot 1 and screenshot 2, includes such a checkbox.) Then Tor users who already have accounts (which might need to be four days old, and created while not using Tor) could edit using Tor, provided that the sysop did not use the checkbox. Hopefully, the sysops will block the usernames of vandals who come through Tor, without needing to apply the checkbox and block all user accounts from a Tor exit node.
Related site messages
- Meta:WikiProject on open proxies
- http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ – Tor Frequently Asked Questions