- tor-dev - lists.torproject.org

New mailing list for wiki changes
by Karsten Loesing 25 Jul '11

25 Jul '11

Hi everyone, yesterday we found that a few people run their own rss-to-email service to be notified of wiki changes. We decided that it's easier to set up a new mailing list that has all the wiki changes and that everyone can subscribe to. If you're interested in learning when something in the wiki changed, subscribe to: https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-wiki-changes (And if you have suggestions to make the r2e output more useful, please say so. The current configuration is simply 'r2e add "https://trac.torproject.org/projects/tor/timeline?wiki=on&max=50&daysback=2…" tor-wiki-changes(a)lists.torproject.org'.) Best, Karsten

1 0

New Paper: Cloud-based Onion Routing
by Nick Jones 15 Jul '11

15 Jul '11

Hi All, I'm a graduate student at Princeton, and our research group has recently submitted a paper proposing a design for cloud based onion routing. The goal of our research is to securely perform onion routing on cloud based infrastructure (like Amazon EC2 and Rackspace) while allowing users to retain the same (or almost the same) privacy as when using Tor. We distribute trust across multiple cloud providers, and use Chaum's e-cash for payment and access control. Additionally, we hope that the elasticity of cloud infrastructure will make cloud based OR more censorship resistant than current systems. This project is still in a relatively early stage, and we would love to get feedback from the Tor community. We would welcome any comments/questions/criticisms. Our project's website is available at: http://sns.cs.princeton.edu/projects/cor/ A direct link to our paper is here: http://www.cs.princeton.edu/~najones/publications/cor-foci11.pdf Our abstract: Internet censorship and surveillance have made anonymity tools increasingly critical for free and open Internet access. Tor, and its associated ecosystem of vol- unteer traffic relays, provides one of the most secure and widely-available means for achieving Internet anonymity today. Unfortunately, Tor has limitations, including poor performance, inadequate capacity, and a susceptibility to wholesale blocking. Rather than utilizing a large number of volunteers (as Tor does), we propose mov- ing onion-routing services to the “cloud” to leverage the large capacities, robust connectivity, and economies of scale inherent to commercial datacenters. This paper de- scribes Cloud-based Onion Routing (COR), which builds onion-routed tunnels over multiple anonymity service providers and through multiple cloud hosting providers, dividing trust while forcing censors to incur large collat- eral damage. We discuss the new security policies and mechanisms needed for such a provider-based ecosys- tem, and present some preliminary benchmarks. At to- day’s prices, a user could gain fast, anonymous network access through COR for only pennies per day. Thanks! Nick Jones

3 5

Re: [tor-dev] CPU utilization for relay
by swsnyder＠snydernet.net 15 Jul '11

15 Jul '11

Mike Perry wrote: >Thus spake swsnyder at snydernet.net (swsnyder at 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. I didn't break on CAST_encrypt() either in a running process or in tor started from a gdb command line. Either way, I could set a breakpoint on the symbol but never actually got there. I think the symbols were screwed-up from building Tor with GCC's Profile Guided Optimization. When I built the same code without PGO I get this from another 10-minute run: CPU: CPU with timer interrupt, speed 0 MHz (estimated) Profiling through timer interrupt samples % linenr info symbol name 2386 58.6241 x86-mont.s:8 bn_mul_mont 262 6.4373 aes-586.s:269 _sse_AES_encrypt_compact 207 5.0860 sha1-586.s:8 sha1_block_data_order 199 4.8894 aes-586.s:424 _x86_AES_encrypt 189 4.6437 aes-586.s:1610 _x86_AES_decrypt 55 1.3514 aes.c:329 aes_crypt_inplace 48 1.1794 di_ops.c:97 tor_memeq Breakpoints *do* hit on bn_mul_mont(). I assume the reduced number of samples is a result of only having half as many active connection as the prior profiling run. Thanks for the reply.

1 0

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) --===============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

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

Tor and BGP integration
by Jacob Appelbaum 29 Jun '11

29 Jun '11

