[RFC] Campaign »Buy/Sponsor a relay.«
Dear Tor folks, on the Tor start page [1] there is a message »Help us reach 5,000 relays in 2010!« On IRC arma discovered an offer by the British ISP Coldbot where you can buy 1 Mb/s bandwidth for £9 per month [2]. Although it is quite pricey I find the idea very nice. »I guess for people caring about privacy but not wanting/able to set up a server themselves can now be told, you can pay 90 pounds a month [for 10 Mbps] and you will improve the connectivity of the Tor network.« [me on IRC] I suggested to contact ISPs for special rates, but arma and Sebastian pointed out that only getting relays from one ISP would hurt Tor security-wise. So different ISPs world-wide should be contacted. So what do you think about this campaign? I guess the first question is, have you ever been in this kind of situation where people asked you on how to support the Tor project. The second question is, is donating [3] working out quite well, i. e. are a lot of people donating? Would a »Sponsor a relay.« campaign hurt these fund raising efforts? Thanks, Paul [1] http://www.torproject.org/ [2] http://coldbot.com/price/tor [3] http://www.torproject.org/donate signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Drop Tor users via bridges by over 2/3 in the beginning of March (was: Tor in China)
Am Mittwoch, den 10.03.2010, 13:27 +0100 schrieb Karsten Loesing: […] I figured out the problem. The metrics portal had the bridge user numbers from 2009-11-30 to 2010-01-05 imported twice. This affected all countries, but was simply most visible for Chinese bridge users. I removed those days from the stats and imported the descriptors again. The corrected graphs can be found on the graphs page: http://metrics.torproject.org/bridge-users-graphs.html#china So my next question is, why did the users count drop that much in the beginning of March? […] Thanks, Paul signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Drop Tor users via bridges by over 2/3 in the beginning of March (was: Tor in China)
On 10 March 2010 07:42, Paul Menzel paulepan...@users.sourceforge.netwrote: So my next question is, why did the users count drop that much in the beginning of March? At the beginning of March, the great firewall of China blocked all (then) known tor exits and relays, and a substantial number of bridges - presumably enumerated over a prior, somewhat extended period.
Re: Drop Tor users via bridges by over 2/3 in the beginning of March (was: Tor in China)
On Wed, 10 Mar 2010 08:31:06 -0500, Flamsmark flamsm...@gmail.com wrote: :At the beginning of March, the great firewall of China blocked all (then) :known tor exits and relays, and a substantial number of bridges - presumably :enumerated over a prior, somewhat extended period. This is our working theory as well. Pending research involves which set of bridges were blocked; website, email, twitter/qq account, or all of them. -- Andrew Lewman The Tor Project pgp 0x31B0974B Website: https://www.torproject.org/ Blog: https://blog.torproject.org/ Identi.ca: torproject *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Drop Tor users via bridges by over 2/3 in the beginning of March
On 3/10/10 5:20 PM, Andrew Lewman wrote: On Wed, 10 Mar 2010 08:31:06 -0500, Flamsmark flamsm...@gmail.com wrote: :At the beginning of March, the great firewall of China blocked all (then) :known tor exits and relays, and a substantial number of bridges - presumably :enumerated over a prior, somewhat extended period. This is our working theory as well. Pending research involves which set of bridges were blocked; website, email, twitter/qq account, or all of them. No obvious problems with the measurements or presentation, so these numbers are probably real. --Karsten *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [RFC] Campaign »Buy/Sponsor a relay.«
On Wed, 10 Mar 2010 11:26:00 +0100, Paul Menzel paulepan...@users.sourceforge.net wrote: :on the Tor start page [1] there is a message »Help us reach 5,000 : relays in 2010!« :»I guess for people caring about privacy but not wanting/able to set up :a server themselves can now be told, you can pay 90 pounds a month [for :10 Mbps] and you will improve the connectivity of the Tor network.« [me :on IRC] We turn down funding when organizations ask us to run relays on their behalf. They have the money, but not the technical skills to run relays. The risk to The Tor Project, the non-profit entity, is that we become a target as we could potentially see a large percentage of Tor network traffic. This traffic becomes interesting to law enforcement, criminal organizations, marketers, and others wanting to enumerate Tor users. This same concern is true for the funding organization. A human rights organization wanted to run either hundreds of relays or to see their relay names as the top 10 relays in the Vidalia network map for a year. They almost looked at the network map/relay list as a branding opportunity. However, controlling relays with that much traffic, even if the relays are dispersed around the world, would turn them into a data collection target. I encourage a peer to peer model of getting more relays. Having individuals run a relay and contribute the bandwidth that makes sense seems to be a less risky model. As the risk is spread out amongst hundreds or thousands of individuals. This is a more difficult path than turning lots of money into relays. Ultimately, I believe this path is more sustainable in the long-term. As committed relay operators run them for their own reasons, not for a paycheck. Active areas of research are around everyone as a bridge and everyone as a relay if the tor client finds itself reachable by the outside world. Getting these options correct without screwing users is difficult. However, we are making progress. In the meanwhile, we need more relays, in particular exit relays, to help speed up Tor for everyone. -- Andrew Lewman The Tor Project pgp 0x31B0974B Website: https://www.torproject.org/ Blog: https://blog.torproject.org/ Identi.ca: torproject *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [RFC] Campaign »Buy/Sponsor a relay.«
Hello peoples, For my part i am on searching where rent a server for a nicely price to can make again stats on a exit for helping Tor. So any interessant propositions are welcome. As i will offer a constant stats for Karsten and offer a clean exit who are always good to have. Any propostions welcome Best regards SwissTorExit signature.asc Description: This is a digitally signed message part.
Re: tor 0.2.1.24 crashes on Sparc-Solaris10
Am Dienstag 09 März 2010 schrieb Roger Dingledine:
On Tue, Mar 09, 2010 at 08:23:30PM +0100, thomas.hluch...@netcologne.de wrote:
When starting tor it comes up but crashes within one minute.
Try these:
http://freehaven.net/~arma/tor-0.2.1.24-dev.tar.gz
http://freehaven.net/~arma/tor-0.2.1.24-dev.tar.gz.asc
Unfortunately this didnt help. But I succeeded in another way meanwhile:
The crashing tor executables were built with gcc. The one who works right now,
is from Your dev tarball, but built with Suns cc plus an interesting CFLAG. I
found some info in the net
(http://developers.sun.com/solaris/articles/manage_core_dump.html):
The Sun Studio C/C++ compiler has the -xmemalign option, which can be used to
adjust the behavior of the UltraSPARC CPU when there are unaligned memory
addresses that can be determined at compile time. The -xmemalign option causes
the compiler to generate additional load/store instructions for unaligned
memory access. However, the -xmemalign option cannot handle unaligned memory
access during runtime. If unaligned memory access happens during runtime, the
developer needs to change the source code.
So I did:
make distclean
export CC=cc
export CFLAGS='-xmemalign'
./configure --enable-threads --prefix=/usr --sysconfdir=/etc
--with-ssl-dir=/usr/local/ssl
/usr/local/bin/make -j 2
here I got some very unusual output:
source='directory.c' object='directory.o' libtool=no \
DEPDIR=.deps depmode=none /bin/bash ../../depcomp \
cc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR=\/usr/share\
-DLOCALSTATEDIR=\/usr/var\ -DBINDIR=\/usr/bin\ -I../../src/common
-I/usr/local/ssl/include -xmemalign -g -O -c directory.c
directory.c, line 3231: warning: statement not reached
source='dirserv.c' object='dirserv.o' libtool=no \
DEPDIR=.deps depmode=none /bin/bash ../../depcomp \
cc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR=\/usr/share\
-DLOCALSTATEDIR=\/usr/var\ -DBINDIR=\/usr/bin\ -I../../src/common
-I/usr/local/ssl/include -xmemalign -g -O -c dirserv.c
dirserv.c, line 747: warning: identifier redeclared: dirserv_add_extrainfo
current : function(pointer to struct extrainfo_t {struct
signed_descriptor_t {..} cache_info, array[20] of char nickname, unsigned int
bad_sig :1, pointer to char pending_sig, unsigned int pending_sig_len}, pointer
to pointer to const char) returning enum was_router_added_t
{ROUTER_AUTHDIR_REJECTS(-5), ROUTER_NOT_IN_CONSENSUS_OR_NETWORKSTATUS(-4),
ROUTER_NOT_IN_CONSENSUS(-3), ROUTER_WAS_NOT_NEW(-2), ROUTER_BAD_EI(-1),
ROUTER_ADDED_NOTIFY_GENERATOR(0), ROUTER_ADDED_SUCCESSFULLY(1)}
previous: function(pointer to struct extrainfo_t {struct
signed_descriptor_t {..} cache_info, array[20] of char nickname, unsigned int
bad_sig :1, pointer to char pending_sig, unsigned int pending_sig_len}, pointer
to pointer to const char) returning int : dirserv.c, line 64
dirserv.c, line 3254: warning: static function called but not defined:
dirserv_add_extrainfo()
Might this be the reason why a gcc built crashes on Solaris? The executable was
created and runs now without crashing:-)
Thomas
signature.asc
Description: This is a digitally signed message part.
Re: tor 0.2.1.24 crashes on Sparc-Solaris10
On Wed, Mar 10, 2010 at 3:47 PM, thomas.hluch...@netcologne.de wrote: Am Dienstag 09 März 2010 schrieb Roger Dingledine: On Tue, Mar 09, 2010 at 08:23:30PM +0100, thomas.hluch...@netcologne.de wrote: When starting tor it comes up but crashes within one minute. Try these: http://freehaven.net/~arma/tor-0.2.1.24-dev.tar.gz http://freehaven.net/~arma/tor-0.2.1.24-dev.tar.gz.asc Unfortunately this didnt help. But I succeeded in another way meanwhile: The crashing tor executables were built with gcc. The one who works right now, is from Your dev tarball, but built with Suns cc plus an interesting CFLAG. I found some info in the net (http://developers.sun.com/solaris/articles/manage_core_dump.html): The Sun Studio C/C++ compiler has the -xmemalign option, which can be used to adjust the behavior of the UltraSPARC CPU when there are unaligned memory addresses that can be determined at compile time. The -xmemalign option causes the compiler to generate additional load/store instructions for unaligned memory access. However, the -xmemalign option cannot handle unaligned memory access during runtime. If unaligned memory access happens during runtime, the developer needs to change the source code. It would still help a lot if you could get a stack trace to find out where the unaligned memory access happens. We try to only do aligned memory access in our code; if there's somewhere where we're doing unaligned access, I want to find it and fix it. yrs, -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [RFC] Campaign »Buy/Sponsor a relay.«
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. 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). Just my two cents... cheers! -Damian On Wed, Mar 10, 2010 at 8:41 AM, Andrew Lewman and...@torproject.orgwrote: On Wed, 10 Mar 2010 11:26:00 +0100, Paul Menzel paulepan...@users.sourceforge.net wrote: :on the Tor start page [1] there is a message »Help us reach 5,000 : relays in 2010!« :»I guess for people caring about privacy but not wanting/able to set up :a server themselves can now be told, you can pay 90 pounds a month [for :10 Mbps] and you will improve the connectivity of the Tor network.« [me :on IRC] We turn down funding when organizations ask us to run relays on their behalf. They have the money, but not the technical skills to run relays. The risk to The Tor Project, the non-profit entity, is that we become a target as we could potentially see a large percentage of Tor network traffic. This traffic becomes interesting to law enforcement, criminal organizations, marketers, and others wanting to enumerate Tor users. This same concern is true for the funding organization. A human rights organization wanted to run either hundreds of relays or to see their relay names as the top 10 relays in the Vidalia network map for a year. They almost looked at the network map/relay list as a branding opportunity. However, controlling relays with that much traffic, even if the relays are dispersed around the world, would turn them into a data collection target. I encourage a peer to peer model of getting more relays. Having individuals run a relay and contribute the bandwidth that makes sense seems to be a less risky model. As the risk is spread out amongst hundreds or thousands of individuals. This is a more difficult path than turning lots of money into relays. Ultimately, I believe this path is more sustainable in the long-term. As committed relay operators run them for their own reasons, not for a paycheck. Active areas of research are around everyone as a bridge and everyone as a relay if the tor client finds itself reachable by the outside world. Getting these options correct without screwing users is difficult. However, we are making progress. In the meanwhile, we need more relays, in particular exit relays, to help speed up Tor for everyone. -- Andrew Lewman The Tor Project pgp 0x31B0974B Website: https://www.torproject.org/ Blog: https://blog.torproject.org/ Identi.ca: torproject *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [RFC] Campaign »Buy/Sponsor a relay.«
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 (09:30:17 PM) StrangeCharm: hey (09:31:44 PM) Me: hey there (09:31:57 PM) StrangeCharm: i just read your or-talk posting (09:32:06 PM) Me: ah - thoughts? (09:32:46 PM) StrangeCharm: if we have a small number of really large families, don't the potential anonymity sets get much smaller? (09:33:29 PM) Me: we already have that situation (say, 500 with comcast, 300 with centurytell, 100 with dreamhost, etc) (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 (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? (09:34:57 PM) StrangeCharm: (and therefore evaded) (09:35:04 PM) Me: yup (09:35:55 PM) StrangeCharm: i see. (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? (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 (09:38:55 PM) StrangeCharm: well, if we recommend that nobody connects through multiple comcast nodes, the anonymits sets are smaller (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. (09:41:30 PM) StrangeCharm: they tend to have good intuitions about these sorts of things (09:41:36 PM) Me: Mind if I post this conversation on the thread? It brings up a good point. (09:41:47 PM) StrangeCharm: go right ahead (09:41:49 PM) Me: thx On Wed, Mar 10, 2010 at 9:24 PM, Damian Johnson atag...@gmail.com wrote: 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. 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). Just my two cents... cheers! -Damian On Wed, Mar 10, 2010 at 8:41 AM, Andrew Lewman and...@torproject.orgwrote: On Wed, 10 Mar 2010 11:26:00 +0100, Paul Menzel paulepan...@users.sourceforge.net wrote: :on the Tor start page [1] there is a message »Help us reach 5,000 : relays in 2010!« :»I guess for people caring about privacy but not wanting/able to set up :a server themselves can now be told, you can pay 90 pounds a month [for :10 Mbps] and you will improve the connectivity of the Tor network.« [me :on IRC] We turn down funding when organizations ask us to run relays on their behalf. They have the money, but not the technical skills to run relays. The risk to The Tor Project, the non-profit entity, is that we become a target as we could potentially see a large percentage of Tor network traffic. This traffic becomes interesting to law enforcement, criminal organizations, marketers, and others wanting to enumerate Tor users. This same concern is true for the funding organization. A human rights organization wanted to run either hundreds of relays or to see their relay names as the top 10 relays in the Vidalia network map for a year. They almost looked at the network map/relay list as a branding opportunity. However, controlling relays with that much traffic, even if the relays are dispersed around the world, would turn them into a data collection target. I encourage a peer to peer model of getting more relays. Having individuals run a relay and contribute the bandwidth that makes sense seems to be a less risky model. As the risk is spread out amongst hundreds or thousands of individuals. This is a more difficult path than turning lots of money into relays. Ultimately, I believe this path is more sustainable in the long-term. As committed relay operators run them for their own reasons, not for a paycheck. Active areas of research are
Re: [RFC] Campaign »Buy/S ponsor a relay.«
On Wed, Mar 10, 2010 at 09:24:54PM -0800, atag...@gmail.com wrote 8.3K bytes in 180 lines about: : 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). Yes, and there's some research into Autonomous System (AS) level routing and aggregation concerns. This whole sponsor a relay concept has come up internally in the past. The idea is based on the assumption that there are organizations with more money then technical skill willing to fund someone to run a relay for some defined period of time, bandwidth, etc. I'm not sure this is true at this point in time. However, this doesn't mean that starting a marketplace or exchange where people with some money can meet people with technical skill in operating a relay is a bad idea. It's a fine experiment to learn about the demand from both ends, and figure out what the market would decide on pricing for slow/fast relays, non-exit/exit relays, branded/Unnamed relays, and reliability and uptime. Of course, this could also introduce some interesting incentives to cheat. Coldbot in the UK is the first such market. I wonder if they'll share how it is going so far. -- Andrew Lewman The Tor Project pgp 0x31B0974B Website: https://www.torproject.org/ Blog: https://blog.torproject.org/ Identi.ca: torproject *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
