Smart Connect

[cstiens]

As reference, here's a link to the Figma file that has all of the design work: https://www.figma.com/file/c22a0Vn4QjmoviIi9Oj5eB/Orbot-%5BLatest%5D?node-id=1407%3A11214

The Master page has the Android design for Smart Connect. The documentation that's been started is here: https://github.com/guardianproject/orbot/blob/master/docs/smart-connect-design-spec.md Though, we need to update it.

[tladesignz]

So, last week I had a talk with @n8fr8 about this again during our call. He's also struggling with the implementation and with the intricacies.

He wanted to experiment some more.

I would suggest we 3 do a call to finalize the spec, but we could also discuss here.

I'll throw in my "yes, buts" here again:

From my perspective, full automation is unachievable, because

• in gathering, we would leak information. (E.g. asking rdsys/MOAT for its opinion on every start leaks information to Tor Project about every start, and in a lesser way, because the request is domain-fronted, but still, to any passive listener on the network.)
• We would look very intrusive (e.g. asking the user to allow us access to geolocation would raise a lot of eyebrows) and also might waste a lot of battery.
• Changes in connectivity esp. on mobile devices can happen all the time in unpredictable ways. (E.g. switching from WiFi to mobile; switching from 4G to GPRS)
• Measurements are unreliable, as we cannot distinguish between censorship blocks or bad reception due to basement car garage.

I instead suggest providing two buttons:

1. button starts Tor with the configuration as-is. (And current config is reflected on it!)
2. button triggers a full analysis to find the best way to connect:

