Hello, here is the July 2015 report for SponsorR:
- In the beginning of July, we gathered in Washington, DC for a hackfest focused on hidden services. We did lots of work and wrote a blog post about it: https://blog.torproject.org/blog/hidden-service-hackfest-arlington-accords - As part of the hackfest we worked on the various codebase changes that we need to implement proposal 224. We also analyzed and documented how the data structures should be refactored for the next generation hidden services project. https://people.torproject.org/~asn/hs_hackfest_2015/224modules.txt https://people.torproject.org/~dgoulet/hs224-refactor.txt - We also published a report on the introduction point stability statistics we collected during the past months. You can find it here: https://lists.torproject.org/pipermail/tor-dev/2015-July/009109.html - As part of improving and understanding reliability of introduction points, we implemented ticket #4862. As part of that ticket, we disabled the dynamic introduction point formulat that leaked the popularity of busy hidden services. We also implemented #8239 which allows hidden services to reconnect to old introduction points, which should improve the reliability and stability of hidden service. - We further discussed hidden service statistics and how the original hidden service statistics we implemented 6 months ago have been very very useful: https://blog.torproject.org/blog/some-statistics-about-onions To improve the reliability of the statistics (since currently only about 3% of the network reports them), we decided to enable them by default in the future (#15254). We also discussed systems for collecting additional statistics in a privacy-preserving manner, using Secure Multiparty Computation or other similar techniques. - We also took our old design for "Direct Onion Services" and revised it into a faster and far more elegant protocol. These types of services trade service-side location privacy for improved performance, reliability, and scalability. They will allow sites like reddit to offer their services faster on hidden services while respecting their clients anonymity. During the last days of the hackfest, we wrote a draft proposal for this new design: https://gitweb.torproject.org/user/special/torspec.git/log/?h=xxx-direct-onion - Further work was done on onionbalance, the hidden service load balancer. An alpha version of the software was released: https://lists.torproject.org/pipermail/tor-talk/2015-July/038312.html and volunteers have already been testing it in their services: https://lists.torproject.org/pipermail/tor-talk/2015-July/038314.html - We did more development on OnioNS, the Onion Name System, which allows a hidden service operator to register a human memorable name (e.g. example.tor) that can be used instead of the regular onion address. In the last days of the hackfest we prepared a proof-of-concept demo wherein a domain name was registered and then the Tor Browser successfully loaded a hidden service under that name. That was a significant step for the project: https://lists.torproject.org/pipermail/tor-dev/2015-July/009103.html - Further hidden service control commands were added. Ticket #14846 implements a control port command that allows hidden service operators to easily fetch the descriptor of their service.1 _______________________________________________ tor-reports mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-reports
