Proposal idea: User path configuration
syverson at itd.nrl.navy.mil
Wed Mar 10 15:49:53 UTC 2010
On Wed, Mar 10, 2010 at 10:32:06AM +0100, Christian Fromme wrote:
> On Wed, Mar 10, 2010 at 5:32 AM, Roger Dingledine <arma at mit.edu> wrote:
> > I think we should work out the situations where strictnodes is needed,
> > and the situations where we want to honor the config option even without
> > strictnodes 1.
> > For example, if you set entrynodes or exitnodes, then imo you should get
> > one of the nodes you specified, or fail if none work. You asked for it,
> > you get it. Similarly, if you set Excludenodes or excludeexitnodes, I
> > think that should trump any entrynodes or exitnodes you set. And if you
> > exclude everything that's possible, then you fail to make a circuit. It's
> > what you asked for. That's pretty much what I built in 0.2.2.7-alpha
> > (though I haven't finished the "excluding" part).
> This sounds like we rather want an option "RelaxStrictNodesOnConflict
> 1" for the user to explicitly relax the rules if he knows what he's
> doing. Default should be 0. At least I find that more intuitive.
OK too many layer for me: Do we really now have in any version of
code, spec, or proposal
excludenodes, excludeexitnodes, etc. plus strictnodes plus
relaxstricnodesonconflict as options that can take values or be set?
Woah and Whoa.
I would want the default to be to fail safe without second-guessing
the user. Some of that was reflected in what Roger said, but then he
seemed to take it back in places. By "fail safe" here I mean that if
you say don't go there, then you don't go there no matter what.
Having the default be
seems like really bad semantics to me. It might mean less frequent
shooting oneself in the foot by semicompetents, but it probably also
means more shooting in the foot when it really matters, especially by
someone who (OK failed to RTFM, but) thinks that excludenodes means
exclude nodes, not exclude nodes unless you think it would be better
if I didn't. Something that means what it says without reading the
documentation makes more sense to me.
I know I'm jumping in without looking, so apologies if my suggestions
are obviated by something said earlier/elsewhere but what about having
just strictexcludenodes and preferredexcludenodes or some such (plus
similar for entry and exits)? Strict would trump everything.
preferredexcludenodes would try to follow preferences but would
reflect the best guess reasonable behavior set by the developers as
you have been discussing. There is then no simple excludenodes, people
need to pick one (or possibly both) and then get what they ask for.
I could suggest even more to this but I don't want to get into some
elaborate access control language. I think you were starting down
that road and this is simpler. Please feel free to show me why I'm
being an idiot.
I should admit that I'm also thinking forward to a time when trust is
part of Tor's routing so that we are in no position to claim to know
which nodes are safe for a given client. But I think the points hold
right now as well.
More information about the tor-dev