We Enhanced the Security and Integrity of Tor Metrics, Supported by MOSS

 

With the generous support of Mozilla's Open Source Support (MOSS) program's Mission Partners track, the Tor Metrics team has spent the last 12 months making improvements to your one-stop shop for Tor data.

As we noted in a blogpost announcing the award last June, Tor Metrics faces an interesting challenge: how can an anonymity network gather information on its users? It has to be done in a way that’s privacy-preserving and not in a way that puts users at risk.

The MOSS award allowed the team to make several improvements to the security and the integrity of Tor Metrics. In fact, this grant allowed Tor Metrics to become a team, expanding beyond one full-time developer. We made a large number of infrastructure improvements to the Tor Metrics code base, including refactoring the code and adding more tests. In short, this MOSS award made Tor Metrics more mature and gave it the foundation with which to scale.

Tor Metrics Website Redesign

Some of the things the MOSS award allowed us to do:

  • Develop and strengthen the infrastructure related to data collection, performance measurement, and network status monitoring. Add a feature to synchronize data between CollecTor instances.

  • Analyze and publish a report on the security of our metrics and the amount of sensitive, personally identifying data we store, and identify further improvements.

  • Improve the accuracy and depth of performance measurements by adding new onion server measurements.

  • Redesign the Tor Metrics website, making it easier to find, compare, and interpret Tor usage and performance metrics, as well as by expanding existing measurements.

For more details, download the PDF of our full report. If you’d like to get involved with Tor Metrics, check out the wiki to see how.

Mozilla Logo

The work carried out under this MOSS award couldn’t have happened without the support of many teams at Tor and anonymous volunteer cypherpunks.

Mozilla's mission is to ensure the Internet is a global public resource, open and accessible to all. Mozilla Open Source Support is an awards program specifically focused on supporting the Open Source and Free Software movement. Their Mission Partners track is open to any open-source or free software project undertaking an activity which significantly furthers Mozilla's mission. Tor appreciates their support.

Anonymous

August 03, 2017

Permalink

I don't see this as been a good thing , how is it good me , if there are only 20 people that use my config 'say tor + plugin' in my country and you publish it ? OPSEC Fail ?

You don't see what as a good thing? Having more people have time to think about our metrics infrastructure, and making it scale, and be better documented about what exactly it publishes? I think "this" is pretty clearly a good thing.

Unless you meant you don't see the whole concept of trying to safely measure Tor's progress as being a good thing. I suggest you read one of our early papers on the topic, published at the "Workshop on Ethics in Computer Security Research":
https://www.freehaven.net/anonbib/#wecsr10measuring-tor
And you're right that publishing anything precise about a situation where only 20 people have some configuration would be a poor choice. That's why we try not to do things like that -- and that's why we are pleased to have had some funding from Mozilla so we can spend time making sure we're not doing things like that.

Hope this helps. :)

Anonymous

August 04, 2017

Permalink

Great work as always and thanks too Mozilla for the support!

I read somewhere that there was going to be more private stats incorporated into Tor? Is that right?

Anonymous

August 04, 2017

Permalink

1- Is an attacker ( hacker, CIA, governement ... ) able to use this data to compromise a targeted user or Tor network?
2- Tor ( not Tor-Browser-bundle ) collects any data?

Re 1, the whole goal is that the answer should be no. As an example, if you have a data set and you're pondering whether it's safe to publish, consider some hypothetical other party out there that has some other data set, and ask yourself if it's possible that they would learn too much if they combined their hypothetical data set with yours. If the answer is yes, don't publish, or even better, don't collect your data set in the first place.

For more on this topic of minimization, check out
https://research.torproject.org/safetyboard.html#guidelines

Re 2, Tor Browser doesn't collect any statistics. It's only the relays that collect anonymized, aggregated statistics, and publish them to the world in their "extra-info" descriptors. You can see it all here:
https://collector.torproject.org/recent/relay-descriptors/extra-infos/

Anonymous

August 04, 2017

Permalink

> It has to be done in a way that’s privacy-preserving and not in a way that puts users at risk.
Is the Tor Project able to put users at risk at all then?

Anonymous

August 04, 2017

Permalink

Great Work! Does somebody know when and if data regarding the new onion services (proposal 224) will be measured?

I would guess that we'll stick to just the current two that we collect:
https://metrics.torproject.org/hidserv-dir-onions-seen.html
But you're right, we might want to start distinguishing between "old style" and "new style" addresses, for the onion address count. (For the "onion traffic" count, I think the relays that collect those stats are not able to distinguish whether they're carrying traffic for legacy onion services or 224-style onion services.)

Anonymous

August 06, 2017

Permalink

sedyBRNEF : 1,676 bytes this file appeared this day when i launched Tort clicking on the icon ; is it a bug, a survey, or a compromised relay ?
is it related at Tor Metrics ?
(first time i saw that !)

Anonymous

August 07, 2017

Permalink

Why no pictures appear in facebook account when connect to facebookcorewwwi.onion site? The image placeholder only appears instead with text "image may contain:..."
It's just a Facebook site problem only. Other sites are OK in Tor.

Anonymous

August 07, 2017

Permalink

Debian 9.1 stable : linux x86_64 & Tor 7.0.3 (clean, updated, checked, verified & sound/camera off etc.)

it is really in the folder tor-browser_en-US : it is related to Tor.
sedyBRNEF appears between the folder Browser & the launcher Tor Browser.

- can't open the file (no app for that).
- reloading the folder or the tor page has had no effect.

if it is not a metrics thing it could be a Tor bug : "a Tor unknown file ?" _ bizarre.
where could i send a copy of this file if it appears again ?
bug-report ?
what is the signification of sedyBRNEF ?

Torsandbox runs using the terminal so i cannot know if there is interference with Tor browser & if there are 'linked': this "Tor unknown file ?" should look like a leak in this case.

Easter-egg ? i do not thing so, could be the trace of an infiltration/connection test ?
thanks you for your response arma.