This is about #10491.

Current issues in Tails

  • A. After Tails Greeter, it might be hard for some people to understand where to click on the GNOME desktop to connect to a Wi-Fi network.

  • B. It's impossible to go from direct Tor connection to bridge mode in case you realize once in the session that you actually need bridges to connect.

  • C. It's hard to know whether you need to log in through a captive portal. (#5785)

  • D. There's no way of triggering Tor to reconnect after logging in through a captive portal, except by closing the Unsafe Browser (which is not obvious).

  • E. Once cannot set up bridges if they need the Unsafe Browser (to log into a captive portal or to get bridges), if they close the Unsafe Browser (that restarts Tor which breaks Tor Launcher). Too bad, for non-bridge use cases one has to close the Unsafe Browser to make Tor connect. (#11535)

  • F. It can be scary for people who cannot afford connecting without obfuscated PTs (to hide they're using Tor) to postpone this choice after the session is started.

  • G. Bridges, firewall and proxy have to be configured again each time. (#5461)

  • H. It's not clear how one is supposed to get bridges if they need some.

  • I. One can't get bridges automatically if one needs some to connect.

  • J. There is no visual feedback on whether the connection to Tor is making progress.

  • K. If MAC spoofing fails but I decide that it's OK not to spoof MAC in my situation, then I have to reboot Tails all the way.

  • L. The Unsafe Browser allows to retrieve the public IP address by a compromised amnesia user with no user interaction. (#15635)

  • M. No audio in Unsafe Browser breaks accessible CAPTCHAs. (#16795)

  • N. People use the Unsafe Browser to browser the Internet.

  • O. A persistent network connection is associated to a specific network interface (via its MAC address) so it cannot be reused easily when hoping between computers with the same Tails. (#10803)

  • P. People who cannot afford connecting without obfuscated PTs (to hide they're using Tor) have very little margin for error: if they forget to choose the right option in the Greeter, their last chance is to notice their mistake before connecting to a network (which might be automatic).

  • Q. Hard to connect using PTs when the computer's hardware clock is not set to the current, correct UTC time

    This is one of the top complaints we get from censored users. tor's improvements wrt. accepting a consensus that's a little in the past or in the future should help, but will probably not fix all these problems, that stem from the fact Tails can't easily tell whether the hardware clock is in UTC or local time, combined with the fact Tails can't tell what the local timezone is.

Open questions

  • What's left from this configuration process on the desktop after Tor is started? Do we allow changing or visualizing the current settings?

  • In the current mockups, to use a wired DHCP connection or a Wi-Fi network saved in persistence with the default settings (direct Tor, MAC spoofing), one needs to click twice. While in current Tails, it works automatically with no user interaction. Both have pros and cons.

Out of scope

  • Adversary who blocks access to the captive portal they control once they notice you're using Tor: they can as well forbid your MAC address from connecting to their Wi-Fi AP.

  • People who have to disable MAC spoofing all the time as this is pretty uncommon, cf. #16385#note-5. As long as they can do this manually every time they start Tails (as they do currently), or for each new Wi-Fi network they connect to, that will be good enough. That is, we don't improve UX for this use case, but we don't make it worse either.

  • Problem O: it's fully orthogonal to the other problems and the solutions to it are orthogonal to the solutions envisioned for the other problems.

Iterations

First batch

  1. Enable "bridge mode" by default and remove it from the Greeter That is, start Tor Launcher on every connection to a network, if we never successfully connected to tor during this session, or if our last attempt to connect to tor during this session failed.

    And then:

    • Don't restart Tor anymore when exiting the Unsafe Browser, otherwise this breaks Tor Launcher.
    • If time allows, we can consider removing the "Tor is ready" notification, now that we have feedback wrt. the status of connecting to Tor (#8061).

    • Solves issues: B, J.

    • Improves issues:
      • P: the prompt for bridges will get in your way while connecting to the network, which is better than the current workflow where you have to remember to activate it in Tails Greeter
      • C: you know it's not worth waiting longer
      • D and E: Tor Launcher lets you retrigger tor bootstrap, either manually or after a timeout
    • Bonus points: makes UX closer to the one in regular Tor Browser.
    • Worsens issues: F (temporarily and for 1st time users affected by issue F, until they understand that the new behaviour behaves by default, all of the time, in they way they had to opt-in for previously). → Add a temporary note about the change in Tails Greeter.
    • Cost:
      • Need to deal with tor's sandbox settings (currently we disable it in bridge mode) or accept losing some security here.
      • How to tell Tor Launcher that last settings failed and it needs to prompt for manual config again. Does Tor Launcher load previous settings from torrc / via the control port, or does it store them somewhere itself?
      • Test suite needs quite a bit of updating wrt. waiting for Tor to be ready.
      • Needs new automated tests for the handling of the various failure modes (whether or not we start Tor Launcher again on 2nd and further connections).
      • Doc probably needs updates.
  2. Persistent Tor settings — #5461

    • Let's assume here that iteration 1 is done already.
    • Solves issues: G.
    • Improves issues:
      • F (increases user confidence in Tails consistently doing what they need)
      • P (not fully solved as the user still can forget to unlock their persistent volume in the Greeter; we could improve further via #15573)
    • Cost:
      • Needs sync'ing relevant torrc settings to a persistent file, and back.
      • Needs Tor Launcher to load these settings but that should be handled by iteration 1 already.
      • Needs new automated test scenarios: persisting settings initially, updating persistent settings (in the live environment and in persistent storage), clearing them up.
      • Doc needs updates.

    Shall they be global or per-network? Per-network is vastly harder to implement and makes UX more complex. Per-network could be useful for:

    • I want to hide I use Tor for this place → solved by iteration 1: as long as Tor Launcher pops up and I get to choose whether I want to diverge from my usual, persistent settings.
    • I need to use a proxy when I'm in this place → solved by iteration 1 (same as above).
    • The ISP in this place blocks Tor and I'd rather not use bridges everywhere else as I don't need them (but it does not hurt much) → solved by iteration 1 (same as above).

    ⇒ No, we won't do per-network persistent Tor settings, but global ones.

    In any case, the user needs to be allowed to revisit their choices that were persisted. How?

  3. Automatic bridges/PTs retrieval (Moat) — #15331

    • Solves issues: H, I
    • Bonus points: UX closer to Tor Browser's
    • Benefit seems marginally higher than persistent Tor settings for our personas.
    • Cost: at first sight, vastly higher than persistent Tor settings

    While designing/implementing solutions, keep Snowflake in mind (#5494): it might require similar kludges to Moat, so better use kludges that will work for both.

Potential extra iterations

Not ordered yet.

  • Better UX wrt. clock & timezone — #5774

    Current design & iterations probably needs an update.

    • Solves issues: Q
    • Benefit: higher than Moat (would be ridiculous to help folks get PTs if they can't connect to tor via these PTs)
    • Cost: to be evaluated in order to prioritize this vs. Moat
  • Include configuration with default bridges/PTs — #8825

    Why we want to do it: it will make Tails work out-of-the-box for some censored users, while currently they need to find out how to get their own bridges before they can even try using Tails, which is discouraging.

    Why it's not trivial: as long as using custom bridges requires typing them every time they start Tails, users will use the default ones. So in order not to overuse these default bridges/PTs, this feature requires allowing Tails users to configure their own bridges/PTs in a persistent manner; and/or perhaps Moat support too, in order to encourage them even more to use their own bridges/PTs.

    But once we have Moat and/or persistent Tor settings, this should be mostly trivial: removing the code we have that disables the default bridges/PTs condition (and encouraging to get their own bridges and use persistence in this context?).

    • Solves issues: I
  • Support Meek bridges

    Why we want to do it: it will make Tails work in some places that block other kinds of bridges.

    This requires first including configuration with default bridges/PTs and allowing Tails users to configure their own bridges/PTs in a persistent manner. Otherwise, if the only default bridges/PTs available by default are the Meek ones, users will (over)use them even in situations where other kinds of bridges would work just fine for them.

    • Cost: low (remove code we have that disables Meek default bridges)
  • Replace GNOME UI to connect to new networks with our own.

    Is this still useful given previous iterations dismiss the per-network settings approach? Or can we skip the "select a network" step of our mockups and jump to the "Tor configuration mode" once we've connected to a network?

    • Solves issues: A, F (not current mockups but doable)
    • Can probably be solved in other ways.
  • Option "I want to hide the fact that I'm using Tails and use Tor bridges on every network."

    • So we can jump to manual Tor configuration directly.
    • So we can avoid probing captive portals too early.

    • Solves issues: F

  • Display a locked-down browser to log into a captive portal when needed

    See blueprint on captive portal detection.

    And remove the Unsafe Browser.

    • Solves issues: C, D, E, L, N (some of then only if we require the user to tell this system once they have successfully logged in; some of them only if we can keep this window somehow open for captive portals that require a permanent connection to them)
    • Related to:
      • Wayland in Tails 5.0 (Bullseye) (#12213)
      • Problem M: audio should work in that locked-down browser
  • Persistent Tor state — #5462

    See blueprint on persistent Tor state.

    Related but orthogonal.

Dismissed ideas

  • Tails suggests disabling MAC spoofing if it fails

    • Solves issues: K
    • Note that "People who have to disable MAC spoofing all the time" is out of scope.
    • Cost: same as moving MAC spoofing to per-network (hard to get right)
  • Move "Disable networking" and MAC spoofing from per-session (Greeter) to per-network. Optional, can happen at the end or never, not needed by anything else. Probably the hardest to get right on the implementation side.

    • Solves issues: K
    • Makes harder: P

Process

Related work

At Tor

At Whonix