moat integration (fetch bridges for the user)
Tor Launcher needs to be enhanced to fetch bridges using moat. Dependencies include legacy/trac#22871 (moved) and legacy/trac#21951 (moved).
Activity
added TorBrowserTeam201803R in Legacy / Trac component::applications/tor launcher in Legacy / Trac owner::brade in Legacy / Trac parent::24689 in Legacy / Trac priority::very high in Legacy / Trac resolution::fixed in Legacy / Trac severity::normal in Legacy / Trac sponsor::4 in Legacy / Trac status::closed in Legacy / Trac type::defect in Legacy / Trac ux-team in Legacy / Trac labels
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-browserhasTorlauncherdisabled and has its own implementation of a launcher? Moreever yawning said that sandboxing meek was impossible legacy/trac#20781 (closed)#comment:6
Replying to cypherpunks:
But isn't that irrelevant currently since
sandboxed-tor-browserhasTorlauncherdisabled and has its own implementation of a launcher? Moreever yawning said that sandboxing meek was impossible legacy/trac#20781 (closed)#comment:6That is all true, but if (1)
sandboxed-tor-browserwants 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 legacy/trac#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).
-
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 -
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.
Hi all!
I think is pretty clear when you have 3 options.
[ ] I will select a built-in bridge [i] [ ] I would like to request a bridge [ ] I have a trusted bridge
If the user request for a bridge, the Captcha should appear.
[ ] I will select a built-in bridge [i] [x] I would like to request a bridge CAPTCHA section - horizontal layout [ ] I have a trusted bridge
Agreed about the horizontal layout, works better for sure.
Quick mockup attached https://trac.torproject.org/projects/tor/attachment/ticket/23136/23136.png
+1 to this suggestion
Replying to antonela:
Hi all!
I think is pretty clear when you have 3 options.
[ ] I will select a built-in bridge [i] [ ] I would like to request a bridge [ ] I have a trusted bridge
If the user request for a bridge, the Captcha should appear.
[ ] I will select a built-in bridge [i] [x] I would like to request a bridge CAPTCHA section - horizontal layout [ ] I have a trusted bridge
Agreed about the horizontal layout, works better for sure.
Quick mockup attached https://trac.torproject.org/projects/tor/attachment/ticket/23136/23136.png
-
Replying to antonela:
Hi all!
I think is pretty clear when you have 3 options. ...
Thank you for creating a new mockup.
When viewed at a high level, it is definitely clearer to have 3 radio buttons. But for the following reason that I mentioned in comment:10, Kathy and I do not think a radio button is the correct UI element to use here:
- 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.
Also, not using an overlay approach will require either a really large window or a small CAPTCHA image (and neither of these is ideal).
-
Replying to mcs:
Replying to antonela:
Hi all!
I think is pretty clear when you have 3 options. ...
Thank you for creating a new mockup.
No problem, we're here to help :)
When viewed at a high level, it is definitely clearer to have 3 radio buttons. But for the following reason that I mentioned in comment:10, Kathy and I do not think a radio button is the correct UI element to use here:
- 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.
Yes, I understand. I think that is what we do after the bridge is received is where we are missing. If we replace the content with the bridge phrase seems more clear that you are going to connect to this bridge. If the user wants, again, another bridge, he can click on [New Bridge]. After that, the captcha block will appears again.
I that way we are not compromising the other options if they are the needed ones.
Take a look at this mockup https://trac.torproject.org/projects/tor/attachment/ticket/23136/23136-1.png
Also, not using an overlay approach will require either a really large window or a small CAPTCHA image (and neither of these is ideal). Got it. We can still have the overlay if we keep the 3 options.
Definitely is something we could test with users :)
-
Replying to antonela:
Yes, I understand. I think that is what we do after the bridge is received is where we are missing. If we replace the content with the bridge phrase seems more clear that you are going to connect to this bridge. If the user wants, again, another bridge, he can click on [New Bridge]. After that, the captcha block will appears again.
I that way we are not compromising the other options if they are the needed ones.
Thanks. This is a good approach and we are working on implementation. We will let everyone how it goes!
-
Replying to mcs:
Thanks. This is a good approach and we are working on implementation. We will let everyone how it goes!
Awesome! Ping us here if you need anything :) Thanks!
-
We have been reviewing this flow a little bit more. Here is the user flow approach we end up with:
[Direct user flow - asking for a bridge for the first time]
I am a user I select 'Request a bridge' and the screen expands showing me the captcha. I type the letters from the captcha and I click on [Get Bridge] button. The IP address and signature of the bridge I got is displayed above the captcha. The captcha is refreshed and a new set of words shows up and the button next the captcha has changed and says '[Get a New Bridge]' I click [Connect]
[User flow where the user tries to get another bridge]
I am a user I select 'Request a bridge' and the screen expands showing me the captcha. I type the letters from the captcha and I click on [Get Bridge] button. The IP address and signature of the bridge I got is displayed above the captcha. The captcha is refreshed and a new set of words shows up and the button next the captcha has changed and says '[Get a New Bridge]' I don't like the bridge I have, I type the new words and I click '[Get a New Bridge]' button A new IP address and signature is shown above the captcha replacing the old one. I click [Connect]
[User flow where the user fails to solve the captcha while trying to get the first bridge]
I am a user I select 'Request a bridge' and the screen expands showing me the captcha. I type the letters from the captcha and I click on [Get Bridge] button. The letters I typed was wrong, above the captcha I see an error message. The captcha is refreshed and a new set of words shows up and the button next the captcha stays as '[Get a Bridge]' I click [Connect]
[User flow where the user fails to solve the captcha while trying to get another bridge]
I am a user I select 'Request a bridge' and the screen expands showing me the captcha. I type the letters from the captcha and I click on [Get Bridge] button. The IP address and signature of the bridge I got is displayed above the captcha. The captcha is refreshed and a new set of words shows up and the button next the captcha has changed and says '[Get a New Bridge]' The letters I typed was wrong, above the captcha I see an error message. The captcha is refreshed and a new set of words shows up and the button next the captcha stays'[Get a New Bridge]' I click [Connect]
Mockups attached -> https://trac.torproject.org/projects/tor/attachment/ticket/23136/23136-4.png
Let us know what do you think!
-
Replying to antonela:
We have been reviewing this flow a little bit more. Here is the user flow approach we end up with: ... Let us know what do you think!
Unfortunately, Kathy and I did not know that you were planning to do more design work. We have already proceeded down a different implementation path (using the overlay approach, as we discussed). Since we are already well past our engineering deadline for this task, I don't think it makes sense to switch right now to the inline flow that you have designed. Also, our implementation includes most of what you suggested. Here is some info about our flow:
- When the user clicks the "Request another bridge" radio button, a CAPTCHA prompt is shown. This prompt is overlaid on top of the other content that is in the settings panel.
- If the user cancels without completing the CAPTCHA, the prompt is closed and a "Request a Bridge…" button is displayed beneath the "Request another bridge" radio button.
- If someone who is interacting with the CAPTCHA prompt enters an incorrect response, we keep the same CAPTCHA but display the following in red below the CAPTCHA image: "The solution is not correct. Please try again."
- After the CAPTCHA is solved and a bridge is obtained, the overlay disappears and the bridge info is displayed beneath the "Request another bridge" radio button. We also change the button label to "Get a New Bridge…"
This is very similar to what you proposed, so I think we are actually in agreement on most points. Hopefully we will have a test version available soon, although we have a BridgeDB dependency and we are not 100% finished with the Tor Launcher code either.
In the meantime, please let us know if you would like us to make some screenshots. I know it is difficult to visualize the interface based on a textual description.
Trac:
Status: needs_information to new -
Replying to mcs:
Unfortunately, Kathy and I did not know that you were planning to do more design work. We have already proceeded down a different implementation path (using the overlay approach, as we discussed). Since we are already well past our engineering deadline for this task, I don't think it makes sense to switch right now to the inline flow that you have designed. Also, our implementation includes most of what you suggested.
I know this project is running late. We understand it and is ok to go with the flow you implemented. I think we will do better with timing on new projects, we are actually doing it with the roadmap coordinations which is giving time for design work etc.
Here is some info about our flow:
- When the user clicks the "Request another bridge" radio button, a CAPTCHA prompt is shown. This prompt is overlaid on top of the other content that is in the settings panel.
- If the user cancels without completing the CAPTCHA, the prompt is closed and a "Request a Bridge…" button is displayed beneath the "Request another bridge" radio button.
- If someone who is interacting with the CAPTCHA prompt enters an incorrect response, we keep the same CAPTCHA but display the following in red below the CAPTCHA image: "The solution is not correct. Please try again."
- After the CAPTCHA is solved and a bridge is obtained, the overlay disappears and the bridge info is displayed beneath the "Request another bridge" radio button. We also change the button label to "Get a New Bridge…"
This is very similar to what you proposed, so I think we are actually in agreement on most points. Hopefully we will have a test version available soon, although we have a BridgeDB dependency and we are not 100% finished with the Tor Launcher code either.
Yes, is very similar indeed. Our only concern is with the pop-out because its not always a nice experience and takes the person out of that wizard window (not as bad as we had before where the user would have to go, open their email client, type the email etc).
But I think we can totally work on testing it later on, and see how our users goes about it and if it needs any improvement. We will always be iterating with our work and we can look into that on a new iteration later, after we have the feature out and working.
In the meantime, please let us know if you would like us to make some screenshots. I know it is difficult to visualize the interface based on a textual description.
If is not too much trouble I would like that. But if its, don't worry we can play with it once is in alpha.
Question! If all goes well this implementation will be on a alpha release around Dec 15?
-
Replying to isabela:
In the meantime, please let us know if you would like us to make some screenshots. I know it is difficult to visualize the interface based on a textual description.
If is not too much trouble I would like that. But if its, don't worry we can play with it once is in alpha.
We will post some screenshots in the next few days, probably on Monday.
Question! If all goes well this implementation will be on a alpha release around Dec 15?
Unfortunately, I think we will be too late to make it into that release. Even if we can get the client side done, we do not have a server to which we can talk. Currently Kathy and I are testing with our own copy of BridgeDB that is deployed on a test server that is not on the public net.
-
Here is the CAPTCHA prompt that the user will see if they do not yet have a bridge from BridgeDB and they click the "Request Another Bridge" radio button:
Here is what they will see if they cancel out of the CAPTCHA prompt:
Here is what they will see after they submit an incorrect response:
And here is what they will see after they submit a correct CAPTCHA response (the button label is now "Request a New Bridge…" and the bridge info is displayed inline):
-
Kathy and I have been gathering various tickets that need to be fixed before we can ship this feature. We should either add them as children of this ticket or create a tracking bug.
BridgeDB/Moat tickets: legacy/trac#24432 (moved), legacy/trac#24636 (moved), legacy/trac#24637 (moved) meek tickets: legacy/trac#24640 (moved), legacy/trac#24642 (moved),
-
Trac:
Parent: N/A to legacy/trac#24689 (moved) -
Replying to mcs:
Kathy and I have been gathering various tickets that need to be fixed before we can ship this feature. We should either add them as children of this ticket or create a tracking bug.
I created a tracking ticket: legacy/trac#24689 (moved)
-
So that the code exists on a TPO server, Kathy and I pushed our development branch. Due to important dependencies such as legacy/trac#24614 (moved) and the fact that we do not yet have a public BridgeDB server to test against, it is probably not worthwhile for other people to try to use this yet. But if you want to take an early look, it is here: https://gitweb.torproject.org/user/brade/tor-launcher.git/commit/?h=bug23136-01&id=2018ac999fdaf54f00b3e3a303d167d02086e29b
-
Kathy and I are making this code available for review. It has been in a nearly finished state for a long time. The patch is here: https://gitweb.torproject.org/user/brade/tor-launcher.git/commit/?h=bug23136-02
There are still some dependencies that need to be resolved:
-
You will need to compile and use a
meek-clientandmeek-client-torbrowserthat includes the fix for legacy/trac#24642 (moved). We do not have a new meek tag yet so you will need to pull the code from dcf's bug24642 branch. -
For some reason the deployed BridgeDB does not return any bridges (see https://trac.torproject.org/projects/tor/ticket/24432#comment:24). In the meantime, I set up a very temporary BridgeDB test server. Note that it is not behind a domain fronting setup, it does not use TLS, it only has fake bridges, and since it does not have any vanilla ones you should request obfs4 bridges. Here are pref settings for the test server: pref("extensions.torlauncher.bridgedb_front", ""); pref("extensions.torlauncher.bridgedb_reflector", "http://pearlcrescent.com:2000"); pref("extensions.torlauncher.moat_service", "http://pearlcrescent.com/meek/moat"); pref("extensions.torlauncher.bridgedb_bridge_type", "obfs4"); Oh, and our test server uses really easy CAPTCHAs except for one BridgeDB one.
Trac:
Status: new to needs_review
Keywords: TorBrowserTeam201802 deleted, TorBrowserTeam201802R added -
-
I almost forgot: for the Moat connection to work reliably, you also need to remove the SOCKS optimistic data feature from Tor Browser (legacy/trac#19910 (moved)).
-
Interaction with the production BridgeDB server is now working!
A revised patch is available on our bug23136-03 branch, here: https://gitweb.torproject.org/user/brade/tor-launcher.git/commit/?h=bug23136-03&id=96bef5e01126972fd92b29829bc0f59e9303de12
Changes compared to our previous patch:
- Request obfs4 bridges instead of vanilla ones (since BridgeDB's Moat distributor has a pool of obfs4 ones to give out).
- We made a few minor changes to the Moat request messages to match recent server changes (use strings for values).
