Think of PTTBB's pluggable transport interface
Seems like upcoming PTTBBs will be using the new 3.x TBBs that include tor-launcher. This is awesome!
This means that we also have a chance to make a nice usable UI for pluggable transport clients. We should think of how we want our users to interact with pluggable transports, and design the interface accordingly.
For example, should we expose the users to pluggable transport names? Or should we try to hide those funny names (obfs2, obfs3, scramblesuit, wtf?) from the users, and only expose a higher level interface?
We should also consider the BridgeDB interface while doing so, and make it fit nicely with the tor launcher interface.
Activity
Cross-referencing #10418 (moved) which has some interface discussion.
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@torproject.org .
(The above can also happen during the first-startup wizard of tbb-3.5.)
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
Bridgelines 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.Trac:
Cc: N/A to mcs, mikeperry, brade
Replying to 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@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 (moved)), and otherwise preserving the "cut and paste lines exactly from BridgeDB" behavior.
dcf has patched the TBB tor with #5018 (moved), 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
Bridgelines 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.
Replying to mikeperry:
Replying to asn:
There should also be some docs on how to get new bridges off bridgedb (web/email) or by emailing support@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 (moved)), 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 (moved) 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
Bridgelines 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.
-
Replying to sysrqb:
Replying to mikeperry:
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 (moved)), 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 (moved) 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.
Hrm. I think we can still keep this simple (from a UX perspective) if we think about it. I don't believe that a user should be using more than one PT type at a time. If we maintain that property, perhaps we can simplify the UX.
One option is to impose a priority ordering on PT/bridge types, and remove "deprecated" PT protocols from the bridge list as soon as "newer" ones are added. This PT protocol ordering could be based on the most recently observed deployment counts of PTs (try the most popular, older, well-deployed PT types first, and then remove them and switch to newer PTs with smaller bridge counts, until we arrive at something that works).
Under this model, we could have BridgeDB WebUI act as a sort of wizard. BridgeDB could instruct users to first try vanilla bridges, and then obfs2, and then obfs3, and then flashproxy, telling the user to manually "clear bridges" after each step. That way the ordering can change more dynamically, based on bridge count and PT availability. It could then give them a link directly to the PT type they need when they finally arrive at a working set.
This may have issues (such as false positives due to heavy scraping + IP-based blocking), but if we're going to put effort into designing this, we should be conscious of the fact that the optimal direction to head in is towards a world where the user is only using one PT type at a time before moving on to the next type. We should put our thinking caps on to think of a flow that only requires the user to go through this discovery process at most once, as opposed to continually trying all bridge and PT types every time TBB starts or is reinstalled.
We should also make it easy for them to communicate to their friends how to start from a given PT type, if possible. Provide a bookmarkable link + QR code at the end of the wizard maybe?
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.
I suppose a heavier client-side option is for Tor Launcher or Tor to record if a particular PT type has succeeded recently. Liveness of a bridge can be verified by using a test circuit through a working bridge to a potentially blocked bridge (assuming all PTs also have working Tor OR ports). If the circuit succeeds but the bridge is unreachable from the client side (and if this happens multiple times for all bridges of a given PT type), then that PT type is definitely blocked by DPI. Later-stage/scarcer/bleeding-edge PTs could be used as first hops to confirm the blockage of the less scarce, but more blockable types.
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
Bridgelines 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.
Hrmm well still, we should avoid having to have custom UI for each PT type. Is there any way to achieve that? Does Flashproxy perform UPNP or other NAT punching techniques by default?
Replying to mikeperry:
Hrmm well still, we should avoid having to have custom UI for each PT type. Is there any way to achieve that? Does Flashproxy perform UPNP or other NAT punching techniques by default?
It does not by default; flashproxy-client is capable of calling tor-fw-helper (#9033 (closed)) but tor-fw-helper is not included in the browser bundle (#5213 (closed), comment:4:ticket:9444).
Our flash proxy–specific help documentation is at FlashProxyHowto.
