[or-cvs] r22631: {arm} Ideas for client mode features (thanks to velope, bja, and S (arm/trunk)

Damian Johnson atagar1 at gmail.com
Tue Jul 13 16:17:14 UTC 2010


Author: atagar
Date: 2010-07-13 16:17:14 +0000 (Tue, 13 Jul 2010)
New Revision: 22631

Modified:
   arm/trunk/TODO
Log:
Ideas for client mode features (thanks to velope, bja, and Sebastian)



Modified: arm/trunk/TODO
===================================================================
--- arm/trunk/TODO	2010-07-13 11:54:49 UTC (rev 22630)
+++ arm/trunk/TODO	2010-07-13 16:17:14 UTC (rev 22631)
@@ -24,6 +24,8 @@
               conn.get_info("config-text")
         [-] conn panel (for version 1.3.8)
           - expand client connections and note location in circuit (entry-exit)
+          - for clients list all connections to detect what's going through tor
+              and what isn't? If not then netstat calls are unnecessary.
           - check family connections to see if they're alive (VERSION cell
               handshake?)
           - fallback when pid or connection querying via pid is unavailable
@@ -106,9 +108,27 @@
     * connections aren't cleared when control port closes
 
 - Features / Site
-  * client use cases
+  * client mode use cases
     * not sure what sort of information would be useful in the header (to
       replace the orport, fingerprint, flags, etc)
+      * one idea by velope:
+        "whether you configured a dnsport, transport, etc. and whether they
+        were successfully opened. might be nice to know this after the log
+        messages might be gone."
+        [notice] Opening Socks listener on 127.0.0.1:9050
+        [notice] Opening Transparent pf/netfilter listener on 127.0.0.1:9040
+        [notice] Opening DNS listener on 127.0.0.1:53
+      * rdns and whois lookups
+        To avoid disclosing connection data to third parties this needs to be
+        an all-or-nothing operation (ie, needs to fetch information on all
+        relays or none of them. Plan is something like:
+        * add resolving/caching capabilities to fetch information on all relays
+          and distil whois entries to just what we care about (hosting provider
+          or ISP), by default updating the cache on a daily basis
+        * construct tarball and make this available for download rather than
+          fetching everything at each client
+        * possibly make these archives downloadable from peer relays (note:
+          this is a no-go for clients) via torrents or some dirport like scheme
     * special page for client related information, such as ips of our client
       circuits at the exit
     * look at vidalia for ideas



More information about the tor-commits mailing list