Tails

#1 Updated by sajolida 2019-02-21 12:43:34

• related to Bug #16011: Get ready for removing tails-installer from Debian added

#2 Updated by sajolida 2019-02-21 13:41:19

• Category set to Installation
• Assignee deleted (sajolida)
• Priority changed from Normal to Elevated
• QA Check deleted (Dev Needed)
• Feature Branch set to doc/16470-upgrade-from-debian
• Affected tool set to Installer

As a start, I tried to understand when were people trying this:

• For people on Windows, doing this before we distributed USB images would lead to the same consequence. Trying to upgrade using UUI instead of Etcher would also erase their persistence. emmapeel is only mentioning GNOME Disks in her report, so I’m guessing that Windows users are not affected.

• For people on non-Debian Linux, they were using GNOME Disks already so there’s no change for them.

• If you try to erase your Tails from itself, GNOME Disks prevents you from doing this because the disk is currently in use, even with an administration password.

• So, the people doing this are probably doing it from Debian. It’s also the only scenario that really changed in terms of upgrades.

Looking at the doc we have for these people:

• https://tails.boum.org/upgrade/tails/ makes it clear that all data on the intermediary Tails will be erased. At least, as clear as when installing.

• https://tails.boum.org/install/linux/usb/ has the same warning.

• https://tails.boum.org/install/expert/usb/ doesn’t have the warning. Interesting… I added one now with c8710fc011.

So, I think that people who suffered from this didn’t read the doc.

I think that this problem comes from the fact that people can’t upgrade from Debian anymore and have to do painful manual upgrades from inside Tails as everybody else. Debian users are loosing their privileges and it will create glitches for some time. If I’m right, then this problem will go away after some times (several months? a year?).

I was myself always doing manual upgrades from Debian partly because of that. Instead of having to choose between automatic upgrades (that are buggy and interrupt your workflow) or manual upgrades inside Tails (that are more tedious), I always downloaded the image in Debian and did a manual upgrade from Tails as it was the best option for me.

We could probably improve the deprecation screen of Tails Installer in Debian to be clearer about which tool to use:

Currently:

https://redmine.tails.boum.org/code/attachments/2190/Screenshot%20from%202018-12-01%2012-09-25.png

Proposal:

Tails Installer is deprecated in Debian

