Sponsor R


September 2014 - August 2017

Some topics we might work on

Hidden service research and development work TBD, but hopefully including:

1) Improve the Tor client software to more reliably reach hidden services to allow more scalable and accurate crawling -- I want to get us to the point where we can hit a Tor client with 100 hidden service socks requests at once and it will handle the reachable ones well and only fail on the ones that are actually unreachable. I'm thinking a good way to get there is to follow the "spin up a local Tor network and do performance and consistency tests" plans (ties in with the upcoming SponsorS work on Tor network testing), and then find and fix HS bugs until everything is reliable.

1b) Better feedback by the Tor client to the controller and/or socks connection about what step went wrong in reaching the hidden service, so we can know whether it's down or just something else went wrong (and if so what).

2) Design and build a hidden-service "health monitoring" service to observe the availability of a hidden service -- something that hits the hidden service periodically, and gathers statistics about consistency, speed, where things fail, etc, and then visualizes the data for the world.

3) Instrument Tor relays to report (perhaps in their extrainfo descs) global HS summary statistics in a way that maintains privacy for both users and services. The hard part here will be figuring out which statistics we want to capture, and convincing ourselves that it's safe and worthwhile to do so.

4) Extend the metrics portal: make the above sanitized data available to the world for research, and visualize and track parts of it for them.

5) Consider the impact of Tor's existing (external) project to redesign hidden services, and adapt our approaches to safely collect aggregate statistics in a sustainable and ongoing way. There's a fine distinction here -- this is not general funding for redesigning hidden services, but it does cover a) design modifications to improve performance or reliability of reaching a hidden service, and b) analyzing our planned redesign to see if it introduces any scary new issues or flaws.

6) Become the expert on all the places on the Internet to discover new .onion addresses (tor2web, ahmia, irc networks, global dns server traffic, twitter feeds, web crawler output, ...)


Year 1 - September 2014 to September 2015

Notes and tasks for Year 1.

Year 2 - September 2015 to September 2016

Notes and task for Year 2

Notes from the mailing list

There was a thread about the SponsorR project in the [tor-dev] mailing list:

In here you can find some ideas that will eventually develop into a tasklist.

Meeting Notes


There has been some discussion to adopt more positive and apt terminology to discuss hidden services. See a current proposal and summary here.



Ticket Summary Keywords Status Owner
No tickets found


Ticket Summary Keywords Status Owner
No tickets found


Ticket Summary Keywords Status Owner
No tickets found


Ticket Summary Keywords Status Owner
No tickets found


Ticket Summary Keywords Status Milestone
#2715 Is rephist-calculated uptime the right metric for HSDir assignment? research, tor-dirauth, research-program new Tor: unspecified
#20371 Lower HSDir query backoff delay tor-hs, research, prop224 new Tor: unspecified


