[tor-bugs] #10538 [Tor bundles/installation]: Think of PTTBB's pluggable transport interface
Tor Bug Tracker & Wiki
blackhole at torproject.org
Tue Jan 14 07:53:00 UTC 2014
#10538: Think of PTTBB's pluggable transport interface
------------------------------------------+-------------------
Reporter: asn | Owner: erinn
Type: task | Status: new
Priority: normal | Milestone:
Component: Tor bundles/installation | Version:
Resolution: | Keywords:
Actual Points: | Parent ID:
Points: |
------------------------------------------+-------------------
Comment (by sysrqb):
Replying to [comment:3 mikeperry]:
> Replying to [comment:2 asn]:
> > There should also be some docs on how to get new bridges off bridgedb
(web/email) or by emailing support at torproject.org .
> >
> > (The above can also happen during the first-startup wizard of
tbb-3.5.)
>
> The above is too much complexity on the TBB side for my tastes. I want
this as simple as possible on the client side. To me, this means adding
just a "Use default bridges" radiobutton (#10418), and otherwise
preserving the "cut and paste lines exactly from BridgeDB" behavior.
>
The Help button actually provides a good description, I think. I hope
people actually use it.
> The bridge type selection complexity should also be on the bridgedb
side, IMO. I also strongly believe that defaulting to auto-probing/trying
every PT type every time with TBB is very foolish behavior for censorship
circumvention. This makes me think that by default, bridgedb should hand
out only one type of bridges. It should have some explanatory text that
tells the user to try another type if the default type doesn't work (by
providing a link to the next most commonly functional PT type), and to how
stick with that type in the future.
I think this is putting too much of the burden on the user. In addition,
as the arsenal of PTs continues to grow, the logic required to provide
users with the correct PT will become a bit rediculous. Does tor need to
try every bridge it is told? Maybe #5018 doesn't go far enough with
respect to starting every PT as soon as it has a bridge and they should be
start one at a time.
>
> I suppose the minimal logic TBB-side here would be to update any "Get
Bridges" bridgedb links in Tor Launcher to specify the currently used PT
types as arguments to the bridgedb URL or something.
>
> We may also want to add Tor Launcher logic to remove bridge lines that
are obviously down/blocked (so it stops trying them on every startup), but
that may be tricky.
>
This has the potential to cause a lot of confusion and frustration,
especially if a user has access to a private bridge that goes down and
then they find that tor is no longer configured to use it.
> > BTW, I think I believe that users should not be required to know what
'obfs2' or 'scramblesuit' means and that they should not be exposed to
those names (if possible) because they might get confused. The workflow
assumes that users will copy/paste `Bridge` lines to tor-launcher without
knowing what 'obfs3' means. That said, an "advanced" panel that allows
people to toggle certain transports might be helpful. Also, some
transport-specific documentation (port forwarding for flashproxy) might be
required.
>
> I agree with the sentiment here. However, I think the browser is the
wrong place for both PT type selection and PT-specific instructions. PT-
specific instructions (like port forwarding) should be provided by
bridgedb with the specific bridge type being handed out. We shouldn't
clutter the Tor Launcher UI with such potentially ephemeral and volatile
PT-specific details, if that is at all possible to avoid.
I agree this should mostly be handled with bridgedb. But your point about
port forwarding is interesting because currently the only PT (afaik) that
requires this is flashproxy, which is the only PT that is not distributed
using bridgedb. I don't know what the best method is to educate users in
this situation. Regarding the other PTs, bridgedb can provide the other
instructions, but for now the entire process should be cut-and-paste.
Maybe in the future it won't be so simple for all PTs.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10538#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list