moat integration (fetch bridges for the user)

Tor Launcher needs to be enhanced to fetch bridges using moat. Dependencies include #22871 (moved) and #21951 (moved).

added TorBrowserTeam201803R component::applications/tor launcher owner::brade parent::24689 priority::very high resolution::fixed severity::normal sponsor::4 status::closed type::defect ux-team labels

Trac:
Sponsor: N/A to Sponsor4

Adding to our September 2017 tickets.

Trac:
Keywords: N/A deleted, TorBrowserTeam201709 added

Isis reminded me (on irc) that we will use meek as a transport for this. One potential issue is that the Linux sandboxed-tor-browser does not support meek.

Replying to mcs:

Isis reminded me (on irc) that we will use meek as a transport for this. One potential issue is that the Linux sandboxed-tor-browser does not support meek. But isn't that irrelevant currently since sandboxed-tor-browser has Torlauncher disabled and has its own implementation of a launcher? Moreever yawning said that sandboxing meek was impossible #20781 (closed)#comment:6

Replying to cypherpunks:

But isn't that irrelevant currently since sandboxed-tor-browser has Torlauncher disabled and has its own implementation of a launcher? Moreever yawning said that sandboxing meek was impossible #20781 (closed)#comment:6

That is all true, but if (1) sandboxed-tor-browser wants to add support for moat and (2) the only way to reach the moat service is via a meek transport, something will need to be done.

Replying to cypherpunks:

Moreever yawning said that sandboxing meek was impossible #20781 (closed)#comment:6

What yawning means there, I believe, is that sandboxing meek with the headless Firefox HTTP helper is impossible. That means no meek-client-torbrowser, but you could still use plain meek-client or obfs4proxy with meek_lite. Or it could even be a separate single-purpose program used only for Moat--the domain fronting code is a small part of meek (the rest is session management and PT integration).

Items for October 2017

Trac:
Keywords: TorBrowserTeam201709 deleted, TorBrowserTeam201710 added

Moving tickets over to November.

Trac:
Keywords: TorBrowserTeam201710 deleted, TorBrowserTeam201711 added

Changing prio to reflect sponsor deadline

Trac:
Priority: Medium to Very High

Trac:

Trac:

Trac:

Trac:

Kathy and I encountered some issues while implementing the Moat UI that is spec'd here: https://marvelapp.com/3f6102d/screen/31456318

Here is the result when we try to place this design in the setup wizard:

Notice that the proxy settings are not close to fitting within what is already a fairly large dialog box. We could make the captcha image a lot smaller, but then it will be even more difficult to solve.

Next, we experimented with a horizontal layout:

This is better in terms of space used, although the proxy settings still do not fit well. And the horizontal layout is awkward from a UX perspective (e.g., the text input box is to the right of the image instead of below). We also made the captcha image half size and you can see that it becomes challenging to decipher.

While working on this, we also realized that there are a number of interaction problems with the current design:

• What do we do after a bridge is received via moat? The obvious answer is that the bridge configuration line will show up in the "Provide a bridge I know" text area. But that means that having a radio button for the moat interaction does not make a lot of sense; it is a short-lived modal interaction (stop what you are doing, interact with BridgeDB, done) rather than a state that needs to be maintained.
• There needs to be a way to cancel the moat interaction. Within the existing design that could be done by choosing a different radio button, but we may want to provide a more obvious way to cancel.
• There should be a Submit button (pressing Return/Enter should also work of course).
• There should be a way to request a different captcha image; we need a "reload" button.

All of this led us to mock up a new design, and we would like everyone's input (especially the UX team's). Here is our proposed configuration screen:

Next, after the user clicks "Get a Bridge For Me" button, an overlay is used for the Moat interaction:

Is this a good direction to pursue? Kathy and I like it and think it solves the problems inherent in the original design, but we are also open to other ideas.

Trac:
Cc: brade to brade, isabela, antonela, tbb-team
Status: new to needs_information

I think the overlay idea is a good one. I am not sure about a good layout for the "Use a different bridge" part. There are basically three different UI elements pretty close together and all three interact somehow with each other. Might be confusing to users.

Trac:

Trac:

Replying to gk:

I think the overlay idea is a good one. I am not sure about a good layout for the "Use a different bridge" part. There are basically three different UI elements pretty close together and all three interact somehow with each other. Might be confusing to users.

You make a good point. Here is a attempt at addressing that problem, and also making it more obvious that the user needs to choose between requesting a bridge and entering info they obtained via another method. The overlay part would remain as shown in moat-3b-proposed.png.

Trac: