Re: Questions about gathering information and statistics about the tor-network
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Sebastian, Sebastian Schmidt wrote: That's about how geolocations of directory users can be collected right now. This sounds interesting. Can those informations be questioned somehow from the dir-servers or are they non-public? It's not that these data are non-public, but there is currently no way to request them from the directory servers. And unfortunately, I don't have a good sample at hand, as I don't collect these data right now. But I think you should be able to generate them on a directory mirror, too. Have a look at the DirRecordUsage* config options (grep for them in the code). You may also need to configure --enable-geoip-stats. Those stats you gathered about the bridges here are really interesting! Since I read it I'm thinking how to interprete them. It looks like we have already many bridges for the short time they are supported in stable tor but just a small number of overall traffic (based on the bandwith consumption) on them. This could be intresting for people who want to support the network because they don't need to setup a 4TB-root for running a bridge. Correct. Often, bridge admins are disappointed that they don't help Tor 'enough', because they see so little bandwidth. But people who don't have much bandwidth to share do help the network by setting up a bridge. As Roger has stated several times, bridges might become even more useful in the future. So it's good to already have a solid number of bridges when they are needed. Also most users seem to be germans/americans and not people of countrys one would think who would be the number one. I'm thinking why? Afaik no provider in germany restricts the access to tor. Do people use bridges because they think this extra hop increases their anonymity instead of letting the bandwith for the people who really needs them? One explanation that comes to mind is that some corporate filtering systems make it necessary to use bridges. I would have to look this up in the spec, but I think there is no anonymity gain by using bridges in terms of an 'extra hop'. Bridges replace the first node in a circuit, so that circuit are 3 hops long, too. Well there are many interesing information which could be gathered without touching users anonymity at all. In contrast there are information which needs to be collected to protect their anonymity. Stats like the sudden increase of nodes in a fascist country like e.g. burma,china and so on shouldn't happen without people noticing it. For the beginning I want to get all the interesting information out of the service-descriptors and make them visible. Starting with the descriptors is a good idea. You can collect them with Peter Palfrader's directory archive scripts in the contrib/ directory. Have you already thought about a good way to present the data? I think best would be a dynamic solution so one gatheres all the information and users can throw exactly the information they want in one pot which they want to see joined in one graph for a timeline they can choose. But I don't know any good framework which offers this. At the moment I just found cewolf(http://cewolf.sourceforge.net/new/index.html) and I don't know if it fits the needs of which I'm thinking off. So I think gathering the already available information is more easily than finding a good way to make them easily public for the average user. Right, making data available might turn out to be difficult. I haven't looked at specific frameworks, yet. One option would be to integrate more graphics into TorStatus (http://trunk.torstatus.kgprog.com/). Kasimir Gabert did a great job displaying bandwidth histories for the past day, week, month, and so on. Maybe these graphics can be extended, given that we have good data to present. I'll be really busy the next month but as soon as I have something to show I'll let you know! Ah, the exam phase? :) If so, good luck with that! Thanks! - --Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJcx3N0M+WPffBEmURAvZlAKDOXtUQbbZ4weziWOD3q67HjjfFqgCeK8uN DXLHN9/NlBZp/dLd1wW2Wq4= =i68w -END PGP SIGNATURE-
Re: TBB on XP again
Hi Mikel, By chance have you used any virtual machines on the host OS that runs your NIS firewall? There are two networking modes I'd be curious about. The first being a 'bridged' networking interface. The second being a 'NAT' networking interface. I would think that 'bridged' networking would not be affected by NIS on your local system, and would be able to operate on the network without restrictions, since it appears as a completely separate device on the network. I'm curious about a NAT'd interface though. I would think that is would be affected by NIS, since all traffic would pass through the host OS before entering the network. For my day job, I managed a global VM infrastructure. One of my duties is to make sure all the VM's stay up-to-date with the latest security patches for the different OS's . I've noticed that the securities measures that allow the company to audit who is doing what can be easily bypassed if a VM is brought online and doesn't have the proper management software installed. (However, network audits catch this within 24 hours.) This can be good or bad depending which side of the fence you're on. Perhaps in your case it might be good to use a VM that has a 'bridged' network interface to try and avoid NIS? If you don't have admin level access, then you are probably stuck using a NAT'd network interface for your VM. The other advantages of using a VM with a 'bridged' network interface in a restrictive or monitored environment is: 1) Process auditing will only see that a VM was run (qemu.exe or vmplayer.exe) in the audit logs. (So what ran in the VM? Who knows... ;-) 2) Network auditing on the HOST OS will not see a direct connection between your VM's traffic and the HOST OS. 3) You can keep it with you on a USB flash drive. Maybe even a Live CD with a VM on it? 4) Use OS encryption on the VM itself to protect your VM in the event it becomes remotely audited, copied, or stolen. Just my two cents worth... Best regards, - Kyle On Sat, Jan 17, 2009 at 11:52 PM, mikel.ander...@juno.com mikel.ander...@juno.com wrote: All, Well I'll be a monkey's uncle! Turns out both non-admin accounts had their NIS accounts set to the more restrictive Teenager level. TBB was stalled waiting to be granted access by the NIS firewall. Adult level users are notified about each request and may grant or deny each one. Users with more restrictive levels are not even notified. Even with the correct account levels systems like mine are going to leave tracks in the firewall. TBB leaves a set of three tracks(tor, firefox, and polipo) for each user account on which it is successfully run. Furthermore, this demonstrates how easy it would be to block the use of portable browsers on any kind of public computer. Mikel Domain Registration - Click Here http://thirdpartyoffers.juno.com/TGL2141/fc/PnY6rw2XOfrwnqKJ8WABRu5NQ1EXUAmPNLBmG6Ort3CeuL2PeaQid/
feedback on police inquiry — France
Hi. We (globenet.org) have been operating a tor exit node (tor.globenet.org == nickname globenet) for 18 months, with the default policy and 2Mbs throttling. Two months ago, we received our first official letter from a local police administration. I copy hereafter the relevant parts of this letter and our answer, as it may be interesting for other french tor node operators. POLICE REQUEST [FR] [...] Nous vous demandons de bien vouloir nous fournir les coordonnées de l'abonné correspondant à l'adresse IP 80.67.172.19. [...] POLICE REQUEST [EN ROUGH TRANSLATION] [...] We ask you to provide us details about the subscriber of the 80.67.172.19 IP address. [...] OUR ANSWER [FR] [...] En ce qui concerne l'objet de votre requête, nous ne sommes pas en mesure d'y répondre car cette adresse IP correspond à un relai tor; il s'agit d'un réseau mondial de relais Internet, utilisés par une grande variété de personnes (journalistes, blogueurs, défenseurs des Droits l'Homme, agents d'application des lois, soldats, entreprises, simples citoyens) pour se protéger contre l'analyse de trafic internet. Le site web de ce réseau[1], ou cet article de Reporters sans Frontières[2], pourront peut-être vous en dire plus. [1]http://www.torproject.org/index.html.fr [2]http://www.rsf.org/article.php3?id_article=14980#5 Vous pouvez vérifier le statut de ce serveur et de cette adresse IP sur la page web suivante: http://torstatus.kgprog.com/index.php?CSInput=tor.globenet.org Ainsi, cette adresse IP ne correspond pas à un abonné identifiable, mais est utilisée chaque jour par plus de 1 internautes dont nous ne pourrions connaître, tout au plus, que la précédente adresse dans le réseau tor décrit ci-dessus, adresse très probablement située dans un autre pays. [...] OUR ANSWER [EN ROUGH TRANSLATION] [...] Regarding the subject of your request, we are not able to respond because this IP address is a tor relay; it is a global network of Internet relays, used by a large variety of people (journalists, bloggers, human rights defenders, law enforcement agents, military, business, simple citizens) as a protection against the Internet traffic analysis. The website of this network[1] or this article from Reporters Without Borders[2], might tell you more. [1] http://www.torproject.org/index.html.fr [2] http://www.rsf.org/article.php3?id_article=14980 # 5 You can check the status of the server and the IP address on the following webpage: http://torstatus.kgprog.com/index.php?CSInput=tor.globenet.org Thus, the IP address is not associated to a a subscriber but is used daily by more than 10,000 Internet users from who we may know, at most, only the previous address in the tor network described above, address most likely in a foreign country. [...] -- Nil signature.asc Description: Digital signature
