|author||intrigeri <email@example.com>||2019-08-17 06:59:20 +0000|
|committer||intrigeri <firstname.lastname@example.org>||2019-08-17 06:59:20 +0000|
3 files changed, 231 insertions, 111 deletions
diff --git a/wiki/src/blueprint/backups.mdwn b/wiki/src/blueprint/backups.mdwn
index 64b4ae4..96cff5b 100644
@@ -78,10 +78,15 @@ start using my backup Tails right away.
### Better UX
-- To prevent people confusing their current Tails with their backup
- Tails, the backup Tails could be aware that it is a backup Tails and
- display some warning when first started. Otherwise, changes made on
- the backup Tails would be overwritten when the backup is updated.
+To prevent people from confusing their current Tails with their backup
+Tails, the backup Tails could be aware that it is a backup Tails and
+display some warning when first started. Otherwise, changes made on
+the backup Tails would be overwritten when the backup is updated.
+- This could be a flag stored in the backup Persistence and that
+ triggers a warning when opened in Tails Greeter.
@@ -94,7 +99,17 @@ is copied. If the backup USB stick already has Tails installed, both the
Tails system on it and the backup of my Persistence are updated.
Before the backup Persistence is being created, the user is prompted for
+a passphrase to create the LUKS volume of the backup Persistence.
+- It might be possible to reuse the same LUKS header to create the
+ backup Persistence without prompting for a passphrase.
+ At first glance, cryptsetup luksHeaderBackup/luksHeaderRestore should
+ work to create that backups LUKS volume; and then, to unlock it, one
+ could dump the master key from memory and pass it to cryptsetup open
@@ -108,6 +123,20 @@ a passphrase.
Updating also updates the system partition of the backup Tails.
+- We want to operate at the file system level to speed things up. We
+ need a tool that allows copying EVERYTHING from the file system (ACL,
+ extended attributes, etc.).
+ See [anarcat: rsync oneliner: a study of a complex
+ commandline](https://anarc.at/blog/2019-07-07-rsync-oneliner/) on how
+ to do that with rsync.
+- We have to make sure that applications that could be problematic if
+ backed up while running are shut down (eg. Thunderbird) while not
+ bothering the user for others (eg. NetworkManager).
### Better UX
The update experience could be improved, like Deja Dup does, by:
@@ -116,11 +145,6 @@ The update experience could be improved, like Deja Dup does, by:
- Starting the update automatically when the backup Tails is plugged in.
-### Open questions
-- Is it fine to copy the content of the current Persistence while it is
- being used?
@@ -143,15 +167,6 @@ Discussion
recovery experiences for each of S2, S3, and S4 would be completely
-### Open questions
-- How can we handle the preserve permissions and ownership when doing
- the backup without having users to set up an administration password
- to create or update their backup?
-- How much can we organize this code to be easier to possibly extend to
- scenarios S2, S3, and S4 in the future?
diff --git a/wiki/src/blueprint/detect_captive_portals.mdwn b/wiki/src/blueprint/detect_captive_portals.mdwn
index 9656fe3..93330a0 100644
@@ -16,6 +16,20 @@ The method used likely has to be active, but it should preferably hook
into some common, innocent looking network connection in order to
+ - Is it OK to be more fingerprintable by checking (without Tor) whether
+ a captive portal is sitting in the way?
+ - Related question: how much is Tails fingerprintable _as Tails_ by a network
+ attacker (ISP), as opposed to being fingerprintable as "someone using Tor Browser"?
+ - How shall we integrate the captive portal browser on the desktop in case we
+ need to get back to it (to log in again, to log out)?
+ - Lunar's proposal: as a detached windows
+ - other possibility: invisible browser by default, can be displayed again somehow
diff --git a/wiki/src/blueprint/network_connection.mdwn b/wiki/src/blueprint/network_connection.mdwn
index acce750..c218044 100644
@@ -8,15 +8,13 @@ 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 a Wi-Fi network.
- Cf. Eileen's feedback.
+ 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 them to connect.
+ 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.
- [[!tails_ticket 5785 desc="Detect captive portals"]]
+ ([[!tails_ticket 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).
@@ -25,14 +23,14 @@ Current issues in Tails
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. [[!tails_ticket 11535]]
+ to make Tor connect. ([[!tails_ticket 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.
- [[!tails_ticket 5461 desc="Persistence preset: Tor configuration"]]
+ ([[!tails_ticket 5461]])
* H. It's not clear how one is supposed to get bridges if they need some.
@@ -44,104 +42,61 @@ Current issues in Tails
* 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. [[!tails_ticket 15635 desc="The Unsafe Browser allows to retrieve the public IP address by a compromised amnesia user with no user interaction"]]
+* L. The Unsafe Browser allows to retrieve the public IP address by a compromised amnesia user with no user interaction. ([[!tails_ticket 15635]])
-* M. [[!tails_ticket 16795 desc="No audio in Unsafe Browser"]]
+* M. No audio in Unsafe Browser breaks accessible CAPTCHAs. ([[!tails_ticket 16795]])
-* N. People use the Unsafe Browser to browser the Internet
+* 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 one's Tails. [[!tails_ticket 10803]]
+ with the same Tails. ([[!tails_ticket 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.
- What's left from this configuration process on the desktop after Tor is
- - What do we do with the NetworkManager in GNOME Shell?
- - Do we allow changing or visualizing the current settings?
- - What's the best way of asking for bridges, keeping in mind
- situations where people might be at risk if they don't use them?
- - Lunar's proposal: Say you're at risk in the Greeter, then configure
- bridges in the session.
- - other possibility: Do everything in the session (offline mode and MAC
- spoofing could still be optional settings in the Greeter), if so how?
- - if we have persistent network configuration (for example bridges) per
- local network, then this might conflict (or duplicate) the fact of
- asking about bridges in the Greeter
- - bridges might be needed on a given local network but not on
- another, would it be possible to ask about that *after* selecting
- the local network?
- - Could we, technically speaking, do something more useful about the failure
- of MAC spoofing than disabling the interface? in the Greeter? in the session?
- - Should we ask for confirmation before disabling the interface?
- - How shall we integrate the captive portal browser on the desktop in case we
- need to get back to it (to log in again, to log out)?
- - Lunar's proposal: as a detached windows
- - other possibility: invisible browser by default, can be displayed again somehow
- - Do we want to tell people about entry guards? For example, feedback
- the entry guard to be selected before connecting? Random entry
- guards are bad for security but persistent entry guards can ease
- - Is it OK to be more fingerprintable by checking (without Tor) whether
- a captive portal is sitting in the way?
- - Is it OK actively try to connect directly (without bridges), then via
- regular bridges, then via obfuscated PTs, to discover
- whether bridges/PTs are needed? How do we keep supporting "I need to hide
- the fact I'm using Tor" if we do so?
- - Related question: how much is Tails fingerprintable _as Tails_ by a network
- attacker (ISP), as opposed to being fingerprintable as "someone using Tor Browser"?
- - How do we instruct Network Manager not to attempt DHCP on known networks?
- This particularly matters for the wired interface because this autoconnection
- would happen even without persistence, and even on network we've never connected to.
- That's relevant only once we've moved MAC spoofing from global to per-network.
+ 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.
- Idea: Add "Autoconnect" toggle in screens 2 and 13.
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
- they Wi-Fi AP.
+ their Wi-Fi AP.
- People who have to disable MAC spoofing all the time as this is pretty
uncommon, cf. [[!tails_ticket 16385#note-5]]. As long as they can do this manually
- for each new Wi-Fi network they connect to (compared to doing it manually
- every time they start Tails, currently), that will be good enough.
+ 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.
-- Original post-its by Lunar:
- - <https://labs.riseup.net/code/attachments/download/1250/2015.10.02.jpg>
- - <https://mailman.boum.org/pipermail/tails-dev/2015-October/009593.html>
-- Digital rewrite by Spencer:
- - <https://labs.riseup.net/code/attachments/download/1251/2015.12.04.png>
- - <https://mailman.boum.org/pipermail/tails-ux/2015-December/000812.html>
-- We had a session at the IFF to gather feedback on mockups. See [[!tails_ticket 11245]].
- - [flowchart behind the mockups](https://labs.riseup.net/code/attachments/download/1293/network-20160306.odg)
- - [mockups](https://tails.boum.org/contribute/how/promote/material/slides/IFF-20160306/)
- - [feedback from post-if notes](https://labs.riseup.net/code/attachments/download/1291/iff-feedback.ods)
@@ -151,7 +106,16 @@ Iterations
if we never successfully connected to tor during this session,
or if our last attempt to connect to tor during this session failed.
+ Don't restart Tor anymore when exiting the Unsafe Browser.
- 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
@@ -161,9 +125,16 @@ Iterations
tell Tor Launcher that last settings failed and it needs to
prompt for manual config again.
-2. Persistent Tor settings
+2. Persistent Tor settings — [[!tails_ticket 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 [[!tails_ticket 15573]])
+ - Cost: XXX
Shall they be global or per-network? Per-network is vastly harder
to implement and makes UX more complex. Per-network could be useful
@@ -176,36 +147,156 @@ Iterations
- 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.
+ that were persisted. How?
+3. Automatic bridges/PTs retrieval (Moat) — [[!tails_ticket 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 ([[!tails_ticket 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 — [[!tails_ticket 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 — [[!tails_ticket 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.
- - Replace GNOME UI to connect to new networks with our own.
- Is this still useful given iterations 1 and 2 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?
+ 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."
- - Option "I want to hide the fact that I'm using Tails and use Tor bridges on every network." in screen 1
- or in Tor Launcher.
- So we can jump to manual Tor configuration directly.
- So we can avoid probing captive portals too early.
- - Move "Disable networking" and MAC spoofing from global (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: F
+* Display a locked-down browser to log into a captive portal when needed
+ See blueprint on [[captive portal detection|detect_captive_portals]].
+ 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) ([[!tails_ticket 12213]])
+ - Problem M: audio should work in that locked-down browser
+* Persistent Tor state — [[!tails_ticket 5462]]
+ See blueprint on [[persistent Tor state|persistent_Tor_state]].
+ Related but orthogonal.
+ - 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
+- Original post-its by Lunar:
+ - <https://labs.riseup.net/code/attachments/download/1250/2015.10.02.jpg>
+ - <https://mailman.boum.org/pipermail/tails-dev/2015-October/009593.html>
+- Digital rewrite by Spencer:
+ - <https://labs.riseup.net/code/attachments/download/1251/2015.12.04.png>
+ - <https://mailman.boum.org/pipermail/tails-ux/2015-December/000812.html>
+- We had a session at the IFF to gather feedback on mockups. See [[!tails_ticket 11245]].
+ - [flowchart behind the mockups](https://labs.riseup.net/code/attachments/download/1293/network-20160306.odg)
+ - [mockups](https://tails.boum.org/contribute/how/promote/material/slides/IFF-20160306/)
+ - [feedback from post-if notes](https://labs.riseup.net/code/attachments/download/1291/iff-feedback.ods)
- - [[Captive portal detection|detect_captive_portals]]
- - Tor Launcher can now retrieve bridges automatically ("Moat") [[!tails_ticket 15331]]
+ - Tor Launcher can now retrieve bridges automatically ("Moat") but
+ this is not integrated in Tails yet: [[!tails_ticket 15331]]
- Tor Browser might soon discover (by trial & error) whether one needs bridges/PTs.
This breaks the "hide that I'm using Tor" use case but makes things easier
for everyone else. This should happen in their nightlies between 2020-09 and 2021-09.
+ How will we deal with that?
- [A Usability Evaluation of Tor Launcher](https://trac.torproject.org/projects/tor/wiki/doc/TorLauncherUX2016)
- [UX testing of circumvention features of Tor Browser](https://github.com/lindanlee/circumvention-ux-tor)