Hi!
intrigeri wrote:
> Hi,
>
> Patrick Schleizer wrote (21 Nov 2014 15:17:08 GMT) :
>> intrigeri wrote:
>>> Patrick Schleizer wrote (15 Nov 2014 15:38:09 GMT) :
>>> 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.
>
> Sure, for meek we don't really need the server side component to be in
> Debian. But I believe my point still holds in general.
>
>>>> 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).
>
> Well, that's already more or less how we're using it in Tails: we're
> using Tor Launcher as a standalone application, not as part of the Tor
> Browser. We don't use it to start/stop Tor, but we use it to configure
> it whenever the user chose so in the Greeter.
That is probably the main difference. Using it as standalone application
by only using tor-launcher vs using tor-launcher from an original TBB
tarball / folder. I'll elaborate below.
>> - 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).
>
> That's what we're doing in Tails already.
>
>> - 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".
>
> We already have this behaviour, so why would we need Tor Launcher to
> do that?
For non-bridge users the advantage would be arguable: using the version
of Tor that comes with TBB rather than the version of Tor that comes
with Debian. If I remember right, there was a time where TBB's version
of Tor (and deb.torproject.org's version) included a new feature that
helped to cope up with the issues causes by that huge botnet that abused
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.
>
> I don't understand what problem this solution is trying to solve.
Glad you're asking! Thanks so much for not just quickly dismissing this!
Somehow I failed to explain the general idea well. Need to work on that.
Tails current implementation differs from what I am having in mind here.
- Currently: You are using /usr/bin/tor-launcher and ~/.tor-launcher.
Somehow extract tor-launcher from TBB or its repo during build time?
- Alternative: Simpler implementation (from Tails side - probably
requires tor-launcher patches) + patching tor-launcher. Using a regular
Tor Browser Bundle tarball, extracted to /home/user/tor-browser_en-US/
or saner location.
- Currently: You are using the Debian "tor" package. The "real" system Tor.
- Alternative: Use /home/user/tor-browser_en-US/Browser/TorBrowser/Tor/
as "fake system Tor". Advantage... When you use that folder, you ship
the same pluggable transports as TBB.
- Currently: When choosing "no extra settings" in Tails Greeter, the
user cannot change its mind and try different settings. At least as far
as I know. I haven't found tor-launcher / Tor settings start menu / on
desktop. And if the user types (/usr/bin/)tor-launcher in terminal, it
will show an error message.
- Alternative: The user could run a start menu entry that configures
Tor. Using tor-launcher from /home/user/tor-browser_en-US.
In other words, if you used an original TBB folder
/home/user/tor-browser_en-US as "fake system Tor" + implementation magic
(above or otherwise), Debian/Tails/Whonix users could choose pluggable
transports from the same tor-launcher menu as TBB users.
You'd just use the original TBB tarball and folder
/home/user/tor-browser_en-US as location for Tor, pluggable transports,
tor-launcher and Tor Browser.
Difference to TBB / this idea... TBB's Tor only provides Tor for Tor
Browser. While what I am having in mind here, TBB's Tor would provide
Tor for the whole system ("fake system Tor"). In other words, patching
TBB so it could be used to provide Tor for the whole system.
That's the basic idea...
Now, I wrote two unrelated JavaScript patches for TorButton. [1] [2] I
am not a JavaScript coder, but I could translate my knowledge of other
languages to produce some functionality. No idea, if these patches will
be merged in their current form, one of the two probably needs a
revision. But those patches are tested, do work. And we got one or two
JavaScript coders at Whonix who might help implementing the "use an
original TBB tarball, /home/user/tor-browser_en-US as 'fake system Tor'"
solution.
Before working on this, it would be helpful if you would approve the
general idea. Knowing it's not a totally insane approach. :) While we're
at it, writing the patches in a way that also other (anonymity centric)
distributions, Debian, Tails could profit from them would result in a
synergy effect, I think. You might or might not wish copy/adapt that
solution for Tails later and thereby solve the "keeping up with
pluggable transports" issue.
Cheers,
Patrick
[1]
https://trac.torproject.org/projects/tor/ticket/13079
[2]
https://trac.torproject.org/projects/tor/ticket/13835
