StrangeCharm and I just had an interesting conversation about this. In short, while this suggestion would diversify trust it would also reduce the entropy of node selection. Not sure which is more important (I'd suspect the former, but could be argued). Cheers! -Damian<br>
<br>(09:30:17 PM) StrangeCharm: hey<br>(09:31:44 PM) Me: hey there<br>(09:31:57 PM) StrangeCharm: i just read your or-talk posting<br>(09:32:06 PM) Me: ah - thoughts?<br>(09:32:46 PM) StrangeCharm: if we have a small number of really large families, don't the potential anonymity sets get much smaller?<br>
(09:33:29 PM) Me: we already have that situation (say, 500 with comcast, 300 with centurytell, 100 with dreamhost, etc)<br>(09:34:09 PM) Me: if we're worried about relay operators as the point of failure then yes, big networks like this are bad<br>
(09:34:52 PM) StrangeCharm: you're suggesting that we already have these large 'families', over which end-to-end observation is possible, they're just not well marked?<br>(09:34:57 PM) StrangeCharm: (and therefore evaded)<br>
(09:35:04 PM) Me: yup<br>(09:35:55 PM) StrangeCharm: i see.<br>(09:36:56 PM) StrangeCharm: i take it that you'd argue that we should protect against possible surveillance by known groups, whether or not we think it's occurring, even if it has some mild privacy deficits elsewhere?<br>
(09:38:10 PM) Me: don't follow what you mean by mild privacy defects - but yes, tor's designed to distribute trust (ie, that no one in the network can hurt you) and distributing the trust some more is a good thing<br>
(09:38:55 PM) StrangeCharm: well, if we recommend that nobody connects through multiple comcast nodes, the anonymits sets are smaller<br>(09:41:04 PM) Me: Hmmm, I see what you mean - yea, you might have a point (though I think we're we're more interested in diversified trust than greater entropy of node selection). We'll see what the tor devs think.<br>
(09:41:30 PM) StrangeCharm: they tend to have good intuitions about these sorts of things<br>(09:41:36 PM) Me: Mind if I post this conversation on the thread? It brings up a good point.<br>(09:41:47 PM) StrangeCharm: go right ahead<br>
(09:41:49 PM) Me: thx<br><br><div class="gmail_quote">On Wed, Mar 10, 2010 at 9:24 PM, Damian Johnson <span dir="ltr"><<a href="mailto:atagar1@gmail.com">atagar1@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
While I understand your concern I disagree since we're already in this boat. I'm currently running a relay with Comcast as my ISP, and if I was going to run an exit I'd go back to the past list correspondence about low-hassle (tor friendly) hosting solutions. In both cases my ISP or hosting provider are seeing the traffic of hundreds of tor relays. They're the points of potential mass data aggregation we should be concerned about for this sort of large scale eavesdropping, not necessarily the relay's operators.<br>
<br>Hence, as long as any hosting entity properly set the 'Family' parameter, I think we should welcome this sort of hired-relay-operation. The proper countermeasure for this problem (imho) would be to grant relays an implied family based on geoip data and known ISP/hoster ip ranges (ie, don't make my circuit through multiple relays hosted by Comcast or, say, in the US).<br>
<br>Just my two cents... cheers! -Damian<div><div></div><div class="h5"><br><br><div class="gmail_quote">On Wed, Mar 10, 2010 at 8:41 AM, Andrew Lewman <span dir="ltr"><<a href="mailto:andrew@torproject.org" target="_blank">andrew@torproject.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Wed, 10 Mar 2010 11:26:00 +0100, Paul Menzel<br>
<<a href="mailto:paulepanter@users.sourceforge.net" target="_blank">paulepanter@users.sourceforge.net</a>> wrote:<br>
<br>
:on the Tor start page [1] there is a message »Help us reach 5,000<br>
: relays in 2010!«<br>
:»I guess for people caring about privacy but not wanting/able to set up<br>
<div>:a server themselves can now be told, you can pay 90 pounds a month [for<br>
:10 Mbps] and you will improve the connectivity of the Tor network.« [me<br>
:on IRC]<br>
<br>
</div>We turn down funding when organizations ask us to run relays on their<br>
behalf. They have the money, but not the technical skills to run<br>
relays. The risk to The Tor Project, the non-profit entity, is that we<br>
become a target as we could potentially see a large percentage of Tor<br>
network traffic. This traffic becomes interesting to law enforcement,<br>
criminal organizations, marketers, and others wanting to enumerate Tor<br>
users.<br>
<br>
This same concern is true for the funding organization. A human rights<br>
organization wanted to run either hundreds of relays or to see their<br>
relay names as the top 10 relays in the Vidalia network map for a<br>
year. They almost looked at the network map/relay list as a branding<br>
opportunity. However, controlling relays with that much traffic, even<br>
if the relays are dispersed around the world, would turn them into a<br>
data collection target.<br>
<br>
I encourage a peer to peer model of getting more relays. Having<br>
individuals run a relay and contribute the bandwidth that makes sense<br>
seems to be a less risky model. As the risk is spread out amongst<br>
hundreds or thousands of individuals. This is a more difficult path<br>
than turning lots of money into relays. Ultimately, I believe this<br>
path is more sustainable in the long-term. As committed relay<br>
operators run them for their own reasons, not for a paycheck.<br>
<br>
Active areas of research are around "everyone as a bridge" and "everyone<br>
as a relay" if the tor client finds itself reachable by the outside<br>
world. Getting these options correct without screwing users is<br>
difficult. However, we are making progress.<br>
<br>
In the meanwhile, we need more relays, in particular exit relays, to<br>
help speed up Tor for everyone.<br>
<br>
--<br>
Andrew Lewman<br>
The Tor Project<br>
pgp 0x31B0974B<br>
<br>
Website: <a href="https://www.torproject.org/" target="_blank">https://www.torproject.org/</a><br>
Blog: <a href="https://blog.torproject.org/" target="_blank">https://blog.torproject.org/</a><br>
Identi.ca: torproject<br>
***********************************************************************<br>
To unsubscribe, send an e-mail to <a href="mailto:majordomo@torproject.org" target="_blank">majordomo@torproject.org</a> with<br>
unsubscribe or-talk in the body. <a href="http://archives.seul.org/or/talk/" target="_blank">http://archives.seul.org/or/talk/</a><br>
</blockquote></div><br>
</div></div></blockquote></div><br>