Atlas Recent Improvements

by irl | March 6, 2017

Atlas is a web application to learn about currently running Tor relays and bridges. You can search by fingerprint, nickname, country, flags and contact information and be returned information about its advertised bandwidth, uptime, exit policies and more.

I'm taking this opportunity to introduce myself. I'm Iain R. Learmonth, or just irl on IRC. I began contributing to Atlas in June last year, and I'm currently serving as the maintainer for Atlas. We have made some usability improvements to Atlas recently that we are happy to share with you today.

Thanks to the work of Raphael and anonymous contributors for their help in producing patches. We will continue to work through the open tickets, and if you have a feature you would like to see or spot something not working quite correctly, please do feel free to open a ticket for that. If you would like to contribute to fixing some of our existing tickets, we have a new guide for contributing to Atlas.

Improved Error Handling

  • Added a new message to warn users when the Onionoo backend is unavailable [#18081]
  • Added a new message for the case where Onionoo is serving outdated data [#20374]
  • No longer attempts to display AS or geolocation information when it's not available [#18989]

UX Improvements

  • Added tooltips to give descriptions of the meaning for flags [#9913]
  • Made it easy to distinguish between "alleged" and "effective" family [#20382]
  • Removed the graphs for which the data backend will never have any data [#19553]
  • Graphs that have no data, but which may have data in the future, now give a "No Data Available" message [#21430]
  • Relay and bridge fingerprints will now wrap when on smaller screens [#12685]
  • Tooltips are repositioned to avoid them being clipped off on smaller displays [#21398]

Standards Compliance

  • Now HTML 5 compliant according to the W3C Validator (including generated HTML) [#21274]

Comments

Please note that the comment area below has been archived.

March 06, 2017

Permalink

Backend error!

Atlas is unable to get a response from its backend server. This probably means that the backend server is unavailable right now. This can also happen, however, if you did not format your query correctly. Please have a look at this page that explains what type of search queries are supported by Atlas.

DDoS?

Since posting this post, the backend has been serving upwards of 2.8k requests per second, while it normally sees around 600 per second. It does seem to have calmed down a little now though.

March 06, 2017

Permalink

17:00:04.152 TypeError: d3.select(...).node(...) is null
mainDetailsView<.plot() main.js:169
mainDetailsView<.render/<.success/<() main.js:220
forEach() self-hosted:208
b.forEach() underscore-min.js:11
mainDetailsView<.render/<.success() main.js:210
graphModel<.lookup_weights/xhr<() graph.js:150
f.Callbacks/n() jquery-min.js:2
f.Callbacks/o.fireWith() jquery-min.js:2
w() jquery-min.js:4
.send/d() jquery-min.js:4
1 main.js:169:20

The backend has been under heavy load today, probably due to this blog post. While we try to catch errors and display error messages, sometimes there are things that still get through. In this case, the request to the backend for bandwidth information looks to have failed while other requests have succeeded. This happens rarely enough that we haven't hit this problem ourselves yet.

I've filed a ticket for this, and we will hopefully investigate soon: https://trac.torproject.org/projects/tor/ticket/21658

March 06, 2017

Permalink

[Modertor: Sorry, OT, but an important issue]

Is Tor cryptography ready for this?

https://www.theregister.co.uk/2017/03/06/ibm_has_cloud_access_to_quantu…
IBM has cloud access to quantum computer 400 times smaller than D-Wave system
Big Blue will build 50-qubitter in 'next few years'
6 Mar 2017
Chris Mellor

> IBM says it will build commercially available quantum computing systems accessed through its cloud platform, but D-Wave has a claimed quantum computer 400 times bigger.

You guys are my heros!

Yes, this is *exactly* what I was talking about!

> An attacker currently monitoring and storing circuit-layer NTor handshakes who later has the ability to run Shor's algorithm on a quantum computer will be able to break Tor's current handshake protocol and decrypt previous communications.

(Because our adversary can record the packets exchanged during the ephemeral key exchange, as well as the subsequent data packets, later decrypt the key exchange packets using their quantum computer, then use the recovered ephemeral key to decrypt the actual data sent/received by the hapless Tor user. If I do not misunderstand.)

Regarding this statement:

> It is unclear if and when such attackers equipped with large quantum computers will exist, but various estimates by researchers in quantum physics and quantum engineering give estimates of only 1 to 2 decades.

This estimate may be optimistic, although clearly it is important not to be panicked by oversold claims from companies anxious to cash in on the "Big Data" "AI" juggernaut.

IBM is one of the companies with deep pockets which is pushing hard to compete with Dwave, and the latest word from their marketeers is that IBM will field a 50 qBit true quantum computer in a few months. (First application they mention: AI for cancer moonshot--- the usual AI hogwash our adversaries try to peddle to the general public. In the nineties, Biden was for the Clipper chip... some things never change.)

> post-quantum-secure lattice-based key-exchange

Good, I sort of understand some of the general principles in lattice based cryptosystems.

> Additionally, there are implementations in Go by Yawning Angel, available from [4] and in Rust by Isis Lovecruft, available from [5].

Very good to know you have your best people working on this--- shows the community Tor Project really is preparing the ground for post-quantum reality!

The details of the post are beyond me, but in general it seems that Tor Project must try to have at least two post-quantum ephemeral key exchanges ready ASAP.

I take the point that the greater computational resources needs makes finding protocols admitting fast but secure hardware implementations is an additional complicating factor, wow. Keep up all your good work!

Er, just three more scary prospects to maybe keep in mind:

@ GK: please help try to convince Debian (on which Tails is based) to take seriously the LUKS backdoor (hit enter a certain number of times and get a shell suitable for messing with the / partition, for example by modifying the kernel to snag the legit user using a keylogger during his/her next login). This LUKS "feature" should be removed as a matter of some urgency. Please direct DP's attention to The Intercept's story disclosing a "Statement of Work" for a 3 week lockpicking course to be taught by two USG operatives (with "10-15 years of operational experience using the techniques taught in the course domestically or abroad"!) to a "force protection unit" at a US military base in Japan. The clear implication: US operatives routinely commit "covert building intrusions" in the USA and in allied nations such as DE, Japan, etc. Years ago, the Church Committee revealed that FBI routinely targeted journalists, lawyers, doctors, civil rights activists, environmentalists, and labor organizers with such burglaries during the period 1920-1975, and I fear that there is every reason to think USG spooks have reverted to form.

@ Tor people planning international travel: not to spread FUD, but please be very careful in airports. Kim Jong-nam killing much in the news, but as you probably are aware, there has been a spate of human rights workers who unexpectedly "hung themselves" (thus local authorities) in various airport bathrooms during routine international travel. If possible, avoid traveling alone and look out for each other. I fear that the Kim Jong-nam killing signals a new willingness of certain governments (not just DPRK) to assassinate human rights workers anywhere in the world. NSA has hired a psychologist whose speciality is making murder look like suicide. And VX was invented by USG, not by DPRK.

On the bright side (?), you know you are having a positive effect when the world's ugliest governments (not just DPRK) start trying to kill you on the street!

Hope TP can continue to work towards geographic diversity of key deployed human resources, so to speak. The intensity of physical surveillance in USA is really becoming terrifying. FBI spyplanes, vehicles, pole cameras, stakeouts, tails, mail diversions, the works. All signs suggest USG may be about to strike at Tor Project in the USA, so IMO the Project cannot move to another country fast enough. Hope I am wrong, but in past this level of surveillance has been followed by really bad news for human rights people.

These days, it seems like all the world's governments keep pushing up the deadline for human extinction.

Stay safe out there, Tor people!

In addition to lattice-based systems, I hope someone is thinking about possible post-quantum key exchange based upon possible trap-door functions which exploit that fact that string sorting is fast (that's the trap door can be opened by someone who possesses the secret half of the keypair).

We need more ideas fast in case lattice systems turn out to be vulnerable (as happened with knapsack systems).

This looks cool. It uses the same backend, but adds itself as a proxy. This is great for clients like lynx and for those that don't want to use JavaScript. One of the reasons Atlas does require JavaScript is to attempt to push processing to the browser and place less stress on the Tor Project infrastructure. I've noticed that that project's site is rather slow to look up details, but if you fit into a category where Atlas doesn't work for you, then it looks to be a good alternative.

March 06, 2017

Permalink

Do these usability improvements include being able to see any -- even the most basic -- information without JavaScript?

There's nothing hard, "the reasons Atlas does require JavaScript is to attempt to push processing to the browser and place less stress on the Tor Project infrastructure."

Because there's some real number crunching involved with transforming the nickname, fingerprint, adv bandwidth, flags, etc. to HTML? It's essentially a table of data; we're not generating RSA keys or doing 3D rendering here. The graphs are the only part I can imagine being even remotely resource intensive, and for many purposes I can do without them. What processing are we talking about exactly?

March 06, 2017

Permalink

Thanks for making this tool more useful! The community appreciates the work that you've been doing.

March 06, 2017

Permalink

Can I find the whole online history of particular Tor relay (IP address, when it was online and offline) for all years? Does Atlas have this functionality?

Atlas does not provide this functionality, because its data backend does not serve this data. But you might like ExoneraTor where you can "Enter an IP address and date to find out whether that address was used as a Tor relay".

March 07, 2017

In reply to karsten

Permalink

Can we trust the displayed uptime as a proof of uninterruptible service provided?

Well, the uptime is something that the relay or bridge claims, so we need to trust them. ExoneraTor looks at the relay lists where 9 directory authorities each perform their reachability tests to all relays and then vote on whether a relay is online or not. That's likely more trustworthy.

March 07, 2017

In reply to karsten

Permalink

Thanks! However, how I would know about it? I cannot find link to it on metrics.torproject.org. Why?

March 09, 2017

In reply to karsten

Permalink

Good, thanks! But it is hidden. I expect it to be at metrics.torproject.org in main menu just after the word "Welcome", where all other links are located. Moreover, it should be in submenu "servers" (it's logical, isn't it?).

March 07, 2017

Permalink

Does Atlas have function search for nodes that most recently joined the network?
I use https://torstatus.blutmagie.de/ that has ability to list nodes by the time they joined the network (first seen) but it is cumbersome.

I use this function to configure Tor to use an exit node that recently joined the network to access websites that ban Tor but are slow at updating their block list.

The data backend used by Atlas does have this capability since version 3.2 ("Extended order parameter to "first_seen" [...]") which was released on January 27, 2017. Want to create an Atlas ticket to make use of that feature somehow, maybe with a suggestion where and how to integrate it?