Hello from Iceland, Linus invited me to Reykjavik to talk about Tor at the NORDUnet conference and this idea is the result of a bit of feedback from some network operators here. Tor needs a way to be friendly to large network operators who wish to enable exiting to anonymous communication for their networks. These network operators are happy to allow anyone to pass traffic to their relays as entry nodes, middle nodes and even limited exit nodes. Linus and I have been discussing methods of automating this process and of course BGP integration makes a lot of sense. Generally, a network operator has a set of AS numbers for their network blocks and as they want people to connect to many of their services, it helps quite a bit to allow exiting to those services from their own Tor relays. We came up with two main ideas for making this happen. One method would be to write a program where given an AS number and a BGP feed, we parse all of the advertised network blocks and emit exit policy lines that accepts all traffic for the AS. This would allow for a web service similar to BulkExitList.py for network aware exit policy generation and relay operators would simply need to add this to their Tor configs manually. For mostly static networks, a cronjob would be fine and Tor doesn't need to know about AS numbers internally. Another method would be to write a controller that watches for BGP network updates and Tor would add relevant exit policy lines for any configured AS. This would allow any Tor relay to dynamically learn about network changes if it has access to a BGP feed patched into a controller. This could be implemented by adding some configuration options to Tor that let Tor know which AS numbers matter to which router. It may also allow for the router to auto learn it's own likely family network but it lacks any kind of bi-directional confirmation, still it seems useful information to have... It would be fantastic if someone offered a hidden service NORDUNet BGPMon feed. This would help enable the first method of generating network aware exit policies; this would also help with the development of AS awareness in Tor itself. In the future, I imagine that it makes a lot of sense for circuit building to be BGP aware as mere netblocks will not be very useful in an ipv6 world, they're already mostly irrelevant. Anyway, food for thought. Linus and I will probably hack on some of these ideas in the near future. All the best, Jake

6 9

WIN32_WINNT in or/or.h
by Gisle Vanem 27 Jun '11

27 Jun '11

I think that the values for 'WIN32_WINNT' and '_WIN32_WINNT' should be protected against redefinement. Reason: In order for MingW to prototype getaddrinfo() and freeaddrinfo() correctly (in <ws2tcpip.h>), '_WIN32_WINNT' *must* be defined as 0x0501 or higher. or/or.h blindly defines them as 0x0400. So, building with -DHAVE_GETADDRINFO needs _WIN32_WINNT to be set to 0x0501. As of now, MingW would simply fallback to use gethostbyname(). So I think this little patch is in order: --- ..\Git-latest\src\or\or.h Mon Jun 20 23:58:06 2011 +++ or\or.h Tue Jun 21 00:04:42 2011 @@ -23,8 +23,12 @@ #endif #ifdef MS_WINDOWS +#ifndef WIN32_WINNT #define WIN32_WINNT 0x400 +#endif +#ifndef _WIN32_WINNT #define _WIN32_WINNT 0x400 +#endif #define WIN32_LEAN_AND_MEAN #endif ----------------------------- What do you say? --gv

2 2

Proposal 182: Credit Bucket
by Nick Mathewson 27 Jun '11

27 Jun '11

