- tor-dev - lists.torproject.org

Re: [tor-dev] [tor-relays] CPU utilization for relay
by Mike Perry 15 Jul '11

15 Jul '11

Thus spake swsnyder(a)snydernet.net (swsnyder(a)snydernet.net) > FYI, this is a profile of my Tor v0.2.2.30-rc relay, taken in a 10-minute sampling: > > CPU: CPU with timer interrupt, speed 0 MHz (estimated) > Profiling through timer interrupt > samples % linenr info symbol name > 3126 29.7290 cast-586.s:9 CAST_encrypt Can you attach gdb to your relay and set a breakpoint for CAST_encrypt? We have no idea why this function should be called at all (unless it is for something like reading keyfiles off disk?) let alone dominate your profile output. gdb -p <tor_pid> (gdb) break CAST_encrypt (gdb) cont You may need to stick a 'file /usr/bin/tor' or similar in there. If you get no hits, try to do it on startup: gdb /usr/bin/tor (gdb) break CAST_encrypt Function "CAST_encrypt" not defined. Make breakpoint pending on future shared library load? (y or [n]) y (gdb) run [<tor args>] If you get any hits, run 'backtrace' and give us the output. You may need to install some debuginfo packages, but gdb should tell you this if so. If anyone playing along at home gets any hits on either of these breakpoints, let us know. > 1677 15.9486 sha256-586.s:8 sha256_block_data_order > 1149 10.9272 aes-586.s:424 _x86_AES_encrypt > 844 8.0266 sha1-586.s:8 sha1_block_data_order > 273 2.5963 crypto.c:1649 crypto_digest_get_digest > 221 2.1018 md32_common.h:283 SHA1_Update > 182 1.7309 encode.c:190 EVP_EncodeBlock > 171 1.6262 OpenBSD_malloc_Linux.c:1793 ifree > 136 1.2934 cast-586.s:379 CAST_decrypt > 130 1.2363 md32_common.h:348 SHA1_Final > 127 1.2078 obj_lib.c:66 OBJ_dup > 122 1.1602 memarea.c:221 memarea_alloc > 110 1.0461 aes-586.s:1610 _x86_AES_decrypt > > After running for 14 hours, the Tor relay has consumed 1.6% of CPU time. It is now using 45MB of RAM, servicing 112 active connections. > > According to http://torstatus.blutmagie.de my Max/Burst/Observed (Bps) bandwidth is: > > 153600 / 307200 / 127170 > > Environment: > > CPU: Pentium-M (Dothan) @ 1.80 GHz > RAM: 1.0 GB DDR1 > Net: Fast Ethernet connected to a Surfboard cable modem > > CentOS v5.6 > Tor v0.2.2.30-rc > libevent 2.0.12-stable > openssl 1.0.0d > zlib 1.2.5 > glibc 2.5-58 > > Just another data point. > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Mike Perry Mad Computer Scientist fscked.org evil labs

1 0

Nick's planned schedule for Tor 0.2.3.x development
by Nick Mathewson 14 Jul '11

14 Jul '11

Hi, all! I'll try to avoid a long-winded mail and instead cut to the chase: I want Tor releases to come out more frequently, and I'm going to plan a release schedule for 0.2.3 to make sure it happens. It's July 2011 now; I want to get 0.2.3.x released in early 2012. To that end, I'm going to declare the following tentative and somewhat arbitrary schedule: December 1, 2011: Big feature freeze. No new features that "feel big" to me get merged into 0.2.3.x after this date, barring exceptional circumstances[*]. January 6, 2012: Feature freeze. Barring exceptional circumstances, no new features get merged to 0.2.3.x after this date, barring exceptional circumstances[*]. Fixes for non-regression bugs (that is, those that also existed in 0.2.2.x) may also get deferred if they aren't too severe. Some time between Jan 6 and Jan 30: we fork off a maint-0.2.3 branch and have master become 0.2.4. When it's ready, 2012: We release 0.2.3.x-rc, see how long everything took us, and adjust our plans or 0.2.4.x. Note that the deadlines above are _merge_ freezes, not _submission_ freezes. If you give me a big patch on Dec 1, and it needs more review or revision than can get done that day, then it needs to wait for 0.2.4. Obviously, this is still up for discussion. But please remember about the bikeshed. Also, please keep the following in mind: * Delaying a release in order to merge "one more feature" means that every *other* feature in the release gets delayed so that the "one more feature" can hit stable earlier. * If we can actually get releases out on a 7-9 month schedule (or better), the impact of making a feature wait for the next release becomes less severe than it's been in the past. [*] Let's not waste time trying in advance to enumerate exceptional circumstances. yrs, -- Nick

