- tor-dev - lists.torproject.org

Re: [tor-dev] Building TOR using Visual Studio
by teor 18 Oct '14

18 Oct '14

On 17 Oct 2014, at 23:00 , tor-dev-request(a)lists.torproject.org wrote: > Date: Fri, 17 Oct 2014 15:09:38 +0400 > From: Vladimir <vilgeforce(a)gmail.com> > To: tor-dev(a)lists.torproject.org > Subject: Re: [tor-dev] Building TOR using Visual Studio > > VS2013 if free only in Express version, and Express version is limited: > doesn't have a profiler, for example. Moreover, there are limitations for > using Express version, it's written in license. > > I'v attached a diff where I changed a code for VS2008 (tested on ubuntu-64 > gcc 4.8.2 too). Also I changed readme: it contained instruction to run > ./configure, but there's no such file. >

6 6

ooniprobe v1.2.2 is out
by Arturo Filastò 17 Oct '14

17 Oct '14

Hi all, This mail is to inform you that a new version of ooniprobe has just been released. Here is the changelog: v1.2.2 (Fri, 17 Oct 2014) ------------------------- Who said friday 17th is only bad luck? * Add two new report entry keys test_start_time and test_runtime * Fix bug that lead to ooniresources not working properly It is now available for download from pypi: https://pypi.python.org/pypi/ooniprobe and soon will be available for download in debian. Have fun! ~ Arturo

1 0

Building TOR using Visual Studio
by Владимир Мартьянов 17 Oct '14

17 Oct '14

Hi all! I'm new at this list :-) I decided to understand how TOR works and I want to build it in VS to debug it and explore it's internals. I have Visual Studio on my first PC and I got errors during build on address.c. I investigated the reason: commit 0ca83872468af59b94e14fe7fdfcb38cb5a3f496 I have Visual Studio express 2013 on my second PC and I didn't have any problems building the TOR. So I have two questions: did you decide not to support old Visual Studio versions or it'll be better to build TOR in VS2008 too? If old versions aren't supported, should it be some #error directives in sources to explain this decision? It was really hard to understand where's the problem, so I think #error will be very helpfull. If you give me some instructions about the problem, I'll try to commit the changes. Thank you.

4 5

Some ideas on the visualization of OONI data
by kudrom 16 Oct '14

16 Oct '14