Here's a proposal by Florian and Björn about improving our queueing times. Per usual procedure, I'm sending it here as I put it in the proposals directory. Filename: 182-creditbucket.txt Title: Credit Bucket Author: Florian Tschorsch and Björn Scheuermann Created: 22 Jun 2011 Status: Draft Overview: The following proposal targets the reduction of queuing times in onion routers. In particular, we focus on the token bucket algorithm in Tor and point out that current usage unnecessarily locks cells for long time spans. We propose a non-intrusive change in Tor's design which overcomes the deficiencies. Motivation and Background: Cell statistics from the Tor network [1] reveal that cells reside in individual onion routers' cell queues for up to several seconds. These queuing times increase the end-to-end delay very significantly and are apparently the largest contributor to overall cell latency in Tor. In Tor there exist multiple token buckets on different logical levels. They all work independently. They are used to limit the up- and downstream of an onion router. All token buckets are refilled every second with a constant amount of tokens that depends on the configured bandwidth limits. For example, the so-called RelayedTokenBucket limits relay traffic only. All read data of incoming connections are bound to a dedicated read token bucket. An analogous mechanism exists for written data leaving the onion router. We were able to identify the specific usage and implementation of the token bucket algorithm as one cause for very high (and unnecessary) queuing times in an onion router. We observe that the token buckets in Tor are (surprisingly at a first glance) allowed to take on negative fill levels. This is justified by the TLS connections between onion routers where whole TLS records need to be processed. The token bucket on the incoming side (i.e., the one which determines at which rate it is allowed to read from incoming TCP connections) in particular often runs into non-negligible negative fill levels. As a consequence of this behavior, sometimes slightly more data is read than it would be admissible upon strict interpretation of the token bucket concept. However, the token bucket for limiting the outgoing rate does not take on negative fill levels equally often. Consequently, it regularly happens that somewhat more data are read on the incoming side than the outgoing token bucket allows to be written during the same cycle, even if their configured data rates are the same. The respective cells will thus not be allowed to leave the onion router immediately. They will thus necessarily be queued for at least as long as it takes until the token bucket on the outgoing side is refilled again. The refill interval currently is, as mentioned before, one second -- so, these cells are delayed for a very substantial time. In summary, one could say that the two buckets, on the incoming and outgoing side, work like a double door system and frequently lock cells for a full token bucket refill interval length. General Design: In order to overcome the described problem, we propose the following changes related to the token bucket algorithm. We observe that the token bucket on the outgoing connections with its current design is contra productive in the sense of queuing times. We therefore propose modifications to the token bucket algorithm that will eliminate the "double door effect" discussed above. Let us start from Tor's current approach: Thus, we have a regular token bucket on the reading side with a certain rate and a certain burst size. Let x denote the current amount of tokens in the bucket. On the outgoing side we need something appropriate that monitors and constrains the outgoing rate, but at the same time avoids holding back cells (cf. double door effects) whenever possible. Here we propose something that adopts the role of a token bucket, but realizes this functionality in a slightly different way. We call it a "credit bucket". Like a token bucket, the credit bucket also has a current fill level, denoted by y. However, the credit bucket is refilled in a different way. To understand how it works, let us look at the possible operations: As said, x is the fill level of a regular token bucket on the incoming side and thus gets incremented periodically according to the configured rate. No changes here. If x<=0, we are obviously not allowed to read. If x>0, we are allowed to read up to x bytes of incoming data. If k bytes are read (k<=x), then we update x and y as follows: x = x - k (1) y = y + k (2) (1) is the standard token bucket operation on the incoming side. Whenever data is admitted in, though, an additional operation is performed: (2) allocates the same number of bytes on the outgoing side, which will later on allow the same number of bytes to leave the onion router without any delays. If y + x > -M, we are allowed to write up to y + x + M bytes on the outgoing side, where M is a positive constant. M specifies a burst size for the outgoing side. M should be higher than the number of tokens that get refilled during a refill interval, we would suggest to have M in the order of a few seconds "worth" of data. Now if k bytes are written on the outgoing side, we proceed as follows: If k <= y then y = y - k In this case we use "saved" credits, previously allocated on the incoming side when incoming data has been processed. If k > y then y = 0 and x = x - (k-y) We generated additional traffic in the onion router, so that more data is to be sent than has been read (the credit is not sufficient). We therefore "steal" tokens from the token buffer on the incoming side to compensate for the additionally generated data. This will result in correspondingly less data being read on the incoming side subsequently. As a result of such an operation, the token bucket fill level x on the incoming side may become negative (but it can never fall below -M). If y + x <= -M then outgoing data will be held back. This may lead to double-door effects, but only in extreme cases where the outgoing traffic largely exceeds the incoming traffic, so that the outgoing bursts size M is exceeded. Aside from short-term bursts of configurable size (as with every token bucket), this procedure guarantees that the configured rate may never be exceeded (on the application layer, that is; as with the current implementation, an attacker may easily cause the onion router to arbitrarily exceed the limits on the lower layers). Over time, we never send more data than the configured rate: every sent byte needs a corresponding token on the incoming side; this token must either have been consumed by an incoming byte before (it then became a "credit"), or it is "stolen" from the incoming bucket to compensate for data generated within the onion router. Specific Design Changes: In the following we briefly point out the specific changes that need to be done in Tor's source code. By doing so one can see how non intrusive our modifications are. First we need to address the bucket increment and decrement operations. According to the described logic above, this should be done in the methods connection_bucket_refill and connection_buckets_decrement respectively. In particular allocating, saving and "stealing" of tokens need to be considered here. Second the rate limiting, i.e. the amount we are allowed to write (connection_bucket_write_limit) needs to be adapted in lines of the credit bucket logic. Meaning in order to avoid the here identified unnecessary queuing of cells, we need to consider the new burst parameter M. Here we also need to take non rate limited connections such as from the localhost into account. The rate limiting on the reading side remains the same. At last we need to find good values/ ratios for the parameter M such that the trade off between avoiding "double door effects" and maintaining strict rate limits work as expected. As future work and after insights about the performance gain of the here described proposal we need to find a way to implement this both using bufferevent rate limiting with libevent 2.3.x and Tor's rate limiting code. Conclusion: This proposal can be implemented with moderate effort and requires changes only at the points where currently the token bucket operations are performed. We feel that this is not the be-all and end-all solution, because it again introduces a feedback loop between the incoming and the outgoing side. We therefore still hope that we will be able to come to a both simpler and more effective design in the future. However, we believe that what we proposed here is a good compromise between avoiding double-door effects to the furthest possible extent, strictly enforcing an application-layer data rate, and keeping the extent of changes to the code small. Feedback is highly appreciated. References: [1] Karsten Loesing. Analysis of Circuit Queues in Tor. August 25, 2009. [2] https://trac.torproject.org/projects/tor/wiki/sponsors/SponsorD/June2011

