> Like Tails' friends, foes, and neutral HTP pools… > "any member in a one pool should be unlikely to share logs (or other identifying data), > or to agree to send fake time information, with a member from the the other pools"
This may be heretical, but I always thought this motivation above is a plausible reason to have more "non-activist" types running Tor relays---we just have too many friends, a few foes would be a welcome addition! -V On Wed, Oct 28, 2015 at 1:11 PM Tim Wilson-Brown - teor <[email protected]> wrote: > > > On 28 Oct 2015, at 14:31, Virgil Griffith <[email protected]> wrote: > > > > Instead of WOT, it seems more desirable, and better fit diversity, to > have both your best friends and worst enemies on the same circuit. Ergo, > minimizing chance of collaboration. > > Like Tails' friends, foes, and neutral HTP pools… > "any member in a one pool should be unlikely to share logs (or other > identifying data), or to agree to send fake time information, with a member > from the the other pools" > https://tails.boum.org/contribute/design/Time_syncing/#index4h2 < > https://tails.boum.org/contribute/design/Time_syncing/#index4h2> > > T > > > > > -V > > On Mon, 26 Oct 2015 at 01:30 grarpamp <[email protected] <mailto: > [email protected]>> wrote: > > On Wed, Sep 23, 2015 at 8:44 AM, tor-dev had: > > > I agree with Roger that ideally all relays can be exits (and since > > > we're being ideal, we'll assume that 'exit' means to every port). And > > > the network location distribution of relays by bandwidth is > > > proportional to both the client destination selection over time and > > > general Internet traffic over time, which match each other since we're > > > being ideal, and also matter since we're using an ideal trust-aware > path > > > selection algorithm. And network wide route selection is such that > > > there is no congestion (generalizing Roger's assumption of infinite > > > exit capacity). > > > > Guessing that... assuming you can ship and calculate all the relay > > data / DHT / weights / KEX / circuits / preferences without > > bogging down your network or cpu... > > > > More relays being exits yields higher maximum possible path diversity. > > More relays being exits yields higher potential aggregate throughput > > between the network and clearnet. > > More exits yields broader more complete location overlay relavent to > > users (more relays yields more guards), datacenteres, and clearnet > > services (though there's as yet no attempt to exit near a service > > unless done manually). > > > > However when subject to global passive adversary tapping > > lots of the fiber, and you turn up more relays as exits (which > > are also non-exit relays by nature), you're adding lots more > > unused bandwidth over the same current consumption, leading > > to lots of unused quiet portions of the network. > > Which seems a greater potential for the adversary to "look, user > > just shot a unique traffic pattern completely through the quiet > > zone, gotcha". > > Whereas when the network links are full with clocked traffic > > (and fill traffic if there would otherwise be slack space) that > > observation attack is hardly as possible, to relavently impossible. > > > > If true, it seems to me adding more [non] exits should be pegged to > > some metrics and solicited on need / planning rather than turning > > up 6000 exits all at once. > > > > > In our ongoing work on trust-aware path selection, we assume a trust > > > distribution that will be the default used by a Tor client if another > > > distribution is not specified. (Most users will not have a reasoned > > > understanding of who they actually need to worry most about, and even > > > if they somehow got that right would not have a good handle how that > > > adversary's resources are distributed.) We call this adversary "The > > > Man", who is equally likely to be everywhere (each AS) on the > > > network. For relay adversaries, we assume that standing up and running > > > a relay has costs so weight a bit to make relays that have been around > > > a long time slightly more likely to be trusted. > > > > tor-relays had talk of individual humans keyparty signing their relays > > and including that WOT along with other trust and meta metrics > > in the consensus or other queryable datastore that could be used > > by the user to select preferred relay sets in whichever sensible or > > silly ways suited them. > > > > An adversary standing up relays has costs. > > Adversaries standing their human agents in public, even if > > their undercover is maintained, has additional costs and risks. > > > > > You > > > would then be faced with the political nightmare of issuing default > > > policies that tells users they should route with a weighting that says > > > country foo has an x percent chance of being your adversary, but > > > country bar has a y percent chance. (Likewise also have similar > > > statements that substitute 'large multinational corp.', 'major > > > criminal organization', 'specific big government agency that is > > > getting all the press lately' etc. for "country" in the last > > > sentence.) > > > > ======== > > In a sense this is like the original 'valid' flag, which you got > > by mailing me and having me manually approve your relay (and without > > which you would never be used as the entry or exit point in a circuit). > > Periodically I wonder if we should go back to a design like that, where > > users won't pick exit relays that don't have the "socially connected" > > badge. Then I opt against wanting it, since I worry that we'd lose > > exactly the kind of diversity we need most, by cutting out the relays > > whose operators we don't know. > > > > But both sides of that are just guessing. Let's find out! > > ======== > > > > > > These type of things may be better suited to a system > > where the users contribute their research and knowledge > > about the network into the network metadata db, and the > > users can query it to make their own decisions, follow > > other users prebuilt selection templates, or stick > > with the provided defaults. > > _______________________________________________ > > tor-dev mailing list > > [email protected] <mailto:[email protected]> > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev < > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev> > > _______________________________________________ > > tor-dev mailing list > > [email protected] > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > Tim Wilson-Brown (teor) > > teor2345 at gmail dot com > PGP 968F094B > > teor at blah dot im > OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F > > -- > tor-talk mailing list - [email protected] > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > -- tor-talk mailing list - [email protected] To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