2 1

Using routers as bridges
by Rob van der Hoeven 14 Jul '11

14 Jul '11

Hi folks, Bridges serve as "unknown" entry points to the TOR network. For this, part of the TOR network nodes are reserved and unlisted. This is not good for the performance of the network, and because the network is relatively small i think the unlisted-nodes strategy will only be a short term solution. At the moment i'm working on my own FreedomBox. From this work i got the following idea: Why not use the DNAT function of a router to forward TOR traffic to a TOR node? This way you don't need unlisted nodes anymore. A router-bridge does not have to be a full TOR node.... Unfortunately the standard DNAT functionality of most routers only support DNAT from the internet to internal addresses. So you need modified firmware to make this work. Maybe a (slightly modified?) version of OpenWRT will work. Router-bridges have a second advantage over real TOR nodes. They can be easily moved. If a router-bridge gets blocked, you can simply give the router-bridge to a friend. To give you an example of internet-internet DNAT i have configured one of my systems to forward traffic to the TOR website. The URL is: https://wordpress.hoevenstein.nl/ (If you try the URL you get a message about an invalid certificate of course) Let me know what you think about this idea... Rob van der Hoeven. http://freedomboxblog.nl

4 6

Tor Relay Setup Wizard
by Damian Johnson 14 Jul '11

14 Jul '11

Hi all. Over the last few weeks I've been working on a relay setup wizard for arm. Its purpose is to make volunteering to be a relay easy, narrowing the options to those most commonly used and giving nice descriptions/defaults to encourage good configurations. At present relay setup for new users, particularly exits, is either confusing or limited. For users doing it without a controller we have a deluge of man page options and a confusing bundle of docs. For Vidalia users, however, it's easy to become a middle hop or bridge, but the configurations it makes for exits are poor (default exit policy, no front page, no notice for how to reduce abuse complaints which probably leads Vidalia exits to be short lived...). This wizard consists of three pages... 1. Selection for what you'd like to be http://www.atagar.com/transfer/tmp/arm_wizard1.png 2. Picking your relay options, with both descriptions of the options and why you'd want to set them http://www.atagar.com/transfer/tmp/arm_wizard2.png 3. Confirmation for the configuration it's making http://www.atagar.com/transfer/tmp/arm_wizard3.png 4. ... then in the frozen land of Nador they were forced to eat Sir Robin's minstrels. And there was much rejoicing. http://www.atagar.com/transfer/tmp/arm_wizard4.png My not-so-humble goals for this wizard is for it to become a method we suggest on the site for setting up an exit (and maybe relays/bridges too later) so I'd appreciate some feedback! The 1.4.3 release candidate is available at... http://www.atagar.com/transfer/tmp/arm-1.4.3rc.tar.bz2 Future plans are automatic signup for Tor Weather and a "Run Tor at Startup" option (this later one is gonna be tricky, but it's vital if we want systems like laptops that frequently shut down to be meaningful relays/bridges). Cheers! -Damian

3 5

(no subject)
by Georg Koppen 11 Jul '11

11 Jul '11