To install Tails from scratch, use GNOME Disks instead.
[See the installation instructions](https://tails.boum.org/install/linux/usb)

To upgrade Tails, do an automatic upgrade from Tails or a manual upgrade from Debian using a 2nd USB stick.
[See the manual upgrade instructions](https://tails.boum.org/upgrade/tails)

Note that in theory we could also advertise manual upgrades like this from Windows and macOS. During our design of the installation assistant, we didn’t want to advertise this because we thought that people who already have a Tails shouldn’t let other operating systems manipulate it once it’s been installed, for security.

If we’re fine with advertising this for Linux anyway, I wrote doc/16470-upgrade-from-debian to go with the redesign of the deprecation message. It was advertise in Debian already through Tails Installer until now and letting your Debian manipulate your Tails doesn’t sound as scary as letting Windows manipulate your Tails.

Ulrike: As the maintainer of the Tails Installer package and the designer of the current deprecation screen, what do you think of my analysis and possible solution?

Help desk: Please keep reporting occurrences of this problem on this ticket. Clarify which tool people used to erase their persistence and possibly, from which operating system (Tails, Debian, Windows), so we can confirm my analysis. Ideally, also ask them what made them believe that this was the way to upgrade, though they probably won’t answer really.

This is a UX regression and leads to serious data loss, so marking it as “Elevated”.

#4 Updated by Anonymous 2019-02-21 17:51:54

• Assignee set to sajolida

I fear that FT is not available, and some of us will be on a sprint. So I don’t know when this can be done. I can try to look into it tomorrow, but I’m not sure I’ll manage. The doc could be merged though I think?

#9 Updated by sajolida 2019-02-22 19:07:37

• Assignee changed from sajolida to intrigeri
• QA Check set to Dev Needed
• Type of work changed from User interface design to Debian

#11 Updated by intrigeri 2019-02-23 08:27:19

• Feature Branch deleted (doc/16470-upgrade-from-debian)

(doc/16470-upgrade-from-debian was merged yesterday)

#12 Updated by intrigeri 2019-02-23 08:29:50

• File Screenshot from 2019-02-23 09-23-56.png added
• Status changed from Confirmed to In Progress
• Assignee deleted (intrigeri)
• Target version set to Tails_3.13
• % Done changed from 0 to 50
• QA Check changed from Dev Needed to Ready for QA
• Feature Branch set to installer:bugfix/16470-improve-deprecation-dialog
• Type of work changed from Debian to Code

Implemented, see screenshot. Please review & test (or ask anonym to), and then I’ll prepare a new release that can be then uploaded to Debian.

#15 Updated by intrigeri 2019-02-23 11:10:53

• Assignee set to intrigeri

#18 Updated by intrigeri 2019-02-23 12:51:20

• % Done changed from 50 to 70
• QA Check deleted (Ready for QA)
• Type of work changed from Code to Debian

intrigeri wrote:
> Given the only change here is two user-facing strings and this needs to be uploaded to Debian soon to make any sense at all, I’ll skip the review, go ahead and prepare a release

Done.

> that can then be packaged and uploaded to Debian.

Done, pushed the packaging, uploaded to Debian but I’m not sure if that’ll work (I’ve uploaded my new OpenPGP subkey to the Debian keyservers 1.5 months ago but there’s been no release of debian-keyring since). I’ll come back to it later today and tomorrow; if my upload was dropped I’ll ask someone from pkg-privacy to sponsor it.

#19 Updated by intrigeri 2019-02-23 15:43:59

• Assignee deleted (intrigeri)
• % Done changed from 70 to 80

“tails-installer_5.0.14+dfsg-1_source.changes ACCEPTED into unstable” :)

I’ll let you handle the backport once this has migrated to testing.

#21 Updated by Anonymous 2019-03-06 11:46:39

• Assignee set to sajolida
• Feature Branch deleted (installer:bugfix/16470-improve-deprecation-dialog)
• Type of work changed from Debian to Contributors documentation

@sajolida: I think the remaining issues from https://redmine.tails.boum.org/code/issues/16470#note-17 need to be triaged on the technical writing side.

#22 Updated by sajolida 2019-03-06 16:51:00

• File next.png added

Answering to @intrigeri.

I’m really happy to see you doing the work of putting you in the shoes
of users and trying to imagine and follow their journeys :) So please dare!

> If a user click on “For USB sticks (USB image)”, under the mistaken impression that this will allow the to upgrade their Tails without deleting their persistent data, then
> they’re already in a pretty bad place.

Actually they would still be in the right place to do their upgrade!

See the screenshot in attachment:

• If you verify the USB image with the verification extension or do a
  BitTorrent download, then you end up with a list of options that point
  to both “install” and “upgrade” scenarios.

• If you don’t verify the USB image with the verification extension,
  then you’re left without links to neither installation or upgrade
  instructions.

This workflow hasn’t change at all since we are distributing USB images.
See the release notes for 3.11: https://tails.boum.org/news/version_3.11/.

If people trying to upgrade went to “Download only” and from there to
any installation instructions with 3.11, they would have wiped their
persistence just like with USB images in 3.12.

That’s why I discarded this option as a possible root cause when this
problem was reported as “something new caused by USB images”.

If we agree on this, then I think that most of your analysis is based on
a wrong assumption.

> IIRC we (kinda reluctantly) added these links because many people were like “OMG what did you do with the download link?!!! Give me the SHAAAA and a direct download link NOW!!!” (exaggerating slightly). Disclaimer: I don’t remember how we went from “add a direct download link on the download page” to “add a direct download link on the release notes” and could not find the corresponding ticket anymore. We did not want to spend too much time on these links so I would understand if we don’t want to invest much more time into them now. OTOH, if we’re keeping them, perhaps we could reduce the risks they cause data loss. Now, at this point, given both “To install” and “manual upgrade” point to pages that have a direct download link, I find it tempting to remove the direct download links from the release notes: they seem to be causing more harm than good. Or, remove the USB image link and keep the link to ISO for DVD/VM, which is less risky (less chances it causes the problem this ticket is about) and is about a clearly defined third use case.

I wouldn’t be against getting rid of the “Download only” links if it helped.

Right now, “manual upgrade” (/upgrade) has no direct download link.
We could add one (only below “Upgrade inside Tails”) that would merely
be a shortcut to skip the overview.

But again, I don’t see how it would help solving this issue which is new
to USB images, while we already had the same exact workflow with ISO images.

