Delivery-Date: Mon, 03 Nov 2014 01:07:25 -0500
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.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID 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 58A411E0BA7;
	Mon,  3 Nov 2014 01:07:23 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id A303831659;
	Mon,  3 Nov 2014 06:07:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id BDBCD3163E
 for <tor-talk@lists.torproject.org>; Mon,  3 Nov 2014 06:07:15 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
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 BEdPfiasgHL0 for <tor-talk@lists.torproject.org>;
 Mon,  3 Nov 2014 06:07:15 +0000 (UTC)
Received: from s2.netcompartner.com
 (lbthomsen-3-pt.tunnel.tserv6.fra1.ipv6.he.net [IPv6:2001:470:1f0a:10f2::2])
 by eugeni.torproject.org (Postfix) with ESMTP id 8FBD0315EB
 for <tor-talk@lists.torproject.org>; Mon,  3 Nov 2014 06:07:15 +0000 (UTC)
Received: from ncpws04.localnet (ncpws04.netcompartner.com
 [IPv6:2001:470:ec48:0:e2cb:4eff:fe3e:11c6])
 by s2.netcompartner.com (Postfix) with ESMTPSA id CA399C053B
 for <tor-talk@lists.torproject.org>; Mon,  3 Nov 2014 07:07:12 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=reclaim-your-privacy.com; s=2014; t=1414994833;
 bh=6klC/gEZMmaLgTWEKeiG6D1cuwNX6FFz/3OnwUZvZQ4=;
 h=From:To:Subject:Date:In-Reply-To:References:From;
 b=KSPNIe0g2qA40JFzQ/aFv5ZlhfuqGMIGZeid/0GcceQ3o4kwCJcq6NYcXXfc/qGp3
 7RRLOGpvgAnfDZPuBARy+c7+Hib2i5GezuaKTe46Y0P5f7QUSo/lPQoY08OpzXYWpk
 zJC/Xda4ydB0BoPEAOtOnleNPo0kneGHjRefsys7fabcttP6ZuDtDf/+xvnJ5mY9zE
 uhdYCyd4HQ40JC2DMsHnUsDzRUV8171cDgcwihzROq5Ph95FoWTHbiUru9QXH/AbLA
 Nx5XhHpnrlfN6JwVq2PfyDkq36DFvzbAB+okil8n2zIFZwUMWN96hsEq8XTZuE8bc8
 eTxdGaKojaZLQ==
From: Lars Boegild Thomsen <lth@reclaim-your-privacy.com>
To: tor-talk@lists.torproject.org
Date: Mon, 03 Nov 2014 14:07:09 +0800
Message-ID: <1992901.RCWOktzqt9@ncpws04>
Organization: Reclaim Your Privacy
User-Agent: KMail/4.14.1 (Linux/3.16-3-amd64; KDE/4.14.1; x86_64; ; )
In-Reply-To: <4932723.DhTOHL3ROZ@ncpws04>
References: <7488606.2oxgLGVBPl@ncpws04>
 <CAJ5w9HXSLfV+FbsA=7WWf2_Hyuo2HYN91PUF92mSAKfixy=TGQ@mail.gmail.com>
 <4932723.DhTOHL3ROZ@ncpws04>
MIME-Version: 1.0
Subject: Re: [tor-talk] Cloak Tor Router
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>

On Sunday 02 November 2014 12:08:15 Lars Boegild Thomsen wrote:
> 1. 100 % Automatic
> 
> The device check at regular intervals if a new binary firmware is available and if that is the case it just updates.  This one is entirely possible and not hard to implement.  I am however not sure I like it.  If someone managed to hijack our domain name that someone could brick all devices in one go.  There is also the possibility of accidental bricking of thousands devices (even Microsoft have released updates that crashed Windows, and Google have screwed up their android updates quite often).  In short - I personally don't like this one but I am willing to stand corrected and be convinced otherwise.
> 
> 2. Automatic update of Tor alone
> 
> This is a bit software as in the binary firmware stays as it is but only the Tor package gets updated.  It's got the same security issues as number 1, but less of a risk of bricking accidentally and a path to recovery IF a bad update was submitted.
> 
> 3. Visual indication of "action needed"
> 
> In our current hardware design we actually included a RGB LED for this very reason.  We could have that flashing RED (and label it "Update needed" on the box) if not up to date but still leave it for the user to update.  I am personally leaning towards this one unless the issues with 1 or 2 can be solved but I am aware that a lot of people won't update.
> 
> 4. Refuse to function unless updated
> 
> Would flash red as in 3 but refuse to run unless the firmware is updated.  I personally think this one is too annoying from a usability point of view.

I thought of another one that might be the best option so far:

5. Have a dedicated status LED that will flash RED if system need upgrade.  I don't like the idea of a fully automatic upgrade, but the device _will_ have a button and it could be that when the RED upgrade LED flashes, the device can be upgraded with a press of the button.  That approach is still to some degree vulnerable to a man in the middle (DNS hijack) attack though.

-- 
Lars Boegild Thomsen
https://reclaim-your-privacy.com
Jabber/XMPP: lth@reclaim-your-privacy.com
-- 
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

