No idea how good the data is, I assume it's good, but in my mind this is impressive just on the visual representation of it alone. What a fantastically beautiful display of information, the UI is great all around!
One suggestion for the UI: when you click a + on an option, the minus should be at the bottom of the expanded option, so that you don't have to move the mouse to close the expansion.
I'm wondering if this might because Australia has less traffic per node, so most of the Australian nodes aren't reaching the display threshold (top 500 or whatever nodes).
A disproportionate amount of traffic seems to be passing through Monrovia, Liberia compared to the rest of African continent and even more developed places like Australia. Can anybody shed some light on this ?
There are less than 50 relays in Australia and none of them come close to IPredator. Every AU relay combined has a middle probability of 0.0246% and an exit probability of 0.0060%.
IPredator alone has an exit probability of 2.1961%.
IPredator is a Swedish VPN service that appeared when the "Ipred" law was passed in Sweden, a law that was passed to allow rights holders to find and prosecute people who torrent stuff. So most likely, it's used for piracy.
Although the people running the relay may be associated with piracy, that doesn't mean this exit node is any different than any other Tor exit node. Traffic on the Tor network is doesn't distinguish by "pirated" content or not. They're simply a company with privacy conscious employees who are probably using their high-bandwidth relay as a form of advertisement.
Must be just the geographical center of the USA. Probably it just puts all the relays which don't have further geolocation than the USA, there. It doesn't do the same for Russia, though...
No, this information is publicly available when your Node joins the Tor network. All nodes (except for a limited set of entry-nodes) are publicly listed as being a part of the Tor network. Their IP addresses are used to approximate their location based on where the IP address is registered.
Because the nodes in a path are determined randomly, with weighting based on publicly available scores, you can simply estimate the amount of traffic between any two given nodes. Here's a summary of how routes are chosen:
And here's the code that does the traffic estimation based on node bandwidth scores (edit: hmm, seems that code might be slightly inaccurate, added a top level comment to point this out...):
I run some Tor relays on Scaleway, currently handling close to 100Mbps for some 3.60€/month after tax.
Although my uptime isn't exactly spotless, I think I'm getting just what I paid for, and I'd gladly recommend them (if and when they start accepting new customers again).
Interesting theory, I'd have assumed it's a combination of cheaper bandwidth, better peering arrangements and a population almost twice the size of the US.
Kansas has some big data centers in it (there's a reason google fiber launched there). Lots of dedicated server and colocation providers are located in Kansas City. In order for these providers to receive IP addresses from ARIN, they must register with ARIN as an "autonomous system" (AS). One of the items on the form they must complete is the geolocation of the IP address block they are being assigned. That geolocation is often the location of the provider company, not necessarily the location of the server(s) the IP(s) point to.
Server providers register as autonomous systems, and purchase IP space in large blocks. They often have servers at multiple data centers, with VLAN routing configured to switch packets at the ingress IP to whichever server that IP is assigned to. When a client rents a server from a provider, the provider assigns the client some number of IP addresses from its available pool. Many times, the provider does not actually SWIP (officially delegate via ARIN) these IP addresses to the client, so the registration with ARIN will not reflect the owner of the server an IP currently points to.
tl;dr When a packet goes to an IP belonging to an AS registered with a certain geolocation, the AS can switch that packet to wherever it wants.
While the other commenters may be correct and seem to know more about this than I, almost every time I've seen stuff geolocate to "Kansas" it's geolocating to the United States, with no further level of detail available. The mapping software finds the geographic center of the United States (which is somewhere in Kansas) and puts it there
Brightest spots in capitals are probably caused by IP geolocation. Whois for many IPs returns main ISP HQ address which usually is based in the capital city. Also, geolocation tools will return capital city if no specific information other than country is available.
I think they could improve they ip2address tool, because I would expect some bright spot at hetzner datacenter and it's not there (while whois for IPs of my servers there returns proper location of the datacenter).
Was just making a joke but thanks for your comment :). The joke was that it looks like a pentagram - but clearly it's just because the big European capitals are formed in that way. That just means Evil has been corrupting the elite of Europe since before Tor...
Traffic sent over TOR is unencrypted. Use a VPN or SSH tunnel of some kind and you've got location obscured and traffic encrypted. Boo-yah. Slow as shit though.
The traffic is only unencrypted if the destination traffic would normally be unencrypted. That means that an exit node can't MITM what would already normally be an HTTPS connection. It's a small nitpick grammatically, but the distinction is an important one.
Edit: Another potential concern that I hadn't thought of might be pavki's concern for traffic correlation attacks, but that's entirely speculation on my part since they haven't provided any clarification to their original comment.
No, traffic sent through tor is encrypted all the way to the exit node. From there, it's in the clear (how else would the data get to its destination on the open internet?)
VPNs are exactly the same. They're encrypted to your provider and cleartext from there. Except the VPN provider knows exactly who you are because they see the IP you're connecting to, in addition to the content. A tor exit node only sees the content, but does not know the source.
No matter how you're connecting, you need to ensure you are running encrypted protocols (SSH, https, ...) to protect against whoever relays your traffic. Tor, VPNs etc do not change this.
I think it doesn't exactly reflect how paths are chosen based on relay bandwidth scores, if we compare to the actual path selection algorithm: http://tor.stackexchange.com/a/114
I might be missing something, but it seems that relay same-family and same-/16-subnet exclusions are ignored. This might bias the visualization to increase the apparent traffic between popular nodes, while in reality, the traffic should be slightly more evened out with less popular nodes. Hard to tell if this effect makes any visible difference without analyzing the data, though. Either way, because of the way the code is structured, it shouldn't be too hard to fix: just simulate full paths instead of single connections between nodes.
anyone else think it is curious that there is hardly any Tor traffic in/out of Seattle? You would think with the high density of tech-types, and proximity to pacific links, that there would at least be something?
72 comments
[ 3.2 ms ] story [ 138 ms ] threadThere are less than 50 relays in Australia and none of them come close to IPredator. Every AU relay combined has a middle probability of 0.0246% and an exit probability of 0.0060%.
IPredator alone has an exit probability of 2.1961%.
(You can see these stats with Tor Compass: https://compass.torproject.org/)
http://tor.stackexchange.com/a/114
And here's the code that does the traffic estimation based on node bandwidth scores (edit: hmm, seems that code might be slightly inaccurate, added a top level comment to point this out...):
https://github.com/unchartedsoftware/torflow/blob/master/pub...
OVH and Free Telecom probably host a huge amount of Tor traffic in FR. Easily do 300 Mbps 24x7 for sub-$15/m dedicated server.
OVH also has subsidiaries in other EU countries that will geolocate back to those countries (hosted in FR physically).
ovh - https://www.kimsufi.com/us/en/index.xml
Although my uptime isn't exactly spotless, I think I'm getting just what I paid for, and I'd gladly recommend them (if and when they start accepting new customers again).
[1] https://www.online.net/en/dedicated-server/dedibox-scg2
Here's a link to bookmark; https://console.online.net/en/order/server_limited
Occasionally there will be deals like 2xSSD HWraid 8-16 core 32GB/64GB ram for <$50/m there (if it's blank there are no promos).
Server providers register as autonomous systems, and purchase IP space in large blocks. They often have servers at multiple data centers, with VLAN routing configured to switch packets at the ingress IP to whichever server that IP is assigned to. When a client rents a server from a provider, the provider assigns the client some number of IP addresses from its available pool. Many times, the provider does not actually SWIP (officially delegate via ARIN) these IP addresses to the client, so the registration with ARIN will not reflect the owner of the server an IP currently points to.
tl;dr When a packet goes to an IP belonging to an AS registered with a certain geolocation, the AS can switch that packet to wherever it wants.
I think they could improve they ip2address tool, because I would expect some bright spot at hetzner datacenter and it's not there (while whois for IPs of my servers there returns proper location of the datacenter).
Nevertheless, awesome visualization.
Edit: Another potential concern that I hadn't thought of might be pavki's concern for traffic correlation attacks, but that's entirely speculation on my part since they haven't provided any clarification to their original comment.
VPNs are exactly the same. They're encrypted to your provider and cleartext from there. Except the VPN provider knows exactly who you are because they see the IP you're connecting to, in addition to the content. A tor exit node only sees the content, but does not know the source.
No matter how you're connecting, you need to ensure you are running encrypted protocols (SSH, https, ...) to protect against whoever relays your traffic. Tor, VPNs etc do not change this.
I think it doesn't exactly reflect how paths are chosen based on relay bandwidth scores, if we compare to the actual path selection algorithm: http://tor.stackexchange.com/a/114
I might be missing something, but it seems that relay same-family and same-/16-subnet exclusions are ignored. This might bias the visualization to increase the apparent traffic between popular nodes, while in reality, the traffic should be slightly more evened out with less popular nodes. Hard to tell if this effect makes any visible difference without analyzing the data, though. Either way, because of the way the code is structured, it shouldn't be too hard to fix: just simulate full paths instead of single connections between nodes.
https://github.com/unchartedsoftware/torflow/issues/4
Unnamed Rd, Charleston, SC 29492, USA 32.912336, -79.862333
https://www.google.ca/maps/place/32%C2%B054'44.4%22N+79%C2%B...