Hi all For the last couple of days i've been thinking about the visualization of the bridge reachability data and how it relates to the currently deployed ooni [7] system, here are the conclussions: == Variables == I think that the statistical variables for the bridge reachability reports are: - Success of the nettest (yes, no, errors) - The PT of the bridge (obfs3, obfs2, fte, vanilla) - The pool from where the bridge has been extracted (private, tbb, BridgeDB https, BridgeDB email) - The country "of the ooni-probe" With these variables I believe we can answer a lot of questions related to how much censorship is being taken, where and how. But there's something left: the timing. George sent an email [0] in which he proposes a timeline of events [5] of every bridge that would allow us to diagnose with much more precission how and why is a bridge being censored. To build that diagram we should define first the events that will be showed in the timeline. I think those events are the values of the pool variable and if the bridge is being blocked in a given country. With the events defined i think we can define another variable: - Time deltas between bridge events. So, for example, what this variable will answer is: how many {days, hours...} does it take China to block a bridge that is published in bridgeDB? Is China blocking new bridges at the same speed that Iran? How many days does it take China block a private bridge? There are some ambiguities related to the deltas, for example if the bridge is sometimes blocked and sometimes not in a country, which delta should we compute? Finally, in the etherpad [1] the tor's bootstrap is suggested as a variable, i don't understand why. Is it to detect some way of censorship? Can anyone explain a little more? == Data schema == In the last email Ruben, Laurier and Pascal "strongly recommended importing the reports into a database". I deeply believe the same. We should provide a service to query the values of the previous variables plus the timestamp of the nettest and the fingerprint of the bridge. With this database the inconsistencies between the data formats of the reports should be erased and the work with the data is much more easy. I think that we should also provide a way to export the queries to csv/json to allow other people to dig into the data. I also believe that we could use mongodb just because one reason: we can distribute it very easily. But let me explain why in the Future section. == Biased data == Can a malicious ooni-probe bias the data? For example, if it executes in bursts some tests the reports are going to be the same and the general picture could be biased. Any more ideas? == Geo Data == In the etherpad [1] it's suggested to increase the granularity of the geo data to detect geographical patterns, but it seems [2] that at least in China there's not such patterns so maybe we should discard the idea altogether. == Playing with data == So until now i've talked about data. Now i want to address how to present the data. I think we should provide a way to play with data to allow a more thoughtful and precise diagnosis of censorship. What i was thinking is to enhance the interactivity of the visualization by allowing the user a way to render the diagrams at the same time she thinks about the data. The idea is to allow the user to go from more general to more concret data patterns. So imagine that the user loads the visualization's page, first he sees a global heated map of censorship measured with the bridge reachability test, he is chinese so he clicks in his country and a histogram like [3] for China is stacked at the bottom of the global map, he then clicks on the obfs2 and a diagram like [4] is also stacked at the bottom but only showing the success variable for the obfs2 PT, then he clicks on the True value for the success variable and all the bridges that have been reached by all the nettests executions in that period of time in China are showed, finally he selects one bridge and it's timeline [5] plus it's link to atlas [6] is provided. This is only a particular scenario, the core idea is to provide the user with the enhanced capability to drive conclusions as much as she desires. The user started with the more general concept of the data, and he applied restrictions to the datapoints to dig more into the data. From general to specific he can start making hypothesis that he later discards or approves with more info displayed in the next diagram. There are some usability problems with the selection of diagram+variable and the diverse set of users that will use the system, but i'd be very glad to think about them if you like the idea. == Users == I think there are three set of users: 1- User of tor that is interested in the censorship performed in its country and how to avoid it. 2- Journalist that wants to write something about censorship but isn't that tech savvy. 3- Researcher that wants updated and detailed data about censorship. I believe we can provide a system that satisfies the three of them if we succeed in the previous bullet point. == Future == So, why do i think that we should index the data with mongodb? Because i think that this data repository should be provided as a new ooni-backend API related to the current collector. Right now the collectors can write down reports from any ooni-probe instance that chooses to do so and its API is completly separated from the bouncer API, which overall is a wise design decision because you can deploy ooni-backend to only work as a collector. So it's not unreasonable to think that we can have several collectors collecting different reports because the backend is designed to do so, therefore we need the data repository to be distributed. And mongodb is good at this. If we build the database for the bridge reachability nettests, i think that we should design it to index in the future all nettest reports and therefore generalize the desgin, implementation and deployment of all the work that we are going to do to the bridge reachability. That way an analyst can query the distributed database with a proper client that connects to the data repository ooni-backend API. So to sum up, I started talking about the bridge reachability visualization problem and finished with a much broader vision that intends to integrate the ongoing efforts of the bridge reachability to improve ooni as a whole. Hope the email is not too large. ciao [0] https://lists.torproject.org/pipermail/tor-dev/2014-October/007585.html [1] https://pad.riseup.net/p/bridgereachability [2] https://blog.torproject.org/blog/closer-look-great-firewall-china [3] http://ooniviz.chokepointproject.net/transports.htm [4] http://ooniviz.chokepointproject.net/successes.htm [5] https://people.torproject.org/~asn/bridget_vis/tbb_blocked_timeline.jpg [6] https://atlas.torproject.org [7] https://ooni.torproject.org/

1 0

Prop 237 (Make all relays directory caches) Patch
by Matthew Finkel 15 Oct '14

15 Oct '14

