Delivery-Date: Tue, 10 Mar 2015 18:18:23 -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.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	T_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 BDCA21E0A52
	for <archiver@seul.org>; Tue, 10 Mar 2015 18:18:21 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id A71A1346C2;
	Tue, 10 Mar 2015 22:18:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 7F2B9346C0
 for <tor-talk@lists.torproject.org>; Tue, 10 Mar 2015 22:18:11 +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 zrgjCROPYvzu for <tor-talk@lists.torproject.org>;
 Tue, 10 Mar 2015 22:18:11 +0000 (UTC)
Received: from turtles.fscked.org (turtles.fscked.org [76.73.17.194])
 by eugeni.torproject.org (Postfix) with ESMTP id 488163468A
 for <tor-talk@lists.torproject.org>; Tue, 10 Mar 2015 22:18:11 +0000 (UTC)
Date: Tue, 10 Mar 2015 15:17:53 -0700
From: Mike Perry <mikeperry@torproject.org>
To: tor-talk@lists.torproject.org
Message-ID: <20150310221753.GA4255@torproject.org>
References: <54E59856.7080006@riseup.net>
 <20150219081021.GI26363@mail2.eff.org>
 <20150219223428.GG4708@torproject.org>
MIME-Version: 1.0
In-Reply-To: <20150219223428.GG4708@torproject.org>
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: multipart/mixed; boundary="===============0496744588686407796=="
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>


--===============0496744588686407796==
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy"
Content-Disposition: inline


--KsGdsel6WgEHnImy
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Mike Perry:
> Seth David Schoen:
> > Luis writes:
> >=20
> > > 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-endangeri=
ng
> > > features and making a Tor Browser Bundle out of it?
> >=20
> > https://trac.torproject.org/projects/tor/wiki/doc/ImportantGoogleChrome=
Bugs
> >=20
> > I think that list is kept relatively up-to-date.
>=20
> You might also like:
> https://blog.torproject.org/blog/isec-partners-conducts-tor-browser-harde=
ning-study#chrome
>=20
> 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/):
>=20
> "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."
>=20
> 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.
>=20
> 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.
>=20
>=20
>=20
> 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).

"The security researchers also claimed they had created a modified
version of Apple=E2=80=99s proprietary software development tool, Xcode, wh=
ich
could sneak surveillance backdoors into any apps or programs created
using the tool. Xcode, which is distributed by Apple to hundreds of
thousands of developers, is used to create apps that are sold through
Apple=E2=80=99s App Store.

The modified version of Xcode, the researchers claimed, could enable
spies to steal passwords and grab messages on infected devices.
Researchers also claimed the modified Xcode could =E2=80=9Cforce all iOS
applications to send embedded data to a listening post.=E2=80=9D It remains
unclear how intelligence agencies would get developers to use the
poisoned version of Xcode."

https://firstlook.org/theintercept/2015/03/10/ispy-cia-campaign-steal-apple=
s-secrets/

*sigh*

--=20
Mike Perry

--KsGdsel6WgEHnImy
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJU/22RAAoJEEEC+JXS8eGGEjEP/jVBiynpbPW1cSEwLPlHJ/Wv
qMs8k4jqb95tT+/efsz4v3b21e8dEdQmuu+YWfI3kfENp+XM2eqQa40S1HRWIO6s
Ss52eivQ4Fx5xuDNSdbYbO69cExbBbXlAe7jJJ9S3aOfSYFulGeK3AfYdZKPmtDs
VjBXJFCrQSbCZglMikasI7EJF9YZOYMODSgw5/TK2HWDOjwlqrhNKb/KDE0RPM1q
rG3FBYpGuwrmn/B3v2uHqH0IvpQto5iPOnjHMYF6Mv5KAB6reljyE8XDBr2qKNPY
cy6DQW8ocNpBl/SxSaZTFqsa6zwgjVPz5YsTg/08iKmHob+3CRVqA8GsUg6xAD6H
LanXdNqqscg8HGa3UodEMxxhs0TGlXHVrm3IUSN/J+WRI/GC8D0sWdGE1C/iz/jL
DboKnSmuojcp3jsN4mgJ3et8bOKic1yv6eOGWtsKL4T5zEqCgM6cc20LAulKE4Q6
d+TaLiUS9b1cpXmssUUiriDpOonzO8P1+uLBlkF8waSxrkFxFIcTolQ5vs+S1YWj
NZ9BmwUNrO9mLiZ/lFl2k9vbNwKL+YptSHm+K8ZYJPOitNL99x2mUr8Z+ZzRhTEG
IB9TtbhMxpHniiiQeFrRAXQOfQDwDXfUV7d25qWujUPxGS3DFP1lszJcHJlbPRCc
QFMCOJGSJJloL/gBE/wa
=W+0G
-----END PGP SIGNATURE-----

--KsGdsel6WgEHnImy--

--===============0496744588686407796==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
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

--===============0496744588686407796==--

