Opened 4 years ago

Closed 23 months ago

#15846 closed enhancement (wontfix)

Publish (hashes of) historic Onionoo details documents

Reported by: karsten Owned by: metrics-team
Priority: Medium Milestone:
Component: Metrics/CollecTor Version:
Severity: Normal Keywords: metrics-2017
Cc: tyseom Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Nusenu writes on tor-dev@: "I might want to prove to third parties that I'm indeed processing/providing authentic historic onionoo documents from onionoo.tpo. What do you think of signing them?"

Let's consider signing responses. What would we gain, and how would we do it?


  • We already provide Onionoo via https. I guess including a signature in the response would enable people to archive that signature and verify it later, which is not possible with https. That's what Nusenu has in mind, I think.


  • Signing responses causes some computation overhead, and it makes responses larger.
  • Where in the JSON document would we add the signature? Are there standards for this, and are there tools supporting them that can be found in Debian stable? This is a con, because it's probably non-trivial to do.

Similar to #15845, I'm leading towards no, but maybe I'm overlooking something.

Child Tickets

Change History (6)

comment:1 Changed 4 years ago by tyseom

Cc: tyseom added

comment:2 Changed 4 years ago by cypherpunks

two alternatives to achieve the same goal ([to some degree] verifiable/authentic historic oninoo data) that do not require changes to onionoo's code and are problably rather low effort and have an additional benefit (public archives):

a) publish historic onionoo details documents on collector.tpo (or any other TLS-enabled tpo webserver)
(prefered over option b)

fetch onionoo data via an hourly cronjob, like

/usr/bin/curl -s --compressed localhost/details -o $output
xz $output

Storage requirements for details documents (currently): 27MB/day (complete details documents of one day stored as tar.xz)

That would allow everyone to use and verify (served via ht tps) historic onionoo data.

Since (historic) DNS and AS/GeoIP data is also included this contains more then just descriptor data (in such a case it wouldn't make much sense to re-publish it on collector just in a different format).

  • con: requires ~820MB/month (but storage is cheap these days?)
  • pros:
    • almost no effort to "implement"
    • would ease features like a compass "timemachine" (historic lookups)

b) publish hashes of historic onionoo details documents on collector.tpo

  • pro: requries almost no storage
  • con: depending on what time of the hour the details file has been fetched it might be hard to actually match/reproduce the provided hash even if both files are authentic

comment:3 Changed 23 months ago by karsten

Keywords: metrics-2018 added

comment:4 Changed 23 months ago by karsten

Keywords: metrics-2017 added; metrics-2018 removed

comment:5 Changed 23 months ago by karsten

Owner: set to metrics-team
Status: newassigned

comment:6 Changed 23 months ago by karsten

Component: Metrics/OnionooMetrics/CollecTor
Resolution: wontfix
Severity: Normal
Status: assignedclosed
Summary: Sign responsesPublish (hashes of) historic Onionoo details documents

Updating the summary and component to reflect what this ticket is really about.

However, I’m not convinced that we should create an archive of Onionoo responses. We already keep an archive of the underlying data, which is signed by the relays or directory authorities producing it. The suggested new archive would be mostly redundant, and in some cases it would even be worse: it would start whenever we start fetching Onionoo responses, and it would lack data whenever either Onionoo or the archiver (temporarily) breaks. We should instead work on including more history in Onionoo documents. If others want to create an archive of Onionoo responses, that‘s fine, but this is not something that we should be doing officially.

Closing. Thanks for the suggestion anyway.

Note: See TracTickets for help on using tickets.