Fwd: [tor-talk] Cloak Tor Router
---------- Forwarded message ---------- From: coderman <coderman@gmail.com> Date: Sat, 1 Nov 2014 12:42:41 -0700 Subject: Re: [tor-talk] Cloak Tor Router On 11/1/14, Lars Boegild Thomsen <lth@reclaim-your-privacy.com> wrote:
... We - the team behind Cloak - and me (the networking and embedded Linux guy in the team) are genuinely concerned about privacy and we really would like this product to ...
first question, did you contact Tor Project Inc. about this for their input? (if yes, what was their take on your aims?)
The first step was to isolate the Tor/Cloak related stuff from my internal source tree and actually put a builtable source online on Github. That is currently available here: https://github.com/ReclaimYourPrivacy.
the majority of these repositories are forks of existing public projects, but not clearly so. (e.g. cloak-routing is a selection of specific OpenWRT packages, eschalot, etc.) what do you think of branching from upstream repositories, and keeping your changes in a manner that upstream would be encouraged to incorporate? i have more feedback on code itself, but this is foremost to mention.
Second step was to document the hardware development to convince everybody (hopefully) that we _are_ actually capable of having a device such as this manufactured at a competitive price. Most of that documentation went on our web-site (https://reclaim-your-privacy.com) and schematics/PCB design on Github (same url as before).
i approve of open hardware approach very much :) perhaps useful to identify what is open (like PCB) and what is not (Atheros)
I had already (9 month back) come up with some sensible firewall rules that would pretty much force all TCP traffic through Tor and since I had been running it for 9 month it was at that time fairly well tested
obviously this is not difficult, but it is also more complicated than just "some sensible rules". e.g. https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy and iptables -A OUTPUT -m conntrack --ctstate INVALID -j DROP and all the other intricacies...
... at that time we could generate a random root password and WiFi key, flash that to a small dedicated R/O partition on the flash, print it on a label attached to the box (along with Serial number and MAC address).
it would also be great if you could introduce some per-device unique entropy seed, obtained from a strong hardware based random number generator. (how better to signal your interest in utmost privacy, even if practical benefit is less concrete? :)
First of all, I would like to hear more opinions about the value of a device such as this.
the concept of a portable Tor proxy hardware router that fits in your pocket is great, in my not so unbiased opinion :)
I realize that most technically adept people will frown on a a "toy" such as the Cloak,
what technical people will frown on is the way the device is presented to users, and if users are placed into risk by technical errors.
but this device is really not meant for anybody who can install the Tor software on their own or someone who can install Tor on a Rasberry Pi.
that's fine; i believe it is possible to make a device that is transparently usable that also doesn't put users at needless risk, if that is what you are getting at. the suggestions others have made that i second: - block accidental Tor over Tor setups. - provide a Tor Browser on the supported platforms with TOR_TRANSPROXY=1 - provide automated builds, so that users can keep their device up to date easily, or use a built-in mechanism to obtain and install the latest easily. in general, some guidelines that me as a technical person would like to see: - the device should fail safe, rather than fail open: if i accidentally connect my friend's windows XP laptop to your device, it should block rather than allow all by default. - support robust stream isolation, beyond what may be default. perhaps IsolateDestAddr and IsolateByClientAddr on TransPort (this does not yet exist, but you could code it to the benefit of all Transparent proxy consumers :) --- regarding your other information: from your kickstarter, "We commit to establish and operate new exit nodes, to ensure that we are pulling our weight. Tor is currently at approx 2000 users per exit node. For every 1000 devices we ship, we will establish a new dedicated exit node. " why the focus on number of exit nodes, instead of contributed exit capacity? you're measuring the wrong thing here. --- i have more feedback, but your responses to these questions will help me determine how much time i can contribute to an evaluation. best regards,
participants (1)
-
coderman