On Sat, Apr 13, 2013 at 6:01 PM, hamahangi <hamaha...@posteo.eu> wrote: > #5903 and #6523. There seems to have been some fiddling with both but no > comments to speak of. Thanks for clearing up the reasoning behind your > decision.
Thanks; I've marked #5903 for 0.2.5 and closed #6523 as a duplicate. That's not a commitment that it will get done in 0.2.5, but I do hope that somebody will give it a try. The tricky parts to get right will be: * Making sure it applies to entry nodes on the codepath where we pick guards at random from all guards, AND on the codepath where we pick guards from configured EntryNodes, AND on the codepath where directory guards are turned off entirely. * Deciding whether it applies to anonymous connections only, or to direct directory requests as well. * Figuring out what should happen when a guard is marked as Excluded, then no longer Excluded. Should do the same as if the guard is excluded with ExcludeNodes, then not? * Figuring out what should happen when the user has no consensus networkstatus document, and they have excluded every authority and directory source that they know about. * Figuring out what should happen if a specified bridge is excluded. * Figuring out what should happen if a bridge is excluded by fingerprint, but we don't learn its fingerprint until after connecting to it. * Refactoring the code and/or adding mocking stubs to the code sufficient for us to have rigorous testing for all of the above. Oh hey, that's a checklist. I've copied it onto #5903. There's enough trickiness here that a design proposal might be in order. > Also a web search for "ExcludeEntryNodes" brought up a preparatory > commit you seem to have made earlier this year > [https://lists.torproject.org/pipermail/tor-commits/2013-February/052377.html]. Whoops! That wasn't a preparatory commit; that was a typo in the documentation, where it should have referred to "ExcludeExitNodes." I've fixed it now; thank you! > I would have thought that the potential importance of the feature here > described in avoiding traffic correlation would outweigh the possible > disadvantage in having it behave unexpectedly, but I can't argue with > your experience. I think that's actually a false dichotomy, and an interesting one. In order to help users get security, an option needs to work in a way that they they expect. Otherwise, when they try to avoid using nodes in one way, and they wind up telling Tor to do something else entirely, they are likely not to get the security properties they thought they were getting by asking for what they thought they were asking for. > Would listing all country codes except the one you wanted to avoid under > 'EntryNodes' do for a temporary workaround? I believe that should work, though it might be somewhat inconvenient. Note that you should probably be using 0.2.4.x-alpha in that case, since I think we fixed some EntryNodes bugs and improved some EntryNodes behavior along the line in the 0.2.4.x series. Assuming you're not disabling guard nodes, you might do as well to pick a half dozen or so countries you like with a bunch of Tor nodes in them, and just list those. I haven't done the math, though; it might not be. > Is there a list of these > that Tor uses, or do I have to enter them manually? (I'm not a > programmer, evidently.) No trouble. I *am* a programmer, and I figure the least I can do here is generate the list for you. I made it with perl -ne 'if (/,([A-Z][A-Z])$/) {print "{\1},\n";}' src/config/geoip |sort | uniq |fmt though there are probably better ways. {AD}, {AE}, {AF}, {AG}, {AI}, {AL}, {AM}, {AO}, {AP}, {AQ}, {AR}, {AS}, {AT}, {AU}, {AW}, {AX}, {AZ}, {BA}, {BB}, {BD}, {BE}, {BF}, {BG}, {BH}, {BI}, {BJ}, {BL}, {BM}, {BN}, {BO}, {BQ}, {BR}, {BS}, {BT}, {BW}, {BY}, {BZ}, {CA}, {CC}, {CD}, {CF}, {CG}, {CH}, {CI}, {CK}, {CL}, {CM}, {CN}, {CO}, {CR}, {CU}, {CV}, {CW}, {CX}, {CY}, {CZ}, {DE}, {DJ}, {DK}, {DM}, {DO}, {DZ}, {EC}, {EE}, {EG}, {EH}, {ER}, {ES}, {ET}, {EU}, {FI}, {FJ}, {FK}, {FM}, {FO}, {FR}, {GA}, {GB}, {GD}, {GE}, {GF}, {GG}, {GH}, {GI}, {GL}, {GM}, {GN}, {GP}, {GQ}, {GR}, {GS}, {GT}, {GU}, {GW}, {GY}, {HK}, {HN}, {HR}, {HT}, {HU}, {ID}, {IE}, {IL}, {IM}, {IN}, {IO}, {IQ}, {IR}, {IS}, {IT}, {JE}, {JM}, {JO}, {JP}, {KE}, {KG}, {KH}, {KI}, {KM}, {KN}, {KP}, {KR}, {KW}, {KY}, {KZ}, {LA}, {LB}, {LC}, {LI}, {LK}, {LR}, {LS}, {LT}, {LU}, {LV}, {LY}, {MA}, {MC}, {MD}, {ME}, {MF}, {MG}, {MH}, {MK}, {ML}, {MM}, {MN}, {MO}, {MP}, {MQ}, {MR}, {MS}, {MT}, {MU}, {MV}, {MW}, {MX}, {MY}, {MZ}, {NA}, {NC}, {NE}, {NF}, {NG}, {NI}, {NL}, {NO}, {NP}, {NR}, {NU}, {NZ}, {OM}, {PA}, {PE}, {PF}, {PG}, {PH}, {PK}, {PL}, {PM}, {PN}, {PR}, {PS}, {PT}, {PW}, {PY}, {QA}, {RE}, {RO}, {RS}, {RU}, {RW}, {SA}, {SB}, {SC}, {SD}, {SE}, {SG}, {SH}, {SI}, {SJ}, {SK}, {SL}, {SM}, {SN}, {SO}, {SR}, {SS}, {ST}, {SV}, {SX}, {SY}, {SZ}, {TC}, {TD}, {TF}, {TG}, {TH}, {TJ}, {TK}, {TL}, {TM}, {TN}, {TO}, {TR}, {TT}, {TV}, {TW}, {TZ}, {UA}, {UG}, {UM}, {US}, {UY}, {UZ}, {VA}, {VC}, {VE}, {VG}, {VI}, {VN}, {VU}, {WF}, {WS}, {YE}, {YT}, {ZA}, {ZM}, {ZW} best wishes, -- Nick _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
