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!