1 0

Reg : using the keep alive messages
by Sambuddho Chakravarty 27 Jun '11

27 Jun '11

Hi All I read in the Tor design spec that Tor control protocol supports keepalive messages which could be used for link padding . I wonder if anyone has ever explored using them... Thanks Sambuddho

2 4

TOR control protocol timeout
by Sean Robinson 25 Jun '11

25 Jun '11

Is there a defined timeout for the TOR control protocol? How long should a control port client wait around for socket data when reading? Or writing? The only references to timeouts that I find in control-spec.txt are about circuit and stream timeouts reported back through the control port. -- Sean Robinson WiFi Radar - http://wifi-radar.berlios.de Python WiFi - http://pythonwifi.wikispot.org pymnl - http://pymnl.wikispot.org

2 4

Tor AF independence patch - first big step to Tor IPv6
by Jeroen Massar 20 Jun '11

20 Jun '11

Hi, As this is World IPv6 day, let me present the first big step to Tor IPv6: the Address Family independence Patch ;) https://unfix.org/projects/ipv6/tor/tor-af-independent.diff it is diff against a recent git checkout and should apply more or less cleanly. Why AF independence[1,2] and not "IPv6 patch", well, for a program to be able to support IPv6 it should first not care about IP in the first place. With Tor that is a tricky thing as it actually needs to know about IP for quite a few places. As such this patch primary function is to make most functions use toraddr_t, that way both IPv6 and IPv4 are supported. Note that a lot of functionality for supporting IPv6 (or any other IP protocol in the longer term) is already present in current versions of Tor (even unittests are present already!). Note also that this is not a 'true' AF indepencence patch as in that case we would have to swap toraddr_t with a sockaddr_storage structure, which, when recompiled, would be true AF independent. In the case though that ever a new IP-alike protocol arises and then we still use BSD style sockets, this patch should make it easy to use that new address family too, but don't hold your breath ;) The problem with that though is that at this stage that means that everywhere IPv6 can be stuck just like IPv4 while these should be separate. And to make it a bit worse, one should actually have them also properly in the packets being sent between nodes and there is no separation between exit policies etc. There is thus a lot to discuss on this subject, and one of the first things that really need to be done is ORMultiPort (proposal 118) to be able to separate IPv4 and IPv6 ports. A question there also becomes, do we want to show a Tor node as separate IPv4 and IPv6 routers, or are they to be seen as one, if it is one, we require the above ORMultiport, so that we can have multiple IP addresses and ports on a single node. As such, I suggest we have a big discussion on the flaws of my patch and how to resolve some of the remaining problems and then start moving work to the ORMultPort patch so that we can start enabling IPv6 everywhere, as then we are getting quite close. And maybe, it could be useful to have a special branch on torproject's git server for this, as it is quite a bit of patch ;) Greets, Jeroen (fuzzel on #tor-dev) [1] = http://www.kame.net/newsletter/19980604/ [2] = http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html