This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============7169121415546917615== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3F72C2734FABE1CB4A827A42" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3F72C2734FABE1CB4A827A42 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable >> Hmmm... If that is the answer to my questions then there is nothing like >> avoiding getting tracked by exit mixes in the concept offered in the >> blog post. Okay. >=20 > That is not entirely true. Because identifiers would be linked to > top-level urlbar domain, gone are the days where exits could insert an > iframe or web-bug into any arbitrary page and use that to track the > user for the duration of the session, regardless of page view. >=20 > Instead, they would be pushed back to doing some sort of top-level > redirect (which we hope would be way more visible), or maybe not even > that, depending on how we define redirects with respect to > "top-level". >=20 > So no, we are not completely abandoning exits as an adversary with > this threat model. If I'm wrong about something, or you think there > are still attacks exits can perform that we should address somehow, > let me know. See my last mail. >> Another question came to my mind: You seem to be at pains not to break >> parts of the web even in the anon mode even if that boils down to not >> implement features that would better fit the needs for people looking >> for unlinkability (one thing that comes to my mind here would be having >> a context being tab dependent additionally). Why? Why not saying: "This >> is Tor's anon mode. It is meant for people that strive for unlinkability >> and might break some functionality. You may still use Tor in normal or >> private browsing mode though (providing no or less unlinkability on the >> browser level)." Do you think that's not worth the effort as Tor's IP >> unlinkability is enough here (especially combined with the things you >> suggested in the blog post)? I do not know Tor's user base very well but >> could imagine that it contains a lot of users that would like to have >> more unlinkability than the "we do not want to break any (or almost any) >> part of the web for a better anonymity" fraction. >=20 > I wish I had better science to give you here on the trade-off we're > going for, but the reality is that we're best-guessing over a very > complex cost/benefit landscape. That's true. > We do know for a fact that the easier Tor is to use (which includes > installation, configuration, overall intuitiveness/"familiarity", > compatibility, and performance), the more people will use it > regularly. That seems to hold for every piece of software, I guess. > We also know for a fact that the more people use Tor, the better the > baseline privacy, anonymity, and censorship resistance properties all > become. Agreed. > Hence, I tend to make decisions in favor of the usability direction > over minor details, especially ones that don't really prevent bad > actors/adversaries from accomplishing their goals. That is definitely a good approach. But maybe there is research to be done here as well. Just a rough (and in part research) idea that I had in mind while asking you the question above: What about if we first started looking at different services offered in the web whether they can be deployed anonymously *at all* (or maybe more precisely (but not much): that can be deployed in a way that there is either no linkability at all or the linkability is not strong enough to endanger the user) (that would be worth some research, I guess)? We would probably find some services where we had to say: "Well, there is no way to get them used anonymously due to their nature and the power of the companies and/or owners behind them." (Facebook comes here to my mind as a candidate and the Google universe as well due to the power Google has). Should we say we make the Tor anon mode compatible with these services nevertheless (due to usability issues) and abandon stronger anonymity measures? I would say no. Not at all. Rather we should be honest and say: "Dear User, surfing anonymously AND using Facebook does not work. You may use the Tor anon mode for that purpose though but there is a high probability that it breaks functionality." The idea of getting more users due to being not too strict here might be appealing but is not the right decision in the end. I think one has to realize that there are services in the web that are *designed* in a way that one EITHER may use them OR use anonymity services. Sure, the devil is in the details (e.g. there are probably a lot of services that may be usable anonymously but then are accompanied with a certain lack of usability. What about them? Should we decide against usability again or should we loosen our means to provide unlinkability here?) but that does not mean there is no way to find a good solution though. In short (and still roughly): I would like to start thinking from having all means available to surf the web anonymously and then downgrade them piece-by-piece to reach a trade-off between anonymity and usability. Services that may not be used anonymously at all would not trigger such a painful downgrade ("painful" as one usually tries first to hack around existing problems encountering unbelievable design issues and bugs and has to concede finally that it is in the user's interest to exclude that feature (again)). > The need for science especially comes in on the fingerprinting arena. > Some fingerprinting opportunities may not actually be appealing to > adversaries. Some may even appear appealing in theory, but in practice > would be noticeable to the user, too noisy, and/or too error-prone. > Hence I called for more panopticlick-style studies, especially of > Javascript features, in the blog post. Yes, that is definitely a good idea though I tend to avoid them all even if currently no adversary is using them (especially if no usability issue is at stake). First: no one knows whether one did not miss an attacker using this kind of attack vector and second: Getting rid of attack vectors is a good thing per se. Georg --------------enig3F72C2734FABE1CB4A827A42 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJOGbUuAAoJEKw9P8jZNrM42sIIAKWwpLB+6Aeu97FMeLwJkI/7 blZ98yMsU8fUchIjrkxeTllUX5gcSuI0PSODaMd0lZFEvkFlMAuudcbnC0GmnEVV DP8KV5j8A/RZnVgbEh18AB/keNojnMo/PneCg0109Say2WWqOvL+tklxA14NvgrJ EQlr/P9tmSkdLtwjq5QBQPOVuGNigPk4em2wuSOo1i+7l65VLpfWLYnNwaBEOoGA /ZOKe4h3KLaXiJhaFpvw4d1BoCGAQC2lHb5724qmiTzdFDRAyigewFPxMy8wjO3H mKdPt/WcKw7NfU6jEY7mYRk1D0v3lttjtx9zLwJxwyYXV0rK/DhNiIlJG0uxX8k= =Y0SW -----END PGP SIGNATURE----- --------------enig3F72C2734FABE1CB4A827A42-- --===============7169121415546917615== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tor-dev mailing list tor-dev(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev --===============7169121415546917615==--

1 0

(no subject)
by Georg Koppen 11 Jul '11

11 Jul '11

This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2411481729548231614== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC109D701B963D257C02E88A3" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC109D701B963D257C02E88A3 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable > However, when performed by the exits, this linkability is a real > concern. Let's think about that. That sounds more like our > responsibility than the browser makers. Now I think I see what Georg > was getting at. We didn't mention this because the blog post was > directed towards the browser makers. Well, my idea was not that sophisticated but yes, it belongs to the passive attacks available to exit mixes I generally had in mind (and I agree that the current domain-based proposal makes it way harder for an active mix attacker). My example used just one session. And I still would claim that even this gives an exit mix means to track users during the 10 minutes (and later if the user happens to get the same exit mix again within the same browsing session). If this is true do you mean that it is just not worth the effort or is to difficult to explain to the user (as it is highly probably that avoiding this kind of tracking implies breaking some functionality in the web (a kind of tab separation would be necessary but not sufficient))? Georg --------------enigC109D701B963D257C02E88A3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJOGaJkAAoJEKw9P8jZNrM47GcH/0yeBG8DCujKgedqr7Ex9rNd LU8gP/P/QXQ8q1htwek65fKTm4w8gmjqz0aWqtxBH4oVKy0TisQyBNXd50x2DIag qJQEDnZYVTzl/DrVVy0bDdvk9+xxfprGpjeWPqNWUCuw/9m8e0QfrSWJagC9nDzn iMsmbboLDUQSNWQAkhJX42fv8xI3uHGZY2an418xX9pcDY7qNLBvsVIhMU+MVvXm 9vsdvH2EAXtFNP/OQHp2iP51jUX1oyY0kE+3jtmMp9OjJXWYzKmYlnC6LBaxEXdD 4C7eWXTnVphFNbiT2NFDtcY1hWtWjdoO1uzR/XpoxDO9Gves8xenVVE5S7tZ44I= =Tz7D -----END PGP SIGNATURE----- --------------enigC109D701B963D257C02E88A3-- --===============2411481729548231614== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tor-dev mailing list tor-dev(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev --===============2411481729548231614==--

1 0

(no subject)
by Georg Koppen 11 Jul '11

11 Jul '11

This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2411481729548231614== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC109D701B963D257C02E88A3" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC109D701B963D257C02E88A3 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable > However, when performed by the exits, this linkability is a real > concern. Let's think about that. That sounds more like our > responsibility than the browser makers. Now I think I see what Georg > was getting at. We didn't mention this because the blog post was > directed towards the browser makers. Well, my idea was not that sophisticated but yes, it belongs to the passive attacks available to exit mixes I generally had in mind (and I agree that the current domain-based proposal makes it way harder for an active mix attacker). My example used just one session. And I still would claim that even this gives an exit mix means to track users during the 10 minutes (and later if the user happens to get the same exit mix again within the same browsing session). If this is true do you mean that it is just not worth the effort or is to difficult to explain to the user (as it is highly probably that avoiding this kind of tracking implies breaking some functionality in the web (a kind of tab separation would be necessary but not sufficient))? Georg --------------enigC109D701B963D257C02E88A3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJOGaJkAAoJEKw9P8jZNrM47GcH/0yeBG8DCujKgedqr7Ex9rNd LU8gP/P/QXQ8q1htwek65fKTm4w8gmjqz0aWqtxBH4oVKy0TisQyBNXd50x2DIag qJQEDnZYVTzl/DrVVy0bDdvk9+xxfprGpjeWPqNWUCuw/9m8e0QfrSWJagC9nDzn iMsmbboLDUQSNWQAkhJX42fv8xI3uHGZY2an418xX9pcDY7qNLBvsVIhMU+MVvXm 9vsdvH2EAXtFNP/OQHp2iP51jUX1oyY0kE+3jtmMp9OjJXWYzKmYlnC6LBaxEXdD 4C7eWXTnVphFNbiT2NFDtcY1hWtWjdoO1uzR/XpoxDO9Gves8xenVVE5S7tZ44I= =Tz7D -----END PGP SIGNATURE----- --------------enigC109D701B963D257C02E88A3-- --===============2411481729548231614== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tor-dev mailing list tor-dev(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev --===============2411481729548231614==--

1 0

(no subject)
by Georg Koppen 11 Jul '11

11 Jul '11

This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============7169121415546917615== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3F72C2734FABE1CB4A827A42" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3F72C2734FABE1CB4A827A42 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable >> Hmmm... If that is the answer to my questions then there is nothing like >> avoiding getting tracked by exit mixes in the concept offered in the >> blog post. Okay. >=20 > That is not entirely true. Because identifiers would be linked to > top-level urlbar domain, gone are the days where exits could insert an > iframe or web-bug into any arbitrary page and use that to track the > user for the duration of the session, regardless of page view. >=20 > Instead, they would be pushed back to doing some sort of top-level > redirect (which we hope would be way more visible), or maybe not even > that, depending on how we define redirects with respect to > "top-level". >=20 > So no, we are not completely abandoning exits as an adversary with > this threat model. If I'm wrong about something, or you think there > are still attacks exits can perform that we should address somehow, > let me know. See my last mail. >> Another question came to my mind: You seem to be at pains not to break >> parts of the web even in the anon mode even if that boils down to not >> implement features that would better fit the needs for people looking >> for unlinkability (one thing that comes to my mind here would be having >> a context being tab dependent additionally). Why? Why not saying: "This >> is Tor's anon mode. It is meant for people that strive for unlinkability >> and might break some functionality. You may still use Tor in normal or >> private browsing mode though (providing no or less unlinkability on the >> browser level)." Do you think that's not worth the effort as Tor's IP >> unlinkability is enough here (especially combined with the things you >> suggested in the blog post)? I do not know Tor's user base very well but >> could imagine that it contains a lot of users that would like to have >> more unlinkability than the "we do not want to break any (or almost any) >> part of the web for a better anonymity" fraction. >=20 > I wish I had better science to give you here on the trade-off we're > going for, but the reality is that we're best-guessing over a very > complex cost/benefit landscape. That's true. > We do know for a fact that the easier Tor is to use (which includes > installation, configuration, overall intuitiveness/"familiarity", > compatibility, and performance), the more people will use it > regularly. That seems to hold for every piece of software, I guess. > We also know for a fact that the more people use Tor, the better the > baseline privacy, anonymity, and censorship resistance properties all > become. Agreed. > Hence, I tend to make decisions in favor of the usability direction > over minor details, especially ones that don't really prevent bad > actors/adversaries from accomplishing their goals. That is definitely a good approach. But maybe there is research to be done here as well. Just a rough (and in part research) idea that I had in mind while asking you the question above: What about if we first started looking at different services offered in the web whether they can be deployed anonymously *at all* (or maybe more precisely (but not much): that can be deployed in a way that there is either no linkability at all or the linkability is not strong enough to endanger the user) (that would be worth some research, I guess)? We would probably find some services where we had to say: "Well, there is no way to get them used anonymously due to their nature and the power of the companies and/or owners behind them." (Facebook comes here to my mind as a candidate and the Google universe as well due to the power Google has). Should we say we make the Tor anon mode compatible with these services nevertheless (due to usability issues) and abandon stronger anonymity measures? I would say no. Not at all. Rather we should be honest and say: "Dear User, surfing anonymously AND using Facebook does not work. You may use the Tor anon mode for that purpose though but there is a high probability that it breaks functionality." The idea of getting more users due to being not too strict here might be appealing but is not the right decision in the end. I think one has to realize that there are services in the web that are *designed* in a way that one EITHER may use them OR use anonymity services. Sure, the devil is in the details (e.g. there are probably a lot of services that may be usable anonymously but then are accompanied with a certain lack of usability. What about them? Should we decide against usability again or should we loosen our means to provide unlinkability here?) but that does not mean there is no way to find a good solution though. In short (and still roughly): I would like to start thinking from having all means available to surf the web anonymously and then downgrade them piece-by-piece to reach a trade-off between anonymity and usability. Services that may not be used anonymously at all would not trigger such a painful downgrade ("painful" as one usually tries first to hack around existing problems encountering unbelievable design issues and bugs and has to concede finally that it is in the user's interest to exclude that feature (again)). > The need for science especially comes in on the fingerprinting arena. > Some fingerprinting opportunities may not actually be appealing to > adversaries. Some may even appear appealing in theory, but in practice > would be noticeable to the user, too noisy, and/or too error-prone. > Hence I called for more panopticlick-style studies, especially of > Javascript features, in the blog post. Yes, that is definitely a good idea though I tend to avoid them all even if currently no adversary is using them (especially if no usability issue is at stake). First: no one knows whether one did not miss an attacker using this kind of attack vector and second: Getting rid of attack vectors is a good thing per se. Georg --------------enig3F72C2734FABE1CB4A827A42 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJOGbUuAAoJEKw9P8jZNrM42sIIAKWwpLB+6Aeu97FMeLwJkI/7 blZ98yMsU8fUchIjrkxeTllUX5gcSuI0PSODaMd0lZFEvkFlMAuudcbnC0GmnEVV DP8KV5j8A/RZnVgbEh18AB/keNojnMo/PneCg0109Say2WWqOvL+tklxA14NvgrJ EQlr/P9tmSkdLtwjq5QBQPOVuGNigPk4em2wuSOo1i+7l65VLpfWLYnNwaBEOoGA /ZOKe4h3KLaXiJhaFpvw4d1BoCGAQC2lHb5724qmiTzdFDRAyigewFPxMy8wjO3H mKdPt/WcKw7NfU6jEY7mYRk1D0v3lttjtx9zLwJxwyYXV0rK/DhNiIlJG0uxX8k= =Y0SW -----END PGP SIGNATURE----- --------------enig3F72C2734FABE1CB4A827A42-- --===============7169121415546917615== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tor-dev mailing list tor-dev(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev --===============7169121415546917615==--

1 0

Feedback on new Orbot data stats
by Nathan Freitas 06 Jul '11

06 Jul '11

Sathya (our fantastic GSoC 2011 dev) has been working on improving the display of information that we can glean from Tor via the control port interface. You can see the results of his work (including an initial screenshot) so far here: http://gsathya.in/blog/?p=66 We would like feedback from Tor/Vidalia and Orbot users out there on what data from Tor that you feel is useful and necessary both as a general case, and perhaps what might be more relevant in a mobile context. One case to consider is that in mobile, we are constantly losing our IP connection, switching from 2G to 3G to Wifi to no service at all. What information does Tor produce that can help the user understand better the state that Orbot is actually in? We are also trying to consider three modes of display: the main screen "dashboard", a full screen detail view, and background notifications that alert the user to important state changes. Thanks! +n8fr8

1 0

Tech report: An Analysis of Tor Relay Stability
by Karsten Loesing 04 Jul '11

04 Jul '11

Hello tor-dev, I just added a tech report called "An Analysis of Tor Relay Stability" that might be interesting to people here to the metrics website: https://metrics.torproject.org/papers/relay-stability-2011-06-30.pdf >From the introduction: "The Tor network consists of around 2,000 relays and 500 bridges run by volunteers, some of which are on dedicated servers and some on laptops or mobile devices. Obviously, we can expect the relays run on dedicated servers to be more "stable" than those on mobile phones. But it is difficult to draw a line between stable and unstable relays. In most cases it depends on the context which relays count as stable: [...] In this analysis, we use a simulator to resemble how the directory authorities assign the Stable and Guard relay flags. This simulator uses archived directory data to decide when a relay was running and when it failed or was restarted. We further use this simulator to calculate future stability metrics that help us evaluate the quality of a given relay flag assignment. We modify the input parameters to Tor's stability metrics to see whether we can improve how the directory authorities should assign relay flags. The analysis data and simulator used in this report are available on the Tor metrics website at https://metrics.torproject.org/." I also made the simulator code and input data available here: https://metrics.torproject.org/papers.html As always, feedback is highly appreciated! Best, Karsten

1 0