July 2011 - tor-dev - lists.torproject.org

(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