On 05 Sep (14:47:41), Mike Perry wrote: > Yawning Angel: > > On Fri, 4 Sep 2015 15:31:15 -0600 > > John Brooks <john.brooks@xxxxxxxxxxxxxxxx> wrote: > > > > > > Have you considered all the implications? > > > > > > Maybe weâve missed some - what implications are you thinking of, that > > > arenât addressed in the proposal? > > > > I have two objections to this, one political, one technical: > > > > * (The political objection) While this is "cool" and probably(?) > > "funded", it seems like a poor thing to work on in terms of > > developmental priority when there are other things Hidden Service > > related that need a lot of developer attention, primarily in making > > the existing HSes more resilient against Nation State level > > adversaries (Eg: Prop. 224). > > We should definitely have a Tor roadmapping session at the dev meeting > to cover this and related concerns. +9000 > > I too have been worrying about the drift between what we suspect are the > most serious problems in the hidden service protocol (and the Tor > protocol in general) and the current set of Tor deliverables and dev > plans (or lack thereof). > > OTOH, in order to make proper roadmapping, priority, and work-ordering > decisions, we really do need a good menu of well-written proposals > and/or tickets to choose from, even if we're likely to decide some of > them are simply not worth doing yet until other issues are solved first. > > Otherwise roadmapping will become a bunch of hand-wavy statements about > "Well, what about trying to solve $ISSUE_X $SOMEHOW?" without the > ability to weigh the efficacy of a specific solution and how its > development effort compares to (or depends upon) the gains from other > potential improvements. Last hidden service meeting in July, we were able to come up with a breakdown of components for 224. See the blog post we did a month ago: https://blog.torproject.org/blog/hidden-service-hackfest-arlington-accords More specifically: Splitting 224 into "modules": https://people.torproject.org/~asn/hs_hackfest_2015/224modules.txt and: Needed code refactor: https://people.torproject.org/~dgoulet/hs224-refactor.txt This is clearly not as organised as it could be but I think it's a good base from which we start on; If the modules above make sense, having a ticket (or a family of tickets) for them and proposals (if applicable) is definitely a way to go forward that I agree on. Good example, proposal #250. Let's have a session for that in Berlin for sure! Ideally, having an agenda before we start would be fantastic. I'll try to start tomorrow a wiki page about it and we can start from there until Berlin. Thanks! David > > > * (The technical objection) It is overly easy for assholes[0] to censor > > Single Onion Services due to: > > > > itâs possible for the previous relay to guess the service youâre > > connecting to > > > > While such a censor would only be able to deny service to clients as > > a fraction of their relay(s) consensus weight, it's still something > > that probably should get consideration. > > In addition to this concern, I am also wondering about the second-order > effects of what happens when we have two classes of internal services: > the "boring" ones that don't use the full rend protocol, and the > "interesting" ones that do, especially if we still have not solved the > circuit setup fingerprinting problem to prevent an observer from easily > differentiating the two before this (or a similar mechanism) is deployed. > > > -- > Mike Perry > _______________________________________________ > tor-dev mailing list > tor-dev@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev