Re: [Tails-testers] USB installation instructions for Linux

Hi again,

Limnivorous via Tails-testers:
>> Limnivorous, can you please point out which distribution does not >
>> make GNOME Disks available to its users?

> Slackware (and its derivatives) for one. Though it is listed at the
> URL you gave, that is just a "repo" of buildscripts, in this case
> for an old version - YMMV.

OK! I must say I'm surprised: GNOME is a key component of the free
software ecosystem these days, I had no clue any more or less major
distro did not package at least its core apps. Good to know, today
I learned, thanks!

> I am sure there are other cases where its availability is marginal
> or absent.

In this light, yes, quite possibly. sajolida, what about doing this:
in the place where say (essentially) "install the gnome-disk-utility
package", add a note to say something like "if your version of Linux
lacks this package, go to the expert Linux installation doc" (i.e.
the command line one). I assume that a distro that does not package
GNOME is targeted primarily at technical users, so this would work for
most of the people affected by the problem raised by Limnivorous.
In any case, it won't work any worse than telling them to install
a package that does not exist.

>> Of course, upstream offers Linux binaries, but I'd rather not
>> suggest that to Linux users, for many reasons.

> [...]

> Why would it be worse for Linux than it is for MS and Mac for you to
> just host the binary?

Yeah, I was too lazy to spell out my thoughts on this topic initially,
but since you're asking, here are the first few reasons that spring to
mind:

- On Windows and macOs, we have no choice: there's no curated app
store similar to Linux distros package repositories, with many
checks in place such as software licenses, overall code sanity,
security updates and sometimes build reproducibility. So the user
is already operating in an environment in which installing
arbitrary binaries downloaded from random third party websites is
the cultural and technical norm. Asking them to install Etcher
won't make things significantly worse, be it in terms of system
security or wrt. users' security habits.

- On Linux it's a very different matter: most non-technical Linux
users I know simply *never* install anything from third-party
places. Doing so (even unsafely) is non-trivial technically, it's
actually increasingly hard (e.g. recent GNOME makes it harder to
start 3rd-party scripts and binaries; getting a .desktop file
installed in the right place is too hard for many people). And most
of the time it's not needed because the distro already packages
a tool that satisfies the user's need.

So in this context, advising Linux users to download and run
a third-party binary would be akin to teaching them that it's OK.
We're Tails so there's a good chance that for many users who trust
us wrt. computer safety matters, and our saying so will have quite
some weight. And then they'll do the same for other third-party
binaries, which will put at risk their operating system, their
data, and in turn the Tails system they're installing from there.
And anyway, how to actually start the downloaded third-party is not
easy and in many cases, it requires using the command line, so it's
not that much easier than dd.

Also, note that hosting the binary ourselves is a trade-off:

We do this mostly in order to ensure the user's experience matches
what our document says, i.e. we can ship installer software
upgrades in a coordinated way with doc upgrades, after having
tested ourselves that the new version still works. (Another
historical reason, back when we made this decision initially, was
that there was no way to download Universal USB Installer over
HTTPS, which was a clear no-no for us. But I think this does not
apply to Etcher.)

The drawback is that it sends a wrong message, i.e. basically "if
Tails hosts the binaries, then they must be good and safe to run".
Unfortunately, we are not in a position to make any such claim: we
did not audit the source code, and we did not build the binaries
nor verified that the binaries we host are indeed reproducibly
built from the source published by upstream (optimistically
assuming they care about reproducible builds).

For Windows and macOS users, for reasons explained above, I think
that sending this wrong message does not matter much.

But for Linux users, who are not used to installing software from
random web sites, I would be really worried if we hosted
third-party binaries, suggesting they are trustworthy. If we
decided to recommend Etcher upstream binaries to Linux users,
I would quite possibly recommend we do *not* host them ourselves.

> Users who know enough to be wary of that too can probably manage to
> use dd, and those who don't would be no worse off than Windows and
> Mac users.

Those who don't know enough to be wary are precisely the one I don't
want to give bad habits by teaching them dangerous practices from our
privileged position of somewhat trusted people.

So far, unless one has a DVD burner handy, for users of non-Debian
Linux distros, the only supported way to install Tails was to use dd
on the command line. So my proposal above brings back this UX to users
of distros that don't package GNOME Disks, compared to the regression
currently brought by our USB image doc. If we implement it, at least
we're not regressing. That's not ideal, of course. But I don't think
this is the next thing we should improve, given the target user base
of such distros and the number of people we're talking about (i.e.
a small subset of the already small Linux userbase) and the fact there
are other critical showstoppers in our first installation UX, e.g.
the lack of Secure Boot support, that affect _anyone_ with a somewhat
recent computer.

Another way to improve the initial installation of Tails from these
Linux distros, both from a UX and security perspective, would be to
package GNOME Disks, or request the distro maintainers to package
it :)

> All in all, it looks like there is no ideal solution. But Etcher
> seems to be a good, straightforward graphical tool for the job.

Maybe there's another tool that does it, and is packaged in most
distros? I mean, all we're looking for here is a GUI frontend over
dd/cat… but perhaps I'm asking too much.

Cheers!
--
intrigeri