Delivery-Date: Mon, 13 Oct 2014 00:57:41 -0400
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 041281E0CB1;
	Mon, 13 Oct 2014 00:57:40 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 5F75531427;
	Mon, 13 Oct 2014 04:57:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 5200A31420
 for <tor-talk@lists.torproject.org>; Mon, 13 Oct 2014 04:57:32 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at eugeni.torproject.org
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id wMxagTbnkQV7 for <tor-talk@lists.torproject.org>;
 Mon, 13 Oct 2014 04:57:32 +0000 (UTC)
Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com
 [209.85.220.170])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 267F9313AE
 for <tor-talk@lists.torproject.org>; Mon, 13 Oct 2014 04:57:32 +0000 (UTC)
Received: by mail-vc0-f170.google.com with SMTP id hy10so5362628vcb.1
 for <tor-talk@lists.torproject.org>; Sun, 12 Oct 2014 21:57:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:in-reply-to:references:date
 :message-id:subject:from:to:cc:content-type;
 bh=OOMeZxHlfaR0KspVu2RRokuyeajuzNT251tTxjX36Mg=;
 b=iphQ0trPR/CADHfyRe/yW6fT8kvcBZBE8FjrKNe2EEcDTj/4s/dvu+ZjAxHzWIp0uv
 oQB8R0ZS643/xZCcqX1zdkrlk4545//TntYkZhQEELgGFFNdhzUp2tZCIMXNC9OWvqST
 OtbksgdmBMgQDzgXgi/MhAhYXVLORqqOeZbuKYpWoTIHfScWPVxs6cq4omNmbHryIEKY
 CNCgn+Q4JYC0CSDWHdRTbi5XDxySjpvkOqbpFrTPPXuI1uVSjhlhv9dD4+NaqN9y9bew
 SzxwK43XAzCtEMlza+B5J6U7TlXkWPOntf5mGClG5Jmy4hoZdrVAkG99bDEoIPtLMwMr
 h9NQ==
X-Gm-Message-State: ALoCoQmlMVWAXKKRqC3Nr+5GjruDnm2lf87gbswKoxfAjJ17UA519Avw/HiO17+Ox50wmWY1h2pG
MIME-Version: 1.0
X-Received: by 10.221.63.74 with SMTP id xd10mr480780vcb.26.1413176249684;
 Sun, 12 Oct 2014 21:57:29 -0700 (PDT)
Received: by 10.220.40.2 with HTTP; Sun, 12 Oct 2014 21:57:29 -0700 (PDT)
In-Reply-To: <CANLPe+Nd+FonS8+x+DEKZB6BZmCVWBqYk01pG-_TCVu=o34j+A@mail.gmail.com>
References: <597899488.3907271413062124086.javamail.root@ip-10-181-20-37.ec2.internal>
 <719492467.3957621413068678816.javamail.root@ip-10-181-20-37.ec2.internal>
 <canlpe+m-mqkbxc3jah5oggra7j-7ju-kj0tzj0z1ms8r0apgng@mail.gmail.com>
 <20141011231732.ge54413@moria.seul.org>
 <canlpe+nlookeocoyk6npy2tdzs+gmpyzqdntiyyqfphitwpvng@mail.gmail.com>
 <44BDACD3189.00000851beatthebastards@inbox.com>
 <c89dfc787bb0b5459316f6baaf85022a@cryptolab.net>
 <9e34afb55dc79c67e72a35f9faa431d0@cryptolab.net>
 <CANLPe+M7utUa9Q=MzoC1E_tYkGg9WCK_ERGbAup20X8VbLkcpw@mail.gmail.com>
 <1c79d806d7a7d71f7ca3b00a10042591@cryptolab.net>
 <CANLPe+Nd+FonS8+x+DEKZB6BZmCVWBqYk01pG-_TCVu=o34j+A@mail.gmail.com>
Date: Mon, 13 Oct 2014 13:57:29 +0900
Message-ID: <CANLPe+NKhibmDDen_XUYgU_5pimjKggS0y3mTYBxWj9WRfiM5Q@mail.gmail.com>
From: Casey Rodarmor <casey@rodarmor.com>
To: Griffin Boyce <griffin@cryptolab.net>
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Cc: tor-talk@lists.torproject.org
Subject: Re: [tor-talk] Tor Relay Smartphone App
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

