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
_______________________________________________
tails-dev mailing list
[email protected]
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
[email protected].
