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


Ticket Summary Keywords Status Milestone
#8742 Byte history leaks information about local usage/hidden services byte-history, stats, tor-hs, privacy, tor-relay, 026-triaged-1, 027-triaged-1-in, PostFreeze027 reopened Tor: unspecified
#12500 Add an option to upload hidden service descriptors some time after startup tor-hs, easy, traffic-analysis, security, reviewer-was-teor-20190422 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
#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 prop224 new 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
#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 UTF-8 tor-hs, prop224, prop285 new Tor: unspecified
#20742 prop224: Implement stealth client authorization prop224, needs-proposal, prop224-extra, tor-hs, client-authorization, stealth-authorization, term-project, 035-removed, hs-auth assigned Tor: unspecified
#21509 Fuzz v3 hidden services fuzz, prop224, tor-hs, 034-triage-20180328, 034-removed-20180328 new Tor: unspecified
#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
#23300 prop224: General client side issues tor-hs, prop224, 034-triage-20180328, 034-removed-20180328 new Tor: unspecified
#23306 hs: Use the state of a directory connection instead of the HAS_FETCHED purpose tor-hs, prop224, 034-triage-20180328, 034-removed-20180328 new Tor: unspecified
#23307 hs: Don't bruteforce every pending connection when we get a RENDEZVOUS ack tor-hs, prop224, 034-triage-20180328, 034-removed-20180328 new Tor: unspecified
#29782 Multiple SocksPort is broken, connects to entry node multiple times. Tor = NSA? CIA, FBI, NSA new

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