Delivery-Date: Tue, 04 Nov 2014 13:46:31 -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.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 D901E1E0683;
	Tue,  4 Nov 2014 13:46:29 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 9422E31792;
	Tue,  4 Nov 2014 18:46:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 62B193058D
 for <tor-talk@lists.torproject.org>; Tue,  4 Nov 2014 18:46:21 +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 7q-CJl34HBSm for <tor-talk@lists.torproject.org>;
 Tue,  4 Nov 2014 18:46:21 +0000 (UTC)
Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com
 [209.85.220.177])
 (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 34FE93038A
 for <tor-talk@lists.torproject.org>; Tue,  4 Nov 2014 18:46:21 +0000 (UTC)
Received: by mail-vc0-f177.google.com with SMTP id hq12so3425797vcb.36
 for <tor-talk@lists.torproject.org>; Tue, 04 Nov 2014 10:46:18 -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:date
 :message-id:subject:from:to:content-type;
 bh=+dCCEWBj6grcJHJ83nn0cq75CCwyCn0IjT9b/GLZbZ0=;
 b=g6/j+6oMPyMPVDOndfx2zCiZFaFBKvDefF181GK4+w3Xr5YfpPCWWB2EMauAa/+eZx
 LVX0R0gPo7YnrA9qvLacqCjipk0wWiAqIYTbNLEnNznd5DYatKYf43Az1afUyU4flkN4
 g8+tCbP4hhiyAA07RSPpjOx7f8F8JMBX51wgNf4Mt7tq/b2LBGTTXHEHuWY435RPJz2X
 zn/cnkwmrGdZ5WDaiMHaf7muHJcXJyvLe8VgKRFmfsGPIbzq/mO7hH+rznKXnyqhfzTR
 xD+3niSpF42voAzkyqlZE9teBBTkbiZe1Bp540nh0x6LEDakUoCPzWLkFJvr2Pc61boj
 YbYg==
X-Gm-Message-State: ALoCoQlfFCfvDVIKUgNcqoBmoBPK85fObYxYbZ/QRC1Na0Taoor5xKNjEK8UvKfPnC/FWPOh9x7Q
MIME-Version: 1.0
X-Received: by 10.52.167.36 with SMTP id zl4mr980483vdb.80.1415126778684; Tue,
 04 Nov 2014 10:46:18 -0800 (PST)
Received: by 10.31.181.15 with HTTP; Tue, 4 Nov 2014 10:46:18 -0800 (PST)
X-Originating-IP: [50.78.106.66]
In-Reply-To: <20141103230522.GJ21428@torproject.org>
References: <CADw1SfEvdtayywkz3jo3gnFtDRqdwwtcV2+iRuBej4tH8h6Rqw@mail.gmail.com>
 <20141103230522.GJ21428@torproject.org>
Date: Tue, 4 Nov 2014 10:46:18 -0800
Message-ID: <CADw1SfEOb-XJr8sriwSL4AKhTdXtuYqn=r7RVuVAQXUfXWN9Vw@mail.gmail.com>
From: Cyrus Katrak <cy@kr36.co>
To: tor-talk@lists.torproject.org
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: Re: [tor-talk] Krypton Anonymous: A Chromium Tor Browser
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 Mon, Nov 3, 2014 at 3:05 PM, Mike Perry <mikeperry@torproject.org> wrote:

> Cyrus Katrak:
> > https://github.com/kr36/seaturtle
> >
> > At a high level:
> > - Process per tab security model, with each tab owning it's own in-memory
> > state (cache, cookies, local storage, hsts db etc...).
>
> We've been going for URL bar domain isolation in Tor Browser to avoid
> divergence with how users expect the browser to behave:
> https://www.torproject.org/projects/torbrowser/design/#philosophy
>
> https://www.torproject.org/projects/torbrowser/design/#identifier-linkability
>
> Even still, per-tab isolation is a common request, so it's easy to
> assume that this is what most people really want. But I think if you
> think through how it will work in practice, it becomes fairly clear it's
> actually a very bad property for usability.
>
> The easiest way to see how per-tab isolation will cause confusion is to
> imagine the twitter use case. In a normal twitter user flow, the user
> logs in to twitter, opens some lists and conversations (often in new
> tabs), perhaps opens tweetdeck in a new tab, follows links from people
> in their feed, and sends and receives twitter conversation links from
> their friends over DM, chat, IRC, and email.
>
> If each these actions happens in a new, isolated tab, the user will be
> forced to log in repeatedly to twitter, and worse, forget which tabs
> they logged in to twitter on, especially once they start following links
> (both on and off site) from people's feeds.
>
> Is Tor Browser-style url bar domain isolation also possible to achieve
> with simple configuration, or did you just go per-tab because the
> Chromium plumbing was already set up to make per-tab isolation easy?
>
> I see a cookie policy file that appears to block third party cookies,
> but I don't see the per-tab isolation mechanism in the source.
>

I oversimplified my explanation a bit. Right now If you open a "fresh" new
tab (using the '+' button in the tab view), you get a "fresh" state.
However if you long-press a link (open link in new tab) or happen to click
a popup link, the newly created tab will share state with the previous tab.
I think this partially addresses your concern, but I agree it's imperfect,
and probably a bit confusing for most people.

I came to this design decision via some personal intuition, user feedback,
and experimentation. The default Chromium security model is process per
site instance
<http://www.chromium.org/developers/design-documents/process-models#1_Process_per_Site_Instance>,
however this doesn't really address some aspects of shared state (cache,
cookies etc...). Take a look at the url request context getter
<https://github.com/kr36/seaturtle/blob/master/shell/browser/shell_url_request_context_getter.cc>
to see the possibilities of what can be shared or isolated across browser
contexts (note that Krypton Anonymous ships with single_context = false).

I'll also note that our companion app (Krypton Premium, for non-Tor
everyday browsing) has the property that it only saves cookies for websites
you've added to your favorites. I don't have a good enough understanding of
what kind of features the Tor community wants, so at the moment Krypton
Anonymous airs on the side of caution by never saving state.



>
> > - Efficiently integrated HTTPS Everywhere rules.
> > - Addresses some fingerprint-ability issues: Disabled geolocation, webgl,
> > accelerated <canvas>, static user agent, etc.
>
> Are these also simple prefs?
>

Some are hard-coded, some are preferences. Generally speaking it's not hard
to convert the hard-coded stuff to preferences, but I'm trying to avoid
giving the user too many options. This should give you a good idea of what
is configurable at the moment:

https://github.com/kr36/seaturtle/blob/master/protos/setting.proto

Note that the defaults listed in that file are quite different from what
Krypton Anonymous ships with.


>
> > - Single tap to start a bundled Tor binary, and properly configure the
> > browsers proxy settings. Gave a fair amount of thought to UX and polish.
>
> Do you interact with the Tor Control port at all here? Or do you just
> re-write the torrc? Where is your tor handling located in the code?
>

When the user clicks the Tor icon this is roughly what happens:
- Change the proxy config
<https://github.com/kr36/seaturtle/blob/master/protos/jni.proto#L172> to
PENDING.
- Loop:
  - Exec Tor with cmd line flags SOCKSPort auto, a DataDirectory and
ControlSocket located in the apps android data directory, and
__OwningControllerProcess mypid. I do not use a torrc.
  - Try to connect to the control socket and get the socks port (GETINFO
net/listeners/socks), once we have the port change the proxy config to
VALID + socks5://127.0.0.1:PORT.

Most of this happens from the java side, which isn't on GitHub.


>
> > It's still early days, only builds for Android at the moment. Nobody has
> > seriously reviewed the code or black box tested. Lots of fingerprint
> > mitigation work still remains. Hoping to get feedback and suggestions for
> > improvement, and help.
>
> It looks like you've seen the Tor Browser design doc and the important
> Chrome Bugs links, but I'd like to point these sections out again as
> they have recently been updated:
>
> https://trac.torproject.org/projects/tor/wiki/doc/ImportantGoogleChromeBugs#ProxyBypassBugs
> and
>
> https://www.torproject.org/projects/torbrowser/design/#fingerprinting-linkability
>
> In particular, that fingerprinting section was just updated this past
> weekend.
>
> I also have an OpenWRT configuration I can give you to monitor for proxy
> leaks on an upstream router, but you need to be able to configure Tor
> Bridges to make use of it.
>
> --
> 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