> Finally, perhaps replacing “To install” with “To install Tails from scratch” would avoid some folks getting lost on this path when they really want to upgrade their Tails.

What about putting the “Upgrade” option first in the list on the
download only pages?

> Install vs. upgrade terminology might not be well understood by everyone. Our doc seems to mostly assume users know the difference. E.g. I see friends coming to me asking “can you please install the latest version on my Tails?” and to figure out if they need a fresh installation or an upgrade, I need to either ask them “do you use a persistent volume?” or check the partition table myself. Also, not all operating systems use the same terminology, e.g. Lineage OS one installs an upgrade after downloading it…

Interesting… I’m worried about “from scratch” not solving your concern
entirely, being to colloquial or being hard to translate.
Maybe we should restructure this section of the release notes to include
the warning about losing persistence below “Install”.

#23 Updated by sajolida 2019-03-06 16:52:10

• Assignee changed from sajolida to intrigeri
• QA Check set to Info Needed

#24 Updated by intrigeri 2019-03-06 19:40:09

• Assignee changed from intrigeri to sajolida

> I’m really happy to see you doing the work of putting you in the shoes of users and trying to imagine and follow their journeys :) So please dare!

This is good to hear :)

>> If a user click on “For USB sticks (USB image)”, under the mistaken impression that this will allow the to upgrade their Tails without deleting their persistent data, then they’re already in a pretty bad place.

> Actually they would still be in the right place to do their upgrade!

> See the screenshot in attachment:

Ah! I didn’t go that far because the verification extension takes 10+ minutes to do its job here (yes, I should reproduce in a cleaner browser & report a bug).

> * If you verify the USB image with the verification extension or do a BitTorrent download, then you end up with a list of options that point to both “install” and “upgrade” scenarios.

Yep. In passing, this list of 4 bullet points has 2 kinds of “differenciators”: the OS one does $thing from (Windows, Linux, macOS, Tails) and the $thing one wants to do (install vs. upgrade). The only upgrade option is the last one. The first 3 bullet points are exactly the same except the last word on the line, so my eye is strongly attracted towards the right side of the list, which might make it easy to miss the install vs. upgrade difference… resulting in a decision made based on the OS and not on the operation one wants to do, which feels somewhat wrong given 3 options can lead to data loss while the last one does not. I suspect there could be a way to present information in a way that puts a bit more emphasis on the $thing one wants to do. [Edit: I see that you’re suggesting a cheap solution to this problem below.]

> This workflow hasn’t change at all since we are distributing USB images.
> See the release notes for 3.11: https://tails.boum.org/news/version_3.11/.

I agree in terms of workflow. But the visual presentation has changed: adding text (especially when attractively styled) changes how the surrounding text is perceived, even if the surrounding text itself has not changed. (Well, I’m not a UX person, I’m just making this up, but that’s what I would expect :)
And as argued previously, IMHO the visual presentation has changed in a way that can potentially encourage more people to click “For USB sticks (USB image)” than they would have clicked “Download Tails 3.11” previously. Unfortunately, as tempting as it would be, I won’t have time to test this with actual users this week.

> If people trying to upgrade went to “Download only” and from there to any installation instructions with 3.11, they would have wiped their persistence just like with USB images in 3.12.

ACK.

> That’s why I discarded this option as a possible root cause when this problem was reported as “something new caused by USB images”.

> If we agree on this, then I think that most of your analysis is based on a wrong assumption.

I’m not 100% convinced: if my hypothesis that “one now has more chances to land on the download page” is correct, then the way the install/upgrade options are presented on the download page becomes more important, and if my other hypothesis (the download only page might lead folks who want to upgrade to click “Install from $my_OS”) is correct as well, then the big picture is that there’s now more chances a user makes 2 mistaken decisions in a row, leading to data loss. In any case, you’re addressing my concerns below:

>> Finally, perhaps replacing “To install” with “To install Tails from scratch” would avoid some folks getting lost on this path when they really want to upgrade their Tails.

> What about putting the “Upgrade” option first in the list on the download only pages?

Sounds great to me, glad we’re on the same page (pun intended) since I was talking about this above before reading this suggestion of yours. I would hope it lowers the chances a user makes a second mistaken decision in a row. Go go go!