• ask user about their preferences (esp. "I positively want a bridge!" and "here's the bridges a friend/Tor/whoever gave me)
• ask moat about its opinion
• start Tor
• if no change in progress for x[^1] seconds, reconfigure Tor to use Snowflake
• if no change in progress for x[^1] seconds, reconfigure Tor to use Obfs4proxy
• if no change in progress for x[^1] seconds, give up and tell user they'll need to get a hidden bridge via a friend or the moat email service or bridges.torproject.org, if they can reach it.

While doing that, show detailed status, about what's going on.[^2] E.g. "Asking MOAT service about what probably works..." "MOAT says, direct connection should work. Trying..." "Direct connection to Tor seems not good - trying Snowflake bridge..." "Connection to a Snowflake seems not good - trying Obfs4 bridges..." "Try to connect using your provided bridges..."

[^1]: I think timeout seconds should be configurable somewhere deep in the menus, so workshops can try out different values and we can get feedback about what default works best! My first guess is 30 seconds, though.

[^2]: I do believe, that it does make sense to throw technical terms at users. First, there are the ones, who understand what's going on and they'll deeply appreciate that we tell them exactly. Second, we need to offer an opportunity for the unknowledgeable users to learn, what's actually going on under the hood, so they get better at staying safe and getting connected at all. I feel, that due to the way, Tor is built, there is no way to provide a "just connect me and get out of the way"-button. As with all thing security, you cannot really be secure, if you don't have at least a high-level understanding about what's going on.

[n8fr8]

About the dialog:

1. Rename "Smart connect" to "Automatic" - simpler, and less boastful
2. Remove "Get a bridge" in configuration option list - it is an action not a configuration option; instead "Get a bridge from Tor" should be an option on the pop-up textfield screen that opens if you tap on "Custom bridge..."
3. Change "Connect" to Save - since we don't want to assume they want to connect immediately if they just want to change the settings

[n8fr8]

About the logic:

• The first time a user starts up, we always are set to "Automatic". However, they should have a chance to change that in the network configuration dialog before they try to connect for the first time.
• Once Automatic runs once, we remember the configuration that has worked for them, and use it again in subsequent connections; HOWEVER, we still show "Automatic" in the network configuration dialog. We don't change it to Snowflake, etc, even if that is what the Automatic process has found works.
• Somewhere in the UI, there needs to be a way for the user to choose "try another way" or "refresh" or "HELP!" that clears the persisted Automatic state, and starts fresh again

What Automatic (formerly known as Smart Connect), means is

• connect to the Tor Rdsys/Circumvention API over Moat, and ask what configuration should be used, and use it
• no timeout, no failover, etc... just do what Tor says

[cstiens]

My takeaways from the call were as follows:

• Smart connect should not persist as a method for connecting to Tor. Rather, it's the mechanism to get help from Tor in deciding how to connect. So, the experience is that you run it, and get a result. We do not want to run it every time the user connects to Tor. I will consider how the UX should work for Smart connect based on this premise.

• Side note: The reason we have the smart connect feature is because people (general users who are not trained on Tor) are confused about bridges. They don't know when to use them or why. They simply know — if the app works when they tap connect or not. We need to stay focused on this issue as the central driver for our decisions.

For Discussion: If smart connect is limited to giving a recommendation from the Tor API, we will still have cases where people tap to connect, and it doesn't work. Here are the scenarios:

• If they are in a country where Tor isn't blocked (ie. Mexico), but in a location where it is (ie. Campus library).
• If the Tor Circumvention API is wrong. (ie. Snowflake worked in Country A yesterday, but it doesn't today)

If we don't give guidance in the UI, then we have the same experience we have in Orbot now. Which is the notion that you may need to use a bridge, but no actionable guidance. I think we need to do better here. This was the purpose in having the failover workflow. We can put a hold on that or rethink it. But, these are important cases to account for.

Remove "Get a bridge" in configuration option list - it is an action not a configuration option; instead "Get a bridge from Tor" should be an option on the pop-up textfield screen that opens if you tap on "Custom bridge..."

• @n8fr8 are we ditching the workflow to get a bridge from Tor that requires a captcha?

[n8fr8]

I agree, we can still try to implement failover. That should only happen when "Automatic" (err, maybe stil Smart Connect!) option is selected

We still will support the Moat API captcha workflow, but it should be under the "Custom bridges..." option.

[cstiens]

We still will support the Moat API captcha workflow, but it should be under the "Custom bridges..." option.

@n8fr8 Can you expand on why you say it should be under custom bridges? In the current mockups, it's displayed as a separate options for a few reasons, which I'll outline below.

1. The offering of the feature (Tor obsf4 bridge can be potentially detected more easily if the censor gets ahold of the list of obsf4 bridges; a custom bridge from a friend will be more difficult to detect)

2. The usability of getting the bridge is different (obsf4 you solve a capchta; custom bridge requires a bridge link or QR code from a friend)

Happy to update the designs as things evolve. But it's useful to understand why, and if there are new needs that weren't originally considered.

Also, since users can get an obsf4 bridge directly from Tor via auto-connect (without solving a captcha), why would they want to deal with captchas? I assume that it's so they don't have to hit the server. But I don't fully understand. And may be totally wrong. ;)

[n8fr8]

The "network settings" is that you are using a custom bridge. That bridge address can be provided in a few ways:

• through signal, telegram, email from tor support channels
• by a friend through some other channel, copy and paste, qr code
• by requesting one directly from tor through solving a captcha

the result of all of these things is a custom bridge string in the custom bridge field., and then the "custom bridge" radio button is selected in the configure dialog.

[n8fr8]

as for why would we maintain this feature while also having smart connect/automatic mode? I'm not as sure about that, and we should just follow whatever Tor Browser 12 is doing - do they have both?

[cstiens]

as for why would we maintain this feature while also having smart connect/automatic mode? I'm not as sure about that, and we should just follow whatever Tor Browser 12 is doing - do they have both?

@tladesignz can you help find the answer to this?

[n8fr8]

Seems like they don't have the circumvention API feature in yet?

[tladesignz]

as for why would we maintain this feature while also having smart connect/automatic mode? I'm not as sure about that, and we should just follow whatever Tor Browser 12 is doing - do they have both?

@tladesignz can you help find the answer to this?

Yes. There are 2 ways to fetch bridges via an API now, as mentioned:

1. Old-school, 2-step with CAPTCHA.
2. New Circumvention API without CAPTCHA.

The CAPTCHA in (1) is there, to stop/slow down automatic harvesting of all (or most) Obfs4 bridges, because that API will give you most of them after enough requests from different IP source addresses.

To be able to get rid of the CAPTCHA in (2), it has a lot of other countermeasures:

• It will only give you bridges from the non-public (or non-default) pool, if you ask for the right country. (Which can be set by an attacker, but wouldn't be changeable by our users).
• It splits the list of non-public Obfs4 bridges into buckets and only hands out bridges from a single bucket to an IP-address region.
• AFAIR: Every source IP will get the same 2 non-public bridges for 30 days, regardless how often it asks.
• Buckets are rotated only after 30 days.

=> To create an (almost) complete list of non-public Obfs4 bridges, an attacker will need access to a huge diverse set of IP addresses and a lot of time. So, no need for CAPTCHAs anymore.

For our users, that means, they potentially get a list of Obfs4 non-public bridges, which are already blocked, and they have no chance to get another for the next 15 days (on average). That's when you would want to use the good ole' CAPTCHA API.

[tladesignz]

So, I cobbled together something from all the information and ideas lying around and released it as Orbot iOS/macOS 1.5.0.

The smart connect now mostly works as I outlined above. Looks pretty stable to me in my non-censored high-throughput environment. Very curious about the feedback from the more limited areas of the world.

Also looking forward to your improvement suggestions!

I will now start working on an improved bridge selection screen. I'll try to pick the best ideas from all the written ideas and drawn sketches, but I'm more than happy if there would be a final decision and a sketch on how that should look like!

Ah, and, @cstiens, please note: A drawer from the bottom doesn't fly on iPads (and macOS). Would be too far away from where the user tapped. I'll implement this as a popover/window, same as it now is.

[cstiens]

Ah, and, @cstiens, please note: A drawer from the bottom doesn't fly on iPads (and macOS). Would be too far away from where the user tapped. I'll implement this as a popover/window, same as it now is.

Good call. It seems Apple does not have a standard guideline for 'sheets' on ipads that is different from iPhone. ('sheets' = drawer from the bottom). https://developer.apple.com/design/human-interface-guidelines/components/presentation/sheets/

Though, they do give a different recommendation for macOS.

[cstiens]

The smart connect now mostly works as I outlined above. Looks pretty stable to me in my non-censored high-throughput environment. Very curious about the feedback from the more limited areas of the world.

@tladesignz Is there any way we can simulate a test for this for ourselves? I guess it would be 2 part. 1) low-bandwidth internet; 2) network that blocks Tor. Otherwise, perhaps we need to engage testing partners on the ground.

I will now start working on an improved bridge selection screen. I'll try to pick the best ideas from all the written ideas and drawn sketches, but I'm more than happy if there would be a final decision and a sketch on how that should look like!

I've create a separate issue for bridge selection: https://github.com/guardianproject/orbot-apple/issues/46

[n8fr8]

Using Little Snitch on a Mac with an iOS Simulator is a good way to selective block outbound connections.

[tladesignz]

Using Little Snitch on a Mac with an iOS Simulator is a good way to selective block outbound connections.

• Little Snitch costs money.
• Orbot doesn't run in an iOS simulator.

@tladesignz Is there any way we can simulate a test for this for ourselves? I guess it would be 2 part. 1) low-bandwidth internet; 2) network that blocks Tor.