2 3

[PATCH] Allow tordnsel to build on Squeeze
by Jérémy Bobbio 20 Jun '11

20 Jun '11

Hi! Quoting IRC: <phobos> I give up on tordnsel, I'm unable to get git head to compile in squeeze Attached are 3 patches that allow tordnsel to build on a Squeeze system. I unfortunately lack a test environment to ensure that the resulting binary works fine. Haskell has proven quite trusty, though. The work needed to make it work for the next versions of GHC (7.x) is going to be an order of magnitude bigger, so it probably makes sense to get the Python implementation working until Squeeze is EOL. Cheers, -- Jérémy Bobbio .''`. lunar(a)debian.org : :Ⓐ : # apt-get install anarchism `. `'` `-

2 1

RFC: remove TorUtil.Enum
by Sean Robinson 18 Jun '11

18 Jun '11

I have been reviewing the TorCtl package and I will be submitting tickets (usually with patches) for clean-ups, fixes, etc. Before I submit a ticket for removing TorUtil.Enum, I wanted to hear from other devs. There are no users of this class within TorCtl, so Enum is now cruft. Does anyone have a problem with removing Enum? If I do not get negative feedback about this patch, I will submit it later in the week. The following patch is also attached to this message as a gzipped patch file. diff --git a/TorUtil.py b/TorUtil.py index 3163d09..1d27144 100644 --- a/TorUtil.py +++ b/TorUtil.py @@ -22,7 +22,7 @@ if sys.version_info < (2, 5): else: from hashlib import sha1 -__all__ = ["Enum", "Enum2", "Callable", "sort_list", "quote", "escape_dots", "unescape_dots", +__all__ = ["Enum2", "Callable", "sort_list", "quote", "escape_dots", "unescape_dots", "BufSock", "secret_to_key", "urandom_rng", "s2k_gen", "s2k_check", "plog", "ListenSocket", "zprob", "logfile", "loglevel", "loglevels"] @@ -127,16 +127,6 @@ def read_config(filename): loglevel = config.get('TorCtl', 'loglevel') -class Enum(object): - """ Defines an ordered dense name-to-number 1-1 mapping """ - def __init__(self, start, names): - self.nameOf = {} - idx = start - for name in names: - setattr(self,name,idx) - self.nameOf[idx] = name - idx += 1 - class Enum2(object): """ Defines an ordered sparse name-to-number 1-1 mapping """ def __init__(self, **args): -- 1.7.5.1 -- Sean Robinson WiFi Radar - http://wifi-radar.berlios.de Python WiFi - http://pythonwifi.wikispot.org pymnl - http://pymnl.wikispot.org

2 2

Looking at Bridge users oddities
by Arturo 17 Jun '11

17 Jun '11

Hi, Jake made me notice that there has been a huge spike in tor bridge users in Italy in the past week (https://metrics.torproject.org/users.html?graph=bridge-users&start=2011-02-…) This prompted me to hack up a quick little script to analyse the Tor bridge usage data and see if it is possible to draw some conclusions from some patterns that emerge in it. I don't feel like expressing a personal an opinion at this point on what this data might mean, but I think spikes in Bridge usage could be used do draw conclusions on socio-political happenings. What the script does is it basically looks for spikes in Bridge traffic by giving it a time frame and a factor for triggering the alert. As already said it's just a quick hack so don't expect it to be performing or even well written :P. A couple of neat things that came out: factor | date1 date2 1: users at date1 2: users at date2 (country code) 23.0512820513 | 2011-06-10 2011-05-29 1: 1798 2: 78 (es) 22.0707070707 | 2011-06-10 2011-06-05 1: 4370 2: 198 (it) 4.14 | 2011-06-11 2011-06-04 1: 207 2: 50 (tw) 5.13333333333 | 2011-06-11 2011-06-05 1: 231 2: 45 (ar) 5.42857142857 | 2011-06-11 2011-06-05 1: 836 2: 154 (br) 4.38181818182 | 2011-06-11 2011-06-01 1: 241 2: 55 (il) 16.5208333333 | 2011-02-15 2011-01-18 1: 48 2: 793 (de) 15.4285714286 | 2010-08-23 2010-07-26 1: 648 2: 42 (au) 13.7916666667 | 2011-03-11 2011-02-15 1: 1655 2: 120 (sa) A one liner to get some interesting stats: python bridge-user-alert.py -f 4 | sort -g Hope somebody finds this little research useful, Cheers, Art.

1 0

Re: [tor-dev] license question
by Ted Smith 16 Jun '11

16 Jun '11

On Thu, 2011-06-16 at 16:51 +0200, Frederic Bor wrote: > Hello, > > > Im currently implementing transparent proxying for tor with Layered Service > Provider feature on windows. Microsoft provides a sample to demonstrate how > to implement an empty LSP (this is a lot of work, even to do nothing). This > sample is distributed under the license attached in this email. I have been > advised on #tor-dev to ask here about its compatibility with 3-clause BSD. > > It seems compatible to me but the following restriction may be a problem in > an open source context: > > "You may not [...] modify or distribute the source code of any Distributable > Code so that any part of it becomes subject to an Excluded License. An > Excluded License is one that requires, as a condition of use, modification > or distribution, that: > - the code be disclosed or distributed in source code form, or > - others have the right to modify it." > > The wording "requires, as a condition of use, modification or distribution" > seems to allow to use the sample in tor, since there is no such requirement > in 3-clause BSD. > > Does this seem right to you? You might want to ask licensing(a)fsf.org -- that looks like a clause designed to exclude copyleft licenses, so they'd probably know about it and what effects it would have on non-copyleft licenses.

1 0

license question
by Frederic Bor 16 Jun '11

16 Jun '11

Hello, Im currently implementing transparent proxying for tor with Layered Service Provider feature on windows. Microsoft provides a sample to demonstrate how to implement an empty LSP (this is a lot of work, even to do nothing). This sample is distributed under the license attached in this email. I have been advised on #tor-dev to ask here about its compatibility with 3-clause BSD. It seems compatible to me but the following restriction may be a problem in an open source context: "You may not [...] modify or distribute the source code of any Distributable Code so that any part of it becomes subject to an Excluded License. An Excluded License is one that requires, as a condition of use, modification or distribution, that: - the code be disclosed or distributed in source code form, or - others have the right to modify it." The wording "requires, as a condition of use, modification or distribution" seems to allow to use the sample in tor, since there is no such requirement in 3-clause BSD. Does this seem right to you? Cheers, Frederic

1 0

Thoughts on simplified packaging
by Andrew Lewman 15 Jun '11

15 Jun '11

As I talk to more and more people, they are confused by all of the different software packages we offer. From the simple, "I just want to be a relay, why is this so hard?" to "I just want to safely get to the BBC, I don't care about configuration and such. Can't you just make it a simple download and have it work by default?" I've written down my thoughts at https://svn.torproject.org/svn/projects/roadmaps/proposed-package-roadmap.t…. I'm looking for your thoughts and feedback. The goal is to simplify what we produce and make it easy for people to get the software and configuration they want. -- Andrew pgp 0x74ED336B

4 3