I just thought of an additional perk: The custom distro could blacklist
known-bad hardware. Some random linux user will probably be pretty annoyed
if their computer doesn't work when they just want to do some non-sensitive
task, but someone installing the Tor custom distro would probably be happy
to be presented with a message like "I think your hardware or firmware is
compromised with a backdoor or surveillance mechanism. <insert identifying
information of device>. Please rip it out, stomp on it, put in a new
component from a different vendor, and reboot. Don't worry user, it isn't
your fault, the internet still loves you."

On Mon, Oct 13, 2014 at 1:35 PM, Casey Rodarmor <casey@rodarmor.com> wrote:

> On Mon, Oct 13, 2014 at 1:07 PM, Griffin Boyce <griffin@cryptolab.net>
> wrote:
>
>> There are lots of issues with hardware projects and it costs an obscene
>> amount of money -- not to mention the implications on security and
>> anonymity that it would introduce.
>>
>
> Do you think there's any way it could be done without creating said
> problems for security and anonymity? Perhaps by just publishing an open
> spec and the auto-booting relay image and letting hardware manufacturers,
> totally independently, produce and sell designs that conform. A conforming
> design is just one that meets the hardware spec and that the manufacturer
> claims will successfully run the image without any user intervention. The
> Tor project simply trademarks a logo and phrase, like "Tor Awesomeness
> Compliant" and a cute cartoon onion, and makes sure that no designs that
> are under spec or don't run the image use the slogan. They also make sure
> that anyone that uses the phrase also always includes a message like "The
> Tor Awesomeness Compliance mark and associated image of Vidalita, the
> adorable privacy respecting chibi-onion, does not mean that this machine is
> individually tested or certified by the Tor Project. It may have security
> flaws or back doors." so manufacturers can't claim or represent that its
> machines are known secure, just that they can run the image and be a good
> relay. This might still create problems if ne'er-do-wells might intercept a
> whole bunch of computers in the mail that they know are only being used as
> tor nodes. It might not create problems if the certification and image is
> popular, and tons of computers are certified that have tones of other
> possible uses.
>
>
>>  Create a disk image of a free operating system that boots and tries to
>>> run the best node it can with whatever hardware it happens to have. It
>>> might also try to upgrade and apply security patches to the operating
>>> system and get the latest version of tor.
>>>
>>
>>   This could work, but would need a maintainer.
>
>
> So, just totally totally hypothetically, not trying to sign up for yet
> another project that I don't know if I have time for, I could maybe be the
> maintainer for such a thing. I'm a programmer, an ex site reliability
> engineer, and have some experience with both low-level programming and
> keeping unix systems running. However, I am not a security, privacy, or
> anonymity expert, so I would need the support of Very Clever People whose
> advice I could rely on to tell me what to do, and how to patch any horrible
> security vulnerability bugs that my horrible shell scripts might have.
> Hopefully the extra surface area of such a distro would be very small, just
> a few extra scripts and config files, so there wouldn't be a ton to audit.
>
>
>> Lots of hosts have pre-made images for other uses, and there are projects
>> like VirtualBoxes[2] that might be good places to distribute these.  An
>> easier way would probably be to use something like a python/bash script or
>> an ansible playbook to install dependencies, set permissions, and detect
>> speed to configure the torrc.
>
>
> That's a good idea, but I think that hardware compatibility is a big issue
> here, especially for non-technical users who might not be able to find and
> install linux drivers for whatever strange hardware that they have. A
> custom image that can control all dependencies and have full permissions to
> fetch and install whatever drivers it needs would probably get many more
> good nodes onto the network, with much less confusion from users. It's also
> possible that an image like that could be more aggressive trying to get the
> node online, and just use more resources if it knows that it's not running
> on a box which is used for anything else. Like, it could use all disk
> resources without worrying about starving anyone else, create and delete
> users, and generally just assume that it's the only thing running. Would be
> a great way to make it as simple as possible, and also provide a way for
> people to sunset their old, but still usable boxes without hassle.
>
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

