[tor-bugs] #10538 [Tor bundles/installation]: Think of PTTBB's pluggable transport interface

[Tor Bug Tracker & Wiki]

#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 mikeperry):

 Replying to [comment:2 asn]:
 > Some notes on the UI:
 >
 > Since we still use vanilla bridges, there should be a master button
 called "Enable PTs" that turns on the PTs. When the user presses the
 "Enable PTs" button, he should get the option to pick between using
 hardcoded obfsbridges, or adding his own obfsbridges. We should warn users
 that hardcoded obfsbridges might be blocked and that users are encouraged
 to get their own bridges. 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.

 dcf has patched the TBB tor with #5018, so PTs won't be launched until PT
 lines are pasted in, so an additional "Enable PTs" button is both overkill
 and redundant.

 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 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.

 > 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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10538#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online