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