>> Install vs. upgrade terminology might not be well understood by everyone. Our doc seems to mostly assume users know the difference. E.g. I see friends coming to me asking “can you please install the latest version on my Tails?” and to figure out if they need a fresh installation or an upgrade, I need to either ask them “do you use a persistent volume?” or check the partition table myself. Also, not all operating systems use the same terminology, e.g. Lineage OS one installs an upgrade after downloading it…

> Interesting… I’m worried about “from scratch” not solving your concern entirely, being to colloquial or being hard to translate.

Indeed, I hadn’t thought of this. Scratch this!

> Maybe we should restructure this section of the release notes to include the warning about losing persistence below “Install”.

No strong opinion. I had other suggestions that you might want to re-read if you agree that the new visual presentation might cause trouble even if the workflow has not changed (and then change your mind somewhat wrt. “based on a wrong assumption”). But perhaps don’t bother for now, we can go ahead with moving the “Upgrade” option on the download only pages and see how it goes after the 3.13 release. Ideally help desk would give us numbers we can compare (although some affected users will have learned from their mistakes or given up on Tails, so even without changing anything I would expect the raw number of affected users to drop).

Cheers!

#25 Updated by sajolida 2019-03-08 07:50:15

• QA Check changed from Info Needed to Dev Needed

I’ll propose an improved layout for install vs upgrade on both the release notes and the download page in time for 3.13.

#26 Updated by sajolida 2019-03-19 12:41:41

• blocked by Feature #16398: Write release notes for 3.13 added

#27 Updated by sajolida 2019-03-19 12:42:30

• Assignee changed from sajolida to intrigeri
• QA Check changed from Dev Needed to Ready for QA
• Feature Branch set to web/16470-better-install-vs-upgrade

Here is a branch. I based it on the release notes for 3.13 (web/16398-3.13-release-notes) so it could be merged today together with the release notes or later on and will improve them.

#28 Updated by intrigeri 2019-03-19 12:53:13

• Assignee changed from intrigeri to sajolida
• QA Check changed from Ready for QA to Dev Needed

Looks great! Only a few comments:

• I guess some translations could be easily unfuzzied (e.g. commit:017a87d42f0c8c56d1d89b2239f78227e6eb07ec) once you’ll have updated the PO files.
• In “If you don’t need install or upgrade instructions”, s/install/installation/ perhaps?
• In install/inc/steps/download.inline.html, <ul class="download-only-img"> now contains no <li> element anymore. I’ve not built to look at how it renders but that doesn’t looks like valid HTML to me. Feel free to ignore if this has no practical drawback to speak of.

Feel free to merge yourself into web/16398-3.13-release-notes and delete this branch, once you’ve processed my feedback in whatever way you think is suitable :)

#29 Updated by sajolida 2019-03-19 18:13:50

• Assignee deleted (sajolida)
• QA Check deleted (Dev Needed)

> I guess some translations could be easily unfuzzied (e.g. 017a87d42f0c8c56d1d89b2239f78227e6eb07ec) once you’ll have updated the PO files.

I haven’t built the PO files because it’s taking ~20 minutes on my computer. I’ve spent the whole day on these release notes and their friends and today I’ll play my joker on rescuing translations.

> In “If you don’t need install or upgrade instructions”, s/install/installation/ perhaps?

Fixed in 5057a8c214.

> In install/inc/steps/download.inline.html,

now contains no

• element anymore. I’ve not built to look at how it renders but that doesn’t looks like valid HTML to me. Feel free to ignore if this has no practical drawback to speak of.

  Fixed in f60fe450e5.

  > Feel free to merge yourself into web/16398-3.13-release-notes and delete this branch, once you’ve processed my feedback in whatever way you think is suitable :)

  Done!

#30 Updated by sajolida 2019-03-19 18:14:40

• Status changed from In Progress to Fix committed

#31 Updated by sajolida 2019-03-19 18:16:17

• Status changed from Fix committed to In Progress

Applied in changeset commit:tails|7202661aadd7055c2d48e11efb105ea9164b2470.

#32 Updated by CyrilBrulebois 2019-03-19 18:48:48

• Status changed from In Progress to Fix committed
• % Done changed from 80 to 100

Applied in changeset commit:tails|33223686d84415ed4a8c0914cca25ef420c86dd2.

#33 Updated by sajolida 2019-03-19 19:06:08

• Type of work changed from Contributors documentation to End-user documentation

#34 Updated by CyrilBrulebois 2019-03-20 14:29:01

• Status changed from Fix committed to Resolved