> On the other hand the "protocol audit" mess is even worse. This 'mess' doesn't seem to have anything to do with Tor, nor is it Torproject's responsibility to do any such audit on any app other than Tor itself, or by extension those it maintains or chooses to partner with.
As said before, torsocks/proxychains/etc are just hooks invented to catch certain types of network system calls so you don't have to go around patching a socks5 client into thousands of apps that should have had it anyways or deploying packet rules and jails. Yes, it would be great if all apps supported an optional: './app --socks5=host:port' argument. But if the app speaks anything other than TCP + UDP-DNS, trying to get it to work with Tor is useless anyways. And that's not Tor's problem either. Yes, you can run Tor+ocat, or Phantom, or i2p+ocat. At which point you give up exit functionality to gain a useful new hidden world. The solutions to this faux 'mess' are exactly what people are doing today: - Beg the app coders to put and maintain socks5 in the apps that use just TCP + UDP-DNS. Also beg apps to be able to bind to a specific address, not just '*'. - Use packet filters and jails to redirect everything. - Make sure preloads do something with all possible calls(2). You don't need a 'Tor lib' because: - All it would do is effectively what a preload does via socks5, because you haven't cited an application use for any of the native Tor functions such a lib would bring to an app. - You can probably make do with the features Tor is growing regarding multiple SocksPort's. - You still need the app coders to code in the bits for './app --tor=host:port' and such enhanced functions anyways. - You're still limited to TCP + UDP-DNS. - And it makes no sense to have this Tor lib be full enough to talk to Tornet without the separate Tor daemon, it's just not efficient beyond one instance. And that's just at the network layer. The payload layer address gotchas (ie: FTP, torrent) aren't Tor's responsibility either. >> I2P is a bit hard to use with your app of choice, even Tor is that >> way in some cases. > I suspect being based on Java is a major show stopper. The problem is not Java. It's that with the sole (known?) exception of Phantom and its native IPv6 interface, the rest of the entire anonymous network space has not been designed (lack of thought due to forebearing art?) to allow common apps to bind to and route packets in and out of them. Nothing you can do in the long run but redesign the front end those networks expose to the user. And to further redesign their insides if you want exits and/or exit binds. Because expecting the world (IETF, POSIX, etc) to change its protocols for you and your secret internets just isn't going to happen anytime soon :) > There are actually more applications designed for i2p than > designed for Tor. I would question if it's not better to put those coding resources towards making the above changes in anon networks and/or towards spreading them across the already written popular apps in order to make them work with the anon networks. > Look into the TorifyHOWTO. > https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO I don't agree with telling everybody using Unix command line email software is 'old advice' and that they should instead use webmail. Of course if I thought said software was going to go down some rare case code path and fire off a SOCK_RAW, it would be different. But we know that's not the case with this class of software. Only with your popular windows binary app of the day, and trojans, for which Tor is again not responsible to check for. _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
