Delivery-Date: Thu, 19 Feb 2015 17:46:52 -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.8 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	RP_MATCHES_RCVD,URIBL_BLOCKED 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 CD1C81E1088
	for <archiver@seul.org>; Thu, 19 Feb 2015 17:46:50 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 3A75D3275C;
	Thu, 19 Feb 2015 22:46:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 9026431D4C
 for <tor-talk@lists.torproject.org>; Thu, 19 Feb 2015 22:46:42 +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 uwOLhIgLP8wz for <tor-talk@lists.torproject.org>;
 Thu, 19 Feb 2015 22:46:42 +0000 (UTC)
Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com
 [209.85.217.182])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 10E6732603
 for <tor-talk@lists.torproject.org>; Thu, 19 Feb 2015 22:46:42 +0000 (UTC)
Received: by lbvp9 with SMTP id p9so2960516lbv.3
 for <tor-talk@lists.torproject.org>; Thu, 19 Feb 2015 14:46:39 -0800 (PST)
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:from:date
 :message-id:subject:to:content-type;
 bh=owy5N9l2rWqAmvri+vFUpuf1lF4QW/mhVqRDrTCanvc=;
 b=i3FYp+fIo91e7sJoj3kavDBsWy8gGu2aLQ2jBYvr6CJMQp2U0GzicCGP0v0/hLmFb8
 WXGswoOnxU89pGaNE84q/RVqFcw5WDpx8FaRCSIIccwHoUYbpxGJjSXGx7iYnIe1Nh/o
 YDI/tMecms21/JaCupRu0XLxcKMhvE550COjknNeMXFI2ax5fSSdl4OQsX24K+l97WPA
 q8RKsUnajyl9GLoMCoM51d+GWitzBhXixgMDype8dG6q+AsN8DyGzU9iWvpfCmqZhs3k
 OoDmaxdOd78bxm+OKwqclQXFGUVdQzXD7SpgGdLUB2iDfTY4TVY5jl2aKGBh7ZKbx4ZZ
 Dnlg==
X-Gm-Message-State: ALoCoQkZefHm3QztjDCyImm5ndGVI9Oy9j5jVaA+qVV9Mocq1VL0pha4PAPSFJ6NOd7cW1BWInnx
X-Received: by 10.152.7.204 with SMTP id l12mr5971400laa.1.1424385998873; Thu,
 19 Feb 2015 14:46:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.40.143 with HTTP; Thu, 19 Feb 2015 14:46:18 -0800 (PST)
In-Reply-To: <20150219223428.GG4708@torproject.org>
References: <54E59856.7080006@riseup.net>
 <20150219081021.GI26363@mail2.eff.org>
 <20150219223428.GG4708@torproject.org>
From: "zaki@manian.org" <zaki@manian.org>
Date: Thu, 19 Feb 2015 14:46:18 -0800
Message-ID: <CAJQ8TmDmxp2RC_kWjouVh64Ggd1bopu-UnRTX4p6e0YryMmHDQ@mail.gmail.com>
To: tor-talk@lists.torproject.org
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: Re: [tor-talk] Tor Browser Bundle with Chromium
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>

This is chromium bug[1] deserves more stars from the privacy community that
wants to choose to use Chrome/ Chrome OS via tor. It's a different
privacy/security trade off depending on your threat model.

Chrome is getting much more friendly towards multiple simultaneous profiles
which makes it usable to have a privacy hardened profile.

I suspect the first place we see a build system attack is in court
documents or a Lavabit type scenario.

[1] https://code.google.com/p/chromium/issues/detail?id=447978

On Thu, Feb 19, 2015 at 2:34 PM, Mike Perry <mikeperry@torproject.org>
wrote:

> Seth David Schoen:
> > Luis writes:
> >
> > > What are the reasons that makes building a Tor Browser using Chromium
> > > not such a good idea? I recall reading somewhere that while making a
> Tor
> > > Browser with a Chromium base would have its benefits due to Chromium's
> > > superior security model (i.e. sandboxing), there are "serious privacy
> > > issues" that would have to be solved to make that possible.
> > > My question is what are those issues? What is preventing someone from
> > > digging out all the Google integration and possible privacy-endangering
> > > features and making a Tor Browser Bundle out of it?
> >
> >
> https://trac.torproject.org/projects/tor/wiki/doc/ImportantGoogleChromeBugs
> >
> > I think that list is kept relatively up-to-date.
>
> You might also like:
>
> https://blog.torproject.org/blog/isec-partners-conducts-tor-browser-hardening-study#chrome
>
> In particular, this paragraph is relevant to the recent Superfish MITM
> (see
> http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/
> ):
>
> "The worst offender on this front is the use of the Microsoft Windows
> CryptoAPI for certificate validation, without any alternative. This bug
> means that certificate revocation checking and intermediate certificate
> retrieval happen outside of the browser's proxy settings, and is subject
> to alteration by the OEM and/or the enterprise administrator. Worse,
> beyond the Tor proxy issues, the use of this OS certificate validation
> API means that the OEM and enterprise also have a simple entry point for
> installing their own root certificates to enable transparent HTTPS
> man-in-the-middle, with full browser validation and no user consent or
> awareness."
>
> In fact, I tried to argue with Ryan Sleevi and Adam Langley about the
> dangers of using CryptoAPI in this way, but I got crickets in response.
> I believe that supporting such MITMs is a deliberate policy from Google
> corporate that they cannot change. Adam went so far as to tell me that I
> should just fork Chromium, because they would not even consider merging
> an alternate browser-only cert store, even as a user option.
>
> However, since our ultimate goal with any browser fork is to re-merge
> with upstream so we don't have to maintain invasive patches like this, a
> corporate-level blocker on basic security patches is a non-starter for
> any project involving Chrome.
>
>
>
> P.S. How I miss the days when the outlandish doomsday scenarios that I
> imagined were still merely hypothetical. It seems every week a new
> nightmare comes true. (Man, I sure hope I'm wrong about the likelihood
> of wide-scale software build system attacks. I kind of like having
> computers).
>
>
>
> --
> Mike Perry
>
> --
> 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
>
>
-- 
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