Ticket Summary Keywords Status Milestone
#3733 Tor should abandon rendezvous circuits that cause a client request to time out tor-hs, prop224, tor-client accepted Tor: 0.3.2.x-final
#6418 Drop support for older versions of the hidden service protocol tor-hs technical-debt deprecation new Tor: unspecified
#9001 Slow Guard Discovery of Hidden Services and Clients tor-hs, path-bias, guard-discovery, needs-proposal, mike-can, prop247, tor-guard, 032-unreached new Tor: unspecified
#12424 Implement improved hidden service protocol (prop224) tor-hs, prop224, term-project-ideas accepted Tor: 0.3.2.x-final
#12500 Add an option to upload hidden service descriptors some time after startup tor-hs, easy, traffic-analysis security new Tor: unspecified
#13484 Do we have edge cases with rend_consider_descriptor_republication()? Can we refactor it to be cleaner? tor-hs, prop224 new Tor: unspecified
#14150 Dirauths should expose the value of `MinUptimeHidServDirectoryV2` as a vote flag-threshold tor-hs, prop224, tor-dirauth new Tor: unspecified
#15463 Tor deals poorly with a very large number of incoming connection requests. tor-hs, performance, dos new Tor: unspecified
#15557 Improve relaunch logic for failed rendezvous circuits tor-hs, tor-client, prop224, prop224-extra new Tor: unspecified
#15621 Kill the pre-version 3 intro protocol code with fire. tor-hs technical-debt deprecation accepted Tor: unspecified
#16538 Limit the impact of a malicious HSDir tor-dirauth, tor-hs prop224 new Tor: unspecified
#16966 Better solution for an HS client descriptor cache entry to expire tor-hs, timing, needs-design needs_information Tor: unspecified
#17110 Hardening security - HidServAuth tor-hs hs-ng new Tor: unspecified
#17520 Relax the rend cache failure cleanup timer tor-hs, tor-client, prop224 new Tor: unspecified
#18098 prop224: Implement tor-genkey tool for offline HS key creation tor-hs, prop224-extra new Tor: unspecified
#19162 Make it even harder to become HSDir tor-hs tor-dirauth prop224 security needs-design accepted Tor: unspecified
#19647 HS Descriptors should only contain printable ASCII tor-hs, prop224 new Tor: unspecified
#20699 prop224: Add control port events and commands tor-hs, needs-proposal, prop224-extra, tor-control new Tor: unspecified
#20700 prop224: Implement client authorization prop224, tor-hs assigned Tor: 0.3.3.x-final
#20742 prop224: Implement stealth client authorization prop224, needs-proposal, prop224-extra, tor-hs, client-authorization sealth-authorization, term-project assigned Tor: unspecified
#20961 prop224: Implement consensus params to adjust portion of the protocol tor-hs, prop224, prop224-extra assigned Tor: unspecified
#21509 Fuzz v3 hidden services fuzz, prop224, tor-hs needs_revision Tor: 0.3.2.x-final
#21600 Hidden service introduction point retries occur at 1 second intervals tor-hs, single-onion, prop224 assigned Tor: 0.3.3.x-final
#21621 Intro points can get stuck in CIRCUIT_PURPOSE_S_ESTABLISH_INTRO tor-hs needs_information Tor: 0.3.3.x-final
#21693 prop224: HS descriptors do wasteful double-base64 encoding tor-hs, prop224, 031-stretch assigned Tor: 0.3.3.x-final
#22220 hs: Move cell encoding/decoding out of hs_intropoint.c to hs_cell.c tor-hs, prop224, prop224-extra refactor code-movement new Tor: unspecified
#22810 prop224: Make the client/service extend properly to the IP/RP tor-hs, prop224-extra needs_revision Tor: 0.3.3.x-final
#22893 prop224: Make intro point per-service and not per-descriptor tor-hs, prop224-extra accepted Tor: 0.3.3.x-final
#23107 prop224: Optimize hs_circ_service_get_intro_circ() digest calculation prop224, prop224-extra, tor-hs, optimization, 032-unreached new Tor: unspecified
#23170 Include ed25519 relay id keys in the consensus prop224 tor-dirauth tor-hs ed25519 needs-proposal accepted Tor: 0.3.3.x-final
#23233 Unexpected BUG violation in hsv3 decriptor decoding prop224, easy, tor-hs, 031-backport needs_review Tor: 0.3.0.x-final
#23300 prop224: General client side issues tor-hs, prop224 assigned Tor: 0.3.3.x-final
#23303 hs: Explain why we reset the directory connection timestamp client side tor-hs, prop224 accepted Tor: 0.3.2.x-final
#23306 hs: Use the state of a directory connection instead of the HAS_FETCHED purpose tor-hs, prop224 new Tor: 0.3.3.x-final
#23307 hs: Don't bruteforce every pending connection when we get a RENDEZVOUS ack tor-hs, prop224 new Tor: 0.3.3.x-final

Last modified 2 years ago Last modified on Oct 5, 2015, 2:36:34 PM