Re: [Tails-dev] keeping up with pluggable transports by usin…

Delete this message

Reply to this message
Author: Patrick Schleizer
Date:  
To: tails-dev
Subject: Re: [Tails-dev] keeping up with pluggable transports by using TBB's Tor and tor-launcher
Hi!

intrigeri wrote:
> Hi,
>
> Patrick Schleizer wrote (15 Nov 2014 15:38:09 GMT) :
>> Idea:
>
>> - Come with a recent release of original TBB from TPO installed by
>> default with every new release of Tails/Whonix.
>
>> - Use the TBB, tor-launcher add-on and pluggable transports from TBB as
>> the new "system Tor".
>
> Indeed, this would allow us to stay on top of things, and probably
> make the UX clearer, since we would support just the same set of PTs
> as Tor Browser supports. I must say it's quite tempting.


Glad you like it!

> OTOH, given the amount of complicated stuff we already need to get the
> Tor Browser itself properly integrated in Tails, I'm not too thrilled
> at the idea of seeing more and more kludges added to do the same for
> PTs... but maybe an actual implementation wouldn't be that scary, and
> my fear would be proved to be irrational.


>> Seems like an approach that needs low maintenance from distribution
>> developers (Debian/Tails/Whonix) as well as from tor-launcher/TBB
>> developers? Needs no extraction of stuff like meek, flashproxy,
>> scramblesuit for packaging (policy conform) for Debian.
>
> Unless I'm mistaken, the server-side of these PTs needs to be in
> Debian anyway, so that people running Debian-based distros can
> actually provide bridges supporting these PTs. And then, while one is
> at it, I suspect that maintaining and packaging the client-side while
> one is at it doesn't involve much more effort. So, I'm not convinced
> by this specific argument.


Maybe we're having different things in mind here. For meek bridges,
there is a google and an amazon one. I guess most users just happily use
those. Or is anyone eager to host a meek bridge? Maybe I am mistaken.
It's also not an important point. Having meek's server component in
Debian surely would be a nice to have. But in that particular case, I
think it's not that important. Unless I'm mistaken.

>> This requires tor-launcher having a features such as:
>
> I'm afraid I don't understand why we would need any such changes
> for Tails. May you please clarify?


I try to reword/elaborate a bit.

General idea: trying to modify/use tor-launcher so it works more like
Vidalia (a Tor config/start/stop utility).

- Just start Tor Browser without configuring Tor (we already got that
TOR_SKIP_LAUNCH). -> It's useful so you can boot with a usual desktop.
Not autostarting a browser. And when the user wants to start the
browser, you use that (without starting tor-launcher or Tor).

- Just start Tor with current configuration (missing feature?) -> For
users who choose "no network obstacles", Tails would just run TBB's Tor
as the new "system Tor".

- Configure Tor (using tor-launcher), but don't
start Tor or Tor Browser (missing feature?). -> For users who choose
"got obstacles", Tails would start the tor-launcher add-on to let them
configure Tor. Then Tails would use the "just start Tor with current
configuration" feature. And if the user notices it doesn't work, go back
to this one.

- anything else?

I don't know Tails / tor-launcher specifics good enough. Maybe you have
a better idea how to implement it best? Perhaps it would be best to
design tor-launcher in a way, so it would for plain Debian users?
Because if that works, it should work for Tails/Whonix users as well.

Cheers,
Patrick