Improve Bridge Selection

[cstiens]

@tladesignz We have screens for the full workflows of using customs bridges and getting a bridge from Tor. I think there are some additional considerations based on our recent conversations in #39. I'll review and provide a design update and the full UI.

[tladesignz]

Yes. Here are some additional things I was thinking about, since I started to work on this already and compare it with what we currently have:

• Error states: The CAPTCHA is loaded from somewhere. Network errors happen frequently. What to do then? Currently, we're showing alerts.
• CAPTCHA reload: Users might have to trigger a reload, because the generated CAPTCHA is unreadable to them.
• What's with Snowflake with AMP rendezvous? This is a different way of how the rendezvous is done (via Google AMP cache instead of domain fronting). This might be helpful, in case e.g. a censor blocks access to the current front domain completely (currently fastly.net AFAIR) or they find a different way to block more granular. Cannot be really automated, though, besides just adding it to the smart connect rotation of things to try. Why do we drop that offer?
• Regarding custom bridges:
  • Currently, we provide information and a copy-to-clipboard feature, on where they could get bridges (https://bridges.torproject.org). Why do we now stop teaching users about it?
  • Currently, users can also use screenshots of QR codes. Why do we stop offer that feature?
  • There's also a feature to request bridges via mail. Why do we drop this feature?

[cstiens]

Here's a video walkthrough of the design for manual bridge options in Orbot. I've removed 'smart connect' from the list of options. However, the notes expressed above may not be considered. Also, please note — there is no concept of managing custom bridges in Orbot Android right now.

Orbot-Manual.Bridge.Selection_Oct2022.mp4

[tladesignz]

Another question: What's with the built-in Obfs4 bridges? These aren't very helpful, when it comes to censorship circumvention of nation-state players, because they're mostly blocked in these counries. But when it comes to libraries and companies, which just do Deep-Packet-Inspection and block plain Tor traffic, they're pretty helpful, because they're high-bandwidth.

[tladesignz]

Another error state:
Scanning might not initialize, because the user didn't grant camera access, or due to parental controls.
What to show then instead?
Please provide any placeholder images (SVG!) and text wording.

Hint: We could send them to the area of the Orbot app inside the Settings app, where users can change their opinion about if they want to grant camera access...

[tladesignz]

Re CAPTCHA: These do not load instantly. Currently we show a modal spinner. User's can only go back, nothing else. All other elements are greyed out. Any changes?

[tladesignz]

There's now also a Telegram bot: https://tb-manual.torproject.org/bridges/

[tladesignz]

I made a screencast from the simulator which shows, what I implemented until now.

Note:

• I re-added the features which you dropped, but I think are necessary to maximize utility for our users. Some of them who are also power users. Some of them live in very constrained environments and don't have knowledgable friends, so we should offer them every opportunity to get a bridge. (Like via email or Telegram.)

• Can't show you the email flow, as the simulator doesn't support that. What happens is just, that a "new email" scene opens with a prefilled email. If you send the mail (or store it), Orbot bumps you to the custom bridges scene, where the user should copy-paste the bridge strings, which they then hopefully receive via mail.

• Similar for Telegram: The browser in the demo shows an error, but if the Telegram app is installed, it should actually open a conversation with the bot.

• Obfs4 bridges almost always come in bunches. So: plural.

• The size you see here is iPhone SE 1st gen. The smallest device we need to support. Stuff needs to fit on there. The video appears pretty big, but understand, that the physical device size is somewhere between 1.25 - 4 times smaller than what you see (depends on your monitor setup): Device resolution is 326 pixel-per-inch!

Work left for you, @cstiens:

• Refine wording. (I made some texts up on the fly. Please improve!)
• Sort items.
• Improve UX of error states?
• We should explicitly hint about https://bridges.torproject.org to make users understand where this is from, or where friends in another country can go and send them a screenshot from.

Work left for me:

• The Captcha will get a refresh button.

Simulator.Screen.Recording.-.iPhone.SE.@.iOS.15.5.-.2023-01-18.at.13.48.38.mp4

[cstiens]

@tladesignz It's looking great! I will have a deeper review of the questions in this issue and the implementation and provide further feedback.

[cstiens]

I re-added the features which you dropped, but I think are necessary to maximize utility for our users. Some of them who are also power users. Some of them live in very constrained environments and don't have knowledgable friends, so we should offer them every opportunity to get a bridge. (Like via email or Telegram.)

I agree with this mentality and approach. I have a couple of things to note:

We had removed email due to the understanding that entering a captcha to request the bridges would give you the same type of information. ie. If you're requesting a bridge from Tor, you will get the same bridge lines if you get them directly from the app via captcha or if you request them over email. @tladesignz Is that correct?
If they are the same, perhaps we benefit the user by simplifying their choices to present the safer option only (ie. captcha). Open to thoughts. If they are different, please tell me how and I can help with the subtext language.

I love the addition of Telegram! It is useful for people discovering the Telegram bot. Previously the thinking was that you would receive from Telegram, then copy/paste in. I like having this approach as well. 👍👍👍

Work left for you, @cstiens:

Noted.

Sort items.

@tladesignz What do you mean here?

Last question. What is Snowflake (AMP rendezvous)?
How does the interaction by the user differ from regular Snowflake? Why would they choose it instead of Snowflake?

[tladesignz]

We had removed email due to the understanding that entering a captcha to request the bridges would give you the same type of information. ie. If you're requesting a bridge from Tor, you will get the same bridge lines if you get them directly from the app via captcha or if you request them over email. @tladesignz Is that correct? If they are the same, perhaps we benefit the user by simplifying their choices to present the safer option only (ie. captcha). Open to thoughts. If they are different, please tell me how and I can help with the subtext language.

They give you the same type of information. But not necessarily the same information. You probably get different Obfs4 bridges. Same with the Telegram bot. It's not about different information, though, but about different ways of reaching the user.

The rdsys (formerly MOAT) interface ("Get bridges from Tor") is a HTTP API. It is secured via a technique called "domain fronting", meaning, if a censor wants to block access, they need to block access for a lot of other things at the same time. (That's why it's also termed "collateral freedom".)
However, the providers used for this are getting smaller and smaller, because the really big ones like Google, Amazon and Microsoft started banning and blocking this technique.

So, it becomes more and more viable to actually block all access. But when this happens, access via email may still be possible.
Same goes for the Telegram bot. That one does give you the same type of information, too. Just via another channel which is hard - and very differently hard - to block.

I love the addition of Telegram! It is useful for people discovering the Telegram bot. Previously the thinking was that you would receive from Telegram, then copy/paste in. I like having this approach as well. 👍👍👍

Sure, that's what you need to do: copy and paste. But people need to actually know about it. And then find it. I don't see a reason why we shouldn't help with that.

Sort items.

@tladesignz What do you mean here?

Maybe you want to change the order of things in the list? That's what I meant.

Last question. What is Snowflake (AMP rendezvous)? How does the interaction by the user differ from regular Snowflake? Why would they choose it instead of Snowflake?

In Snowflake, the actual connections between you and the first Tor node are routed via a volunteer's computer. But to find a volunteer, there's a broker server. You need to talk to that one first, and the broker will find a volunteer for you. Again, domain fronting is used to tunnel through a censor's firewall. (See above.)

But there's another option to reach the broker server: Google AMP cache. When the Fastly domain front (currently used) gets blocked, you might still be able to reach the Google AMP cache and use Snowflake this way.

We might consider adding that to the list of things to try in smart connect, btw.

We cannot tell Snowflake to automatically switch over on its own, however. The Snowflake client code needs to get restarted with a different configuration. It cannot use both at the same time. That's why we need to offer it for manual configuration. The very constrained users (and the folks who like to play a lot) should be able to try every means possible. And it's also good, when people distribute themselves.

[cstiens]

@tladesignz I took a pass at the order and copy. See below. After going through this, I so badly want to group things and nest options. But... in order to try to keep it simple and get this pushed, this works. The method for ordering is based on a combination of what's easy to get and most likely to work (ie. what are currently more resilient bridges). ... Acknowledging that that's a tough call to make and is likely to change.

Direct Connection
The best way to connect to Tor. Use if Tor is not blocked.

Snowflake (original)
Connects through Tor volunteers. Gets around some Tor blocking.

Snowflake (AMP)
Connects through Tor volunteers. But uses a different method than 'original' to find the first volunteer. Gets around some Tor blocking.

Bridge from Tor (obsf4) via Telegram
Likely to keep you connected if Tor is severely blocked. Using this method will launch the Tor Bot Telegram channel. Tap 'Start' or write '/start/ in the chat to get a bridge address.

Bridge from Tor (obsf4) after Capchta
Cloaks your traffic. Gets around some Tor blocking.

Built-in Bridge (obsf4)
Cloaks your traffic. Gets around some Tor blocking. Good if you're on public wifi, but in a country where Tor isn't blocked.

Bridge from Tor (obsf4) via email
Cloaks your traffic. Gets around some Tor blocking. Requires an email sent from a Gmail or Riseup account.

Custom Bridge
Most likely to keep you connected if Tor is severely blocked. Requires a bridge address from someone you trust.

[n8fr8]

Perhaps

"Bridge from Tor (obsf4) after Capchta"

should be

"Request a new bridge from Tor"

I think the word "Capchta" is strange to use for many reasons, and perhaps doesn't translate well?

I also question putting in the email or telegram choices as separate options in the list here. In the "custom bridge" sectio, we could indicate that bridges can be requested via these methods, and provide some information on how to do that.

[cstiens]

Thanks for the feedback! Yeah. I had used captcha because I was trying to give an indication of 'how' you get these things. What it takes. ie. 'you have to send and email', you need to solve a captcha, etc.

perhaps solving a captcha is trivial and doesn't need to be called out though.

I also question putting in the email or telegram choices as separate options in the list here. In the "custom bridge" section, we could indicate that bridges can be requested via these methods, and provide some information on how to do that.

Good feedback. This was the leaning I was having as well.. in regards to grouping items.

[cstiens]

Based on my understanding of bridges, I made a sketch on how I would make bridge recommendations if I were doing a basic Tor training for people from multiple regions. This is what I'd like to be able to communicate in the view where people are choosing their own bridge. If people don't have the technical background, it's helpful to give an indication of what's most likely to work (strong, stronger, strongest) and how easy it is to get them (colors).

[cstiens]

Two updates:

1. I'm working through the UX for grouping the custom bridges into one option.
2. We've decided to move the auto/smart connect 'ask' to the bridge selection view. In this view, the user can 'ask tor' for a recommendation. The API will tell them which method to use. Then users can click connect to get connected (and of course, find out if it will work for them.) If it doesn't work for them, we will walk them through other methods to try. This is the fail scenario we designed for early on. We need to revisit a bit, since we have the addition of Telegram as a method for getting custom bridges. So we'll run an UX cycle on that.

This solution can allow us to ditch the 2 button UI we had originally planned for return use.

[tladesignz]

Woah? That's not what I understood. Why should we ditch the "Smart Connect"? That is a really good idea!

[cstiens]

Why should we ditch the "Smart Connect"? That is a really good idea!

We wouldn't ditch it. We would run it the first time. Then on return use, you would run it from this 'Choose How To Connect' view. ... But, I guess we don't get the full benefits by doing it in this view, huh? Like it would only tell you what Tor thinks. But it wouldn't try other methods afterward if the recommendation didn't work. Or maybe it could. We would essentially try the Tor recommendation. Then if that didn't work, prompt the user to ask if they want to app to run Smart Connect / connect whichever way possible.

It seems we might loose the magic by requiring more steps and breaking the process up. We should discuss on a call.
I'm trying to get us away from 2 start buttons on the home view...

If we keep the Smart Connect option on the home screen for return use, here's another way we could do it.

Screen.Recording.2023-03-03.at.12.23.02.PM.mov

[tladesignz]

We wouldn't ditch it. We would run it the first time. Then on return use, you would run it from this 'Choose How To Connect' view. ... But, I guess we don't get the full benefits by doing it in this view, huh? Like it would only tell you what Tor thinks. But it wouldn't try other methods afterward if the recommendation didn't work.

Yes, exactly. It's not the same thing.

Or maybe it could. We would essentially try the Tor recommendation. Then if that didn't work, prompt the user to ask if they want to app to run Smart Connect / connect whichever way possible.

That really sounds annoying for both the programmer and the user. It's complicated to implement and it also complicates things for the user. It actually hides the smart connect feature and then makes it more cumbersome to use.

If we keep the Smart Connect option on the home screen for return use, here's another way we could do it.

Yeah, that's what I wanted to suggest, too. If you don't like 2 big buttons of the same size, then do a checkbox or different button sizes.

[cstiens]

Recapping from the scrum discussion..

• We keep the full list at the top level. This approach allows a user to see all of their options in one view. It also means that we retain only 2 levels of information rather than nesting.

• We need to adapt the language on the second 'custom bridge' view so that it's relevant depending on where they are coming from. (ie. If they got bridges from Telegram, Email or selected to input one from a friend.
• If the user is getting a bridge from a friend. That friend is either hosting a bridge on their own server or can go to bridges.torproject.org to get one for their friend. We would link them to https://bridges.torproject.org/options/ or https://bridges.torproject.org/bridges/?transport=obfs4. We'll tweak the language for this on the Custom Bridge (from a friend) view.

Last, we keep the option to run Smart Connect in the home view on return use. We move away from the 2 button approach and use the checkbox instead.

[n8fr8]

I would like to find a way to use smart connect without it being a big checkbox option on the main screen. Seems like maybe if the current option the user has selected fails, we can prompt them to "try another way?" and then smart conncect kicks in.

I really like the "Ask Tor" option, and how you have implemented it on iOS @tladesignz - very clear and useful.

[cstiens]

Seems like maybe if the current option the user has selected fails, we can prompt them to "try another way?" and then smart connect kicks in.

We've discussed adding this in—the fall-back to smart connect if the current method doesn't work. I think the prompt to the user is really important in this case. This is not implemented on iOS yet. Because we need a design cycle first.

From our discussions, having the smart connect very accessible (in one tap) remains important. Otherwise, we're costing the user time and friction to connect. They may not know if the current method will work, and want to run smart connect right away. @tladesignz anything else to add here from our conversations this week?

[cstiens]

One more thing to add, we will run usability tests on the Connect view and Choose How to Connect view in our workshops in Mexico. They will have people who are new to Tor and familiar with Tor.

[tladesignz]

I would like to find a way to use smart connect without it being a big checkbox option on the main screen. Seems like maybe if the current option the user has selected fails, we can prompt them to "try another way?" and then smart conncect kicks in.

@cstiens and I discussed this at length. I don't see any other sensible way. Things to consider:

• We cannot tell when we don't succeed. We can just assume that we get blocked after a wild guess on amount of time passed.
• Prompt can certainly not be modal, as that prompt might come at the completely wrong time for the user.
• We don't have any context information nor should we try to get it, as that might be super-invasive.
• Why make the user do things, when they know, it won't work, and they know the solution would be to use smart connect?

=> We need to help the users help themselves, and otherwise stay out of the way.

Providing three obvious options

1. Do as last time
2. Smart connect
3. Manual configuration

Seems like the most sensible thing for me to do in this case.

I really like the "Ask Tor" option, and how you have implemented it on iOS @tladesignz - very clear and useful.

Thanks. We had that for a year or something. This is just @cstiens new UI.

[n8fr8]

We had that for a year or something. This is just @cstiens new UI.

I like the new UI.

[n8fr8]

My naive high-level goal with this Orbot re-design was to simpllify things, and somehow it feels like we haven't.

[tladesignz]

My naive high-level goal with this Orbot re-design was to simpllify things, and somehow it feels like we haven't.

I'd definitely say we improved things. I'd also say, we simplified things for users. Esp. the smart connect feature is a big step forward, and the reorganisation of transport options is, too, very much.

However, true security is complicated and its complexities cannot be hidden away without degrading it. The way, Tor is architected, even less so.

Don't kid yourself: If you now think "But Signal can!", think twice. They only achieve this simplicity, because they basically ignore authentication. But encryption without authentication only protects you 1/3 of the way.

Anyway, simplification in itself is not a sensible goal: Only clever simplification can be. But if that's unachievable, stupid simplification (aka. just dropping options) is not a great replacement.