[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