Hi Nick, All, I've made some minor corrections to proposal 237. Mostly these are cosmetic changes, but I did remove some...overstatements, as well. Attached is the patch, but it's only available as a branch in my personal repo[0] as prop237-clarifications. Let me know if you have any comments/suggestions (the overall proposal is unchanged). If not, I'll start implementing this within the next few days. Thanks! Matt [0] https://git.torproject.org/user/sysrqb/torspec.git

1 0

Patches to improve mobile hidden service performance
by Michael Rogers 13 Oct '14

13 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, I've been experimenting with small changes to Tor to improve the performance of mobile hidden services. The following patches for Tor and jtorctl make two performance improvements: 1. Each time the network's enabled, don't try to build introduction circuits until we've successfully built a circuit. This avoids a problem where we'd try to build introduction circuits immediately, all the circuits would fail, and we'd wait for 5 minutes before trying again. 2. Added a command to the control protocol to purge any cached state relating to a specified hidden service. This command can be used before trying to connect to the service to force Tor to download a fresh descriptor. It's a more fine-grained alternative to SIGNAL NEWNYM, which purges all cached descriptors and also discards circuits. https://code.briarproject.org/akwizgran/briar/blob/9e5e2e2df24d84135f14adaa… https://code.briarproject.org/akwizgran/briar/blob/9e5e2e2df24d84135f14adaa… The Tor patch is based on the tor-0.2.24 tag, and the jtorctl patch is based on the Guardian Project's repo, which is ahead of the upstream repo (n8fr8 needs commit privileges for upstream, I think). https://github.com/guardianproject/jtorctl I've only done small-scale testing of these patches so far. If they seems like they might be useful I'll create a trac ticket to merge them. Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJUM6W7AAoJEBEET9GfxSfM5FkIAL+gPk2ZmGvSnt/gVQGZwqH5 mpqGoPIfZPycfhm/dgOjE4MSANcGo7kTqnh85ir9TQvjtNAEkfkTL7GB9G+DOd2X ghje+HCWNRU8WlFD27rrxSUzT+8IvfVaJaj+sCYtA44ib3qpz4XXKXee8xTW2epV dnCLtW7TBUjQEHqbL0aGtsKEHvgVQcLWPxusEioefBPXo6a+8cRKLY+EJvqxaMze mdOQBh+wa7SIyMQi4JqgzjtKAoAqpVzXYsIrmxT1hlCOOaNDjbFUN35QbrZMT6B+ zNCuWIIC6JfBWccfxDsAew2MC8WNf05nvgM67cTFU2nCI6MwYYf4x2xtEOcA5qs= =LweI -----END PGP SIGNATURE-----

4 5

Optimising Tor node selection probabilities
by Steven Murdoch 13 Oct '14

13 Oct '14

I’ve just published a new paper on selecting the node selection probabilities (consensus weights) in Tor. It takes a queuing-theory approach and shows that what Tor used to do (distributing traffic to nodes in proportion to their contribution to network capacity) is not the best approach. Counter-intuitively the paper shows that some of the slowest nodes should not be used at all, because if they are used they will slow down the average performance for all users. The proportion of nodes which shouldn’t be used depends on the relationship between network usage and network capacity, so will vary over time. It’s not clear that there is a closed-form solution to the problem of calculating node selection probabilities (I couldn’t find one), but this paper shows that the optimisation surface is convex and so gradient-based optimisation methods will find the global optimum (rather than some local optimum which depends on the starting position of the optimisation process). Although the process outlined in the paper requires knowing the relationship between network capacity and usage, it isn’t highly sensitive to minor inaccuracies in measuring this value. For example if it is assumed the network is loaded at 50% then the solution will outperform Tor’s old approach provided the true network load is between 0% and 60%. After this work was done, Tor moved to actively measuring the network performance and manipulating the consensus weights in response to changes. This seems to have ended up with roughly the same outcome. The advantage of Tor’s new approach is that it doesn’t require knowing network usage and node capacity; however the disadvantage is that it can only react slowly to changes in network characteristics. For more details, see the paper: http://www.cl.cam.ac.uk/~sjm217/papers/#pub-el14optimising Note that this is published in IET Electronics Letters, which is a bit different to the usual Computer Science publication venues. It jumps straight into the maths and leaves it to the reader to understand the background and implications. The advantage is that it’s 2 pages long; the disadvantage is that to understand it you need to know a reasonable amount about Tor and queuing theory to make much sense of it. Best wishes, Steven

2 2

Re: [tor-dev] Optimising Tor node selection probabilities
by teor 12 Oct '14

12 Oct '14

On 11 Oct 2014, at 23:00 , tor-dev-request(a)lists.torproject.org wrote: > Date: Fri, 10 Oct 2014 14:33:52 +0100 > From: Steven Murdoch <Steven.Murdoch(a)cl.cam.ac.uk> > To: tor-dev(a)lists.torproject.org > Subject: [tor-dev] Optimising Tor node selection probabilities > Message-ID: <FDECA8F4-5F99-4738-8391-CD60D156D774(a)cl.cam.ac.uk> > Content-Type: text/plain; charset=windows-1252 > > I?ve just published a new paper on selecting the node selection probabilities (consensus weights) in Tor. It takes a queuing-theory approach and shows that what Tor used to do (distributing traffic to nodes in proportion to their contribution to network capacity) is not the best approach. > > Counter-intuitively the paper shows that some of the slowest nodes should not be used at all, because if they are used they will slow down the average performance for all users. The proportion of nodes which shouldn?t be used depends on the relationship between network usage and network capacity, so will vary over time. > > It?s not clear that there is a closed-form solution to the problem of calculating node selection probabilities (I couldn?t find one), but this paper shows that the optimisation surface is convex and so gradient-based optimisation methods will find the global optimum (rather than some local optimum which depends on the starting position of the optimisation process). > > Although the process outlined in the paper requires knowing the relationship between network capacity and usage, it isn?t highly sensitive to minor inaccuracies in measuring this value. For example if it is assumed the network is loaded at 50% then the solution will outperform Tor?s old approach provided the true network load is between 0% and 60%. > > After this work was done, Tor moved to actively measuring the network performance and manipulating the consensus weights in response to changes. This seems to have ended up with roughly the same outcome. The advantage of Tor?s new approach is that it doesn?t require knowing network usage and node capacity; however the disadvantage is that it can only react slowly to changes in network characteristics. > > For more details, see the paper: > http://www.cl.cam.ac.uk/~sjm217/papers/#pub-el14optimising > > Note that this is published in IET Electronics Letters, which is a bit different to the usual Computer Science publication venues. It jumps straight into the maths and leaves it to the reader to understand the background and implications. The advantage is that it?s 2 pages long; the disadvantage is that to understand it you need to know a reasonable amount about Tor and queuing theory to make much sense of it. > > Best wishes, > Steven This is fantastic, Steven - and although we've changed Tor's consensus weights algorithm, we still waste bandwidth telling clients about relays that wold slow the network down. Your result further supports recent proposals to remove the slowest relays from the consensus entirely. teor pgp 0xABFED1AC hkp://pgp.mit.edu/ https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 http://0bin.net/paste/Mu92kPyphK0bqmbA#Zvt3gzMrSCAwDN6GKsUk7Q8G-eG+Y+BLpe7w…

2 1

Tor Metrics website redesign
by Karsten Loesing 11 Oct '14

11 Oct '14

Hi everyone, I started redesigning the Tor Metrics website and would like to hear your opinion. The most recent version of the redesign is available here: https://kloesing.github.io/metrics-2.0/ This is a non-functional design prototype in an early development state. Each page contains a note at the bottom that explains what design decisions were made. For reference, here's the current Tor Metrics website: https://metrics.torproject.org/ Feedback much appreciated. This is the perfect time to consider your ideas. Thanks! All the best, Karsten

1 0

hidden service???
by EBOLA 11 Oct '14

11 Oct '14

is hidden server hack possible ? plase respon t y

2 1