On 2/19/14, 2:14 PM, anonym wrote:
> 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.)
Yes, I think that is correct. It is a little difficult for Kathy and me
to separate the two things because until now we have never thought about
Tor Launcher running in a profile separate from the one where browsing
will be done.
>> 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 tried to explain this in my last message but possibly I wasn't clear.
We do not plan to show the network configuration wizard each time.
The issue is that Tor Launcher needs to reconfigure the default bridges
each time tor starts up. This is necessary because the default bridge
addresses may change when TBB is upgraded (the addresses are stored as a
series of hidden Tor Launcher preferences).
>> 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.
That is already how things work. The option to use default bridges is
only displayed if the necessary preferences are present.
>> 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?
Yes, although I leave it to Mike (in his role as TBB chief architect) to
comment as well. Requirements may dictate a future change in direction,
but for now the plan is for Torbutton and Tor Launcher to work together
but maintain their distinct roles.
-Mark
