pickaproxy.com blog

Tor "platform" snapshot

We have now simplified our "version" snapshot to remove "Guard" and "non-Guard" identification, keying only on whether a node is an "Exit" or "non-Exit" node, to keep the list shorter.

And we have now added a new "platform" snapshot showing which operating system is being used by each Exit and non-Exit node.

These are only currently "running" nodes, so any nodes out-of-service are not included in these snapshots.

I see there are 26 nodes running "Darwin" (which I believe is Apple Mac running OS/X), 56 nodes running FreeBSD, 607 running Linux, 3 running NetBSD, 19 running OpenBSD, 2 running SunOS, 28 running Windows 2000, 30 running Windows "Longhorn" (now officially called Vista), 56 running Windows 2003, 307 running Windows XP, and 1 running Windows ME. 

If my math is right, that adds up to 412 running some flavour of Windows and 713 running some flavour of Unix.

Tor and wikipedia

wikimedia.org (the Wikimedia Foundation operates Wikipedia and other projects) has an interesting analysis of Tor users at meta.wikimedia.org/wiki/Editing_with_Tor that also gives an excellent description of how Tor works.  Basically they are explaining that Tor users will find that they are not able to edit wikipedia and wikimedia pages in some instances - usually when another Tor user on the same exit node as you has caused the wiki sysops to take notice of their vandalism and then attempt to stop it by blocking all access from that exit node (also known as IP Blocking since it is targeted against a specific IP Address).

Tor "version" snapshot

We added a new "Version Summary Snapshot" to pickaproxy.com yesterday after reading a post by Mike Perry on the or-talk mailing list where he said:

"Want a faster Tor? Upgrade, inform others. For those of you who are not subscribed to or-announce and/or have friends who use Tor, the latest Tor stable should provide significant performance/capacity increase once most clients upgrade. According to my measurements with TorFlow, there should be roughly four times as much capacity once the network rebalances. In addition, many users should experience noticable improvement in performance just based on the fact that we are choosing guards in proportion to their bandwidth and expiring guards that were selected with the buggy uniform algorithm. Also, once the network is balanced, we can begin to investigate both reliability scanning options and Johannes Renner can finish his Master's Thesis on performance enhanced path selection. :) http://archives.seul.org/or/announce/Aug-2007/msg00001.html"

It seemed there was an obvious need to show how current each of the running nodes were, in terms of the version of the Tor software they were running.  This latest Tor version 0.1.2.17 (stable) and 0.2.0.6-alpha (development) is a significant change that Mike has done a lot of work to get released - he has been posting a lot of his findings to the or-dev mailing list from his work on TorFlow, which is a set of python scripts written to scan the Tor network for misbehaving, misconfigured, and overloaded Tor nodes.

Also, as part of our pickaproxy.com service, we will be making sure that our users know which Tor version is being used at their selected exit node, and when there are significant security risks with a specific version, either letting them know, or automatically NOT allowing connections through them.

Maybe we should even send out email notices to node operators who are running insecure versions? Each node operator has the option to identify an email contact address. Without them opting in this would likely be bad form. But in the interests of security I wonder if someone should take this on, or should we?