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. 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. > * (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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev