Flatpak apps

  1. Flatpak apps
  2. System-wide or per-user mode
  3. Routing all Flatpak apps' network traffic over Tor
    1. Proxy-related environment variables
  4. Repositories
  5. Persistent Storage
  6. Apps management user interface
    1. GNOME Software startup and update schedule
  7. Localization
  8. Related pages

System-wide or per-user mode

Flatpak can operate in system-wide or per-user mode.

We set it up for the user in per-user mode for these reasons:

  • In system-wide mode, many operations (install, add overrides, repository configuration) needs privileges (not necessarily setting an administration password).
  • We install the Tor Browser pseudo-Flatpak as a system Flatpak, and we prefer to not give the amnesia user too much latitude to mis-configure it.

Routing all Flatpak apps' network traffic over Tor

Tails transparently proxies all of amnesia's outgoing TCP Internet traffic through tor, so since Tails' Flatpak-integration is set up for per-user mode (described above) all Flatpak apps installed in the ways we support will be torified. Notably this means that the stream isolation is limited to IsolateDestAddr and IsolateDestPort for all Flatpak apps.

Proxy-related environment variables

Our research has shown that standard environment variables, such as HTTP_PROXY and SOCKS_SERVER, are not honored by most Flatpak apps. However, if we find Flatpak apps that support them and work better (e.g. improved stream isolation by setting SOCKS username/password) we might consider adding overrides on a per-app basis.

Repositories

We enable Flathub at build time by default, install the up-to-date GPGKey in the image, and keep its key up-to-date in Persistent Storage via on-activated-hooks.

Persistent Storage

Given the storage requirements, we only support managing Flatpak apps when the corresponding Persistent Storage feature is enabled.

That feature makes these directories persistent:

  • /.local/share/flatpak: repository data (configuration, keys, AppStream, icons...), runtime environments, the actual Flatpak apps, and overrides
  • ~/.var/app: user's application data (configuration, caches, etc.)
  • ~/.cache/gnome-software: icons and repository data cached by GNOME Software in its own format

Apps management user interface

We install GNOME Software with gnome-software-plugin-flatpak. We do not install gnome-software-plugin-deb: in Tails, GNOME Software is for Flatpak apps, while Debian packages are managed in other ways (APT on the command line, Synaptic as long as we ship it).

GNOME Software uses AppStream to get the list of apps available on Flathub: "AppStream is a metadata specification enabling software to provide rich, machine-readable information (screenshots, descriptions, versions) for app stores, including Flathub".

GNOME Software startup and update schedule

GNOME Software follows an update schedule by checking if certain conditions are met on its startup and every hour following that, and if met proceeds to fetch updates. The main condition is that it will only fetch updates if the last attempt for that was done another calendar day. It implements that by comparing the current time with a timestamp (org.gnome.software.check-timestamp GSetting) that was set last time it fetched updates (if not set it will also proceed). To benefit from this scheduling we make this timestamp (and GNOME Software's other settings) persistent as part of the Flatpak feature:

A wrapper for GNOME Software prevents it from starting if Tor isn't bootstrapped, informing users of this requirement. The reason for this is that GNOME Software updates the timestamp mentioned above even if started before Tor has bootstrapped so fetching upgrades will fail, and as a result all update checks fail for the rest of the day, so updates would only be fetched if the session extend far into the next day when the update check can succeed again. GNOME Software has a network availability check that will prevent the timestamp from being updated if there's no network, which prevents this issue in most normal cases, but not ours.

The service that starts GNOME Software is scheduled to start after Tor has bootstrapped:

XDG autostart is disabled, and DBusActivatable is dropped from the Desktop file to ensure that it executes the wrapper:

Localization

Flatpak Apps are localized in three different ways (or not at all):

  1. All available localization is part of the base Flatpak app (e.g. org.signal.Signal)
  2. Localization is handled in a non-standard way, e.g. downloaded on application start (e.g. org.telegram.desktop)
  3. The localization bits are split into a .Locale Flatpak extension that contains all locales, but is only partially installed; only the locale matching the system locale (or whatever was manually configured with flatpak config --set languages) is installed.

Tails doesn't do anything special here, so there is really nothing to say about 1 and 2. For 3 the only relevant thing to mention is about switching locales:

When a Flatpak app is initially installed its .Locale extension (if it exists) is also installed, but only pulling the part of it that is for the current system locale (as selected by the user at the Welcome Screen). If a user restart Tails in a different locale the new parts of the .Locale extension are pulled the next time Flatpak upgrades are installed, which is according to GNOME Software's update schedule, mentioned above. So new locales will not necessarily be pulled in immediately after switching, it might take a few days.

Related pages

See also: