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