On Mon, Nov 3, 2014 at 3:05 PM, Mike Perry <mikepe...@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
