<div class="gmail_quote">On Fri, Jun 10, 2011 at 3:54 PM, Runa A. Sandvik <span dir="ltr"><<a href="mailto:runa.sandvik@gmail.com">runa.sandvik@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, Jun 10, 2011 at 12:55 PM, <<a href="mailto:andrew@torproject.org">andrew@torproject.org</a>> wrote:<br>
> On Mon, May 30, 2011 at 01:56:25PM +0100, <a href="mailto:runa.sandvik@gmail.com">runa.sandvik@gmail.com</a> wrote 2.9K bytes in 75 lines about:<br>
> : The whole point with the Torouter is to allow more people to run a<br>
> : bridge or a relay, so I see a web interface as something mandatory. So<br>
> : yeah, we'd have to make sure that the interface is secure.<br>
><br>
> Right, so we have two torouters, an expert model which is the dreamplug,<br>
> and a non-expert model which is the excito.<br>
><br>
> Experts use ssh and follow some instructions for configuring their<br>
> device. Plus, they get some cheap hardware to do whatever else they<br>
> want to do with it.<br>
<br>
</div>Do you think we should ship the plugs as they are, or should we<br>
re-flash and harden first?<br>
<div class="im"><br></div></blockquote><div><br></div><div>I think we should re-flash with an OS that makes hardening a priority. We should only harden the OS in the sense that we should strip out anything that we do not require for our uses. Debian and Ubuntu both have compiler hardening flags enabled by default but in general, I'd consider Ubuntu's userspace to be proactively improved and their kernel ships with quite a few security improvements. I'm not sure about the kernel status for Debian or who is proactively working on security in Debian.</div>
<div><br></div><div>In either case, the very old version of Ubuntu on the DreamPlugs is worse than modern Debian or modern Ubuntu; we should not ship the plugs without an OS update at the *very* least.</div><div><br></div>
<div>I think that we should probably setup a hidden service on each one and ensure that we can remotely administrate them with the consent of the testers. This will help us to perhaps make some of these choices differently down the road.</div>
<div> </div><div>I think the user experience should be that they plug in the router, it auto-configures the upstream firewall/NAT device if possible and that's it. If the NAT device can't be configured, I propose we use some common ports so that our instructions to people are basically generic and easy for everyone to follow.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> Non-experts get the excito with the web interface: point, click,<br>
> configured, done.<br>
><br>
> I have 10 dreamplugs with US power config arriving soon. Once Excito<br>
> has their new version ready, we can get 10 of those. Then we find 20<br>
> volunteers willing to test the default configs and provide feedback. In<br>
> exchange, they get to help censored users and get free hardware.<br>
<br>
</div>We should probably discuss how we want users to provide feedback and<br>
what kind of data we'd like to see (i.e. we want more feedback than<br>
just "yay, it works" or "it doesn't work and I'm giving up").<br>
<div class="im"><br></div></blockquote><div><br></div><div>I think a mailing list and an open bug report or ten is a good idea. Also, a wiki page that explains how the devices operate from a user perspective. This page should be different from the how-we-build-it wiki page.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> Rather than arguing about web interfaces that do not exist, we should be<br>
> figuring out how to update the routers, make sure new tor packages are<br>
> updated timely, and how to handle support issues from the simple "it<br>
> doesn't work, at all" through "your router ate my cat and soured my<br>
> milk".<br>
<br>
</div>We're going to need a web interface sooner or later, and I guess users<br>
will also start asking about client mode and a hidden service at some<br>
point. But we don't need all that to kick off the test phase.<br>
<br></blockquote><div><br></div><div>Well, I think we can easily push out a wifi network that is transparently sent via Tor and if users want that, we can provide it easily. I do not think we should offer a remote client other than this without some security discussions.</div>
<div><br></div><div>Again, I think we should enable OpenSSH on localhost and add a hidden service to connect to it. This should enable us to remotely test things on a router and see where it fails.</div><div><br></div><div>
We don't need a web service when we launch, although I do believe it is good to discuss the requirements.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
How to update the routers:<br>
<br>
- Excito: they roll out their own software updates and users can<br>
point-and-click to update via the interface.<br>
<br></blockquote><div><br></div><div>They do not yet have a Tor package with tor-fw-helper, we need to make some packages of 0.2.3.x for this to happen, I think. Perhaps weasel can tell us of the best way to make this happen? I suspect we'll need to use a B3 device as a build machine and we'll also need the explicitly have packages for these devices.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
- DreamPlug: good question, I wonder if users would have to re-flash<br>
with a new image.<br></blockquote><div><br></div><div>The users should not do anything about re-flashing. We will have about two dozen and we should just reflash them, it's easy.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Make sure new Tor packages are updated timely:<br>
<br>
- Excito: we'll need to drop them an email whenever there are new<br>
packages available so that they can update the Excito package repo.<br>
Users can also add the torproject Debian repo to their<br>
/etc/apt/sources.list if they don't want to wait for Excito.<br>
<br></blockquote><div><br></div><div>I think we should ask Excito to ship with our repo or commit to pulling in our packages for their repo. Will they do this?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
- DreamPlug: default OS is Ubuntu, so I guess users will want to add<br>
the torproject Debian repo to their /etc/apt/sources.list. Or we can<br>
do it for them.<br>
<br></blockquote><div><br></div><div>The user should not consider this a general purpose Ubuntu device, they should consider it a Tor bridge/router device that happens to run Ubuntu or Debian. We should configure it for them and they shouldn't have to think about it beyond perhaps removing bandwidth limits. :-)</div>
<div> </div><div>We should probably include apticron and automatically update packages on these routers. I trust the Debian Q&A process and I do not believe it will result in bricked routers; anything less will result in a lot of collective sysadmin time that none of us have and that we should not expect our users to even comprehend unless they *want* to understand it.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
How to handle support issues:<br>
<br>
We should probably set up a mailing list, such as torouter@lists... I<br>
already have a B3 and a DreamPlug, so I should be able to reply to<br>
most (if not all) of the support requests.<br>
<font color="#888888"><br></font></blockquote><div><br></div><div>That sounds good. I will also help with this list.</div><div><br></div><div>All the best,</div><div>Jake</div></div>