19/02/14 15:14, Mark Smith wrote: > On 2/18/14, 1:08 PM, anonym wrote: >> TL;DR: I think the standalone approach is better, and like to switch it. > > The main reason we proposed the "exit browser after configuration" > solution was because we were not sure how much work it would be to > create a standalone XUL app.
Completely understandable. I certainly thought the standalone approach would be much more problematic than it turned out to be. :) [...] >> Some notes on "exit the browser" vs standalone XUL approaches: >> ... >> >> * When it comes to upstream maintenance, the "exit the browser" and >> standalone XUL approaches are pretty similar, at least as long as >> Tor Launcher only deals with starting/configuring Tor, and do not >> interact with Firefox (e.g. add something to `prefs.js` that's >> relevant for Firefox, or whatever). Tor Launcher maintainers, is >> this the plan for the foreseeable future? > > To support a pluggable transports (PT) Tor Browser bundle, we have added > an option to configure a default set of bridges. That option requires > setting preferences inside the browser so that Tor Launcher knows to > reconfigure the default bridges each time the browser is started (we > need to set the bridge configuration each time because they originate > from hidden Tor Launcher preferences which may be updated when a new > version of TBB is installed). It sounds to me like the setting you are talking about does *not* have any direct effect on Firefox, only on Tor Launcher. To clarify, you are *not* setting e.g. `network.proxy.socks` (which Firefox itself uses), instead you are setting e.g. `extensions.torlauncher.xxx` (which Firefox itself doesn't use). Is this correct? (If so, we're happy -- see the end of this email.) > This is also why we need to start tor > with DisableNetwork=1 when the "use default bridges" option is enabled: > so we can update the bridge configuration before tor starts its > bootstrap process. See: > https://trac.torproject.org/projects/tor/ticket/10418 [Note: The reason I'm continuing this part of the discussion is not because I think it will be especially relevant for Tails directly but it does help me to better understand where Tor Launcher is going in the future so I can assess if "Tor Launcher in Tails" is a long-term solution or not. It may be that I'm just wasting everyone's time here being confused and speculating about a future change that I don't know the exact details of, so we may want to just drop it. :)] Will anything change with Tor Launcher's current design of immediately starting Tor and configure it to use the previous settings on all runs after the very first? Otherwise I don't see the relevance of setting `DisableNetwork=1` beyond the first run; if the "use default bridges" option was chosen on first run, bridges will be written into torrc, which makes `DisableNetwork=1` redundant. However, if the design does change, e.g. that you show the network settings on *each* run, with `DisableNetwork=1` set (highly relevant now since the user may have chosen connect in the clear in the previous run), then I don't see why you thought this new behaviour would be incompatible earlier patch (0002-Always-open-network-settings-if-DisableNetwork-is-se.patch). > I am not sure if the concept of default bridges is something you will > want for Tails in the future or not. It doubt it. In Tails we care about the bridges being non-public to support the "hide that you are using Tor" use case as best we can. If we expose our users to a convenient option to use a public list of default bridges, then we put the users of that use case at risk. Therefore it'd be great if whatever GUI control you'll use for this option will be hidden (or at least disabled/"greyed out") if the pre-supplied list of default bridges is empty/non-existent. > Another small consideration is that we (TBB developers) will probably > not test Tor Launcher as a standalone XUL application because we will > not be using it that way... so it is possible we will accidentally break > something that is needed in that mode. Of course we will try not to do so. As long as Tor Launcher more or less sticks with its current design, and continues to keep away from stuff directly affecting Firefox (leaving that to Tor Button) and only do stuff related to starting/configuring/monitoring Tor processes, I expect very little problems due to your upstream changes. Does this look like your plan for the foreseeable future? [Sorry for essentially repeating my question from earlier, but a straight answer to this question would help immensely for assessing the viability of Tails' new plan w.r.t. Tor Launcher.] Cheers! _______________________________________________ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