The easiest and cheapest thing you can do is install Orbot macOS on your Mac, and also install the Network Link Conditioner Preference Pane which can be found in the Additional Tools for Xcode package.

More info about it here: https://nshipster.com/network-link-conditioner/

[n8fr8]

Happy to reimburse for Little Snitch as a testing tool - since it can block specific sites, domains, etc

Great to know about Network Link Conditioner

[tladesignz]

Ha, totally forgot: This is also available under iOS, already built-in. You need to get it into developer mode, though. See the NSHipster article at the bottom on how to do that. @cstiens, maybe your device is already in dev mode, since I think I remember using it with my computer when I visited you. If not, you will need to download and install Xcode. :-(

[tladesignz]

Ah, and, @cstiens, please note: A drawer from the bottom doesn't fly on iPads (and macOS). Would be too far away from where the user tapped. I'll implement this as a popover/window, same as it now is.

Good call. It seems Apple does not have a standard guideline for 'sheets' on ipads that is different from iPhone. ('sheets' = drawer from the bottom). https://developer.apple.com/design/human-interface-guidelines/components/presentation/sheets/

Though, they do give a different recommendation for macOS.

From that linked article:

To present immersive content or enable complex tasks, consider alternatives to sheets. For example, iOS and iPadOS offer a full-screen style of modal view that can work well to display immersive content — like videos, photos, or camera views — or multistep tasks like document or photo editing. (For developer guidance, see UIModalPresentationStyle.fullScreen.) In a macOS experience, you might want to open a new window or let people enter full-screen mode instead of using a sheet. For example, a self-contained task like editing a document tends to work well in a separate window, whereas full-screen mode can help people view media or perform a more immersive task.

We're not doing sheets/bottom drawers. They are meant to provide extra buttons while editing in the main scene, not complicated multi-step settings, you'll only do once in a while.

It's going to be a popover, which covers the full screen on phones, and which uses the space of a typical phone on tablets showing right next to the button where the user tapped.

On macOS, the main window is quite small compared to the whole available screen. Therefore it makes no sense showing inside that window. It's going to be a modal window there, which uses just enough space to show all things.

In other words: No changes to how it currently works.

[cstiens]

Note: We've resolved our understanding and use of views in a side chat.

[tladesignz]

Closing this, since Smart Connect is now implemented since a while and there's no real push to improve further. Please reopen if you feel the necessity!