[Feature] Persist settings when using Tails OS

[johndoe9459272]

Problem: When using Tails, the main settings of the bitbox app like tor-proxy, full-nodes, language and so on are not saved per default, as the bitbox dotfiles (/home/amnesia/.config/bitbox/**) are deleted on reboot. In case the user is fine with persisting those settings, I found that the file ~/.config/bitbox/config.json includes the most important settings.

Solution: By enabling the tails OS dotfiles feature, it's possible to persist files in the persistent volume, which are linked into the home folder on startup (using linux symbolic links). This way, I was able to keep the settings of ~/.config/bitbox/config.json after restart. Changes made in the bitbox app are also synced to the persisted file.

Question: As the dotfile feature allows you to persist specific files, not entire folders, is it safe to only persist the config.json file? Or is it bad, as this will not save all settings (more setting files like accounts.json available) and therefore might produce some bad state?

Futhermore: Do I need to reset my settings on updates, as the structure of the config.json might change?

Thank you!

[benma]

https://tails.net/doc/persistent_storage/configure/#index13h2

All the files in subfolders of /live/persistence/TailsData_unlocked/dotfiles are also linked in the corresponding subfolder of the Home folder using Linux symbolic links.

It sounds like it should also work with folders? Did you try?

As a workaround, you could symlink .config/bitbox to Persistent/bitbox and persist it this way? You'd need to repeat this after each reboot, but that could maybe be automated (e.g. a wrapper script to launch the BitBoxApp).

If none is feasible, we could consider adding a command line argument -datadir with which you could specify where the BitBoxApp stores its data, and point it to the Persistent folder.

I would avoid persisting individual files of the bitbox folder, as it's not guaranteed this will continue to work.

[johndoe9459272]

@benma thank you very much for your response

It sounds like it should also work with folders? Did you try?

Yes, I did try that. But you cannot link the folder itself. You need to copy all the files inside the folder. Now, let's assume a new file will be added sometime in the future, it will not be added from /home/amnesia/.config to /live/persistence/TailsData_unlocked/dotfiles automatically. You probably won't notice this issue at all. This is clarified in the same article: https://tails.net/doc/persistent_storage/configure/#index13h2, see the infobox with the following hint:

The Dotfiles feature only links specific files, and not entire folders, from the Persistent Storage. Accordingly, empty folders are ignored, as shown in the above example.

Your workaround may probably work, although the dotfiles feature of tails os is not needed, as this can be achieved with the persistent storage only.

The solution "command line argument -datadir" opts for the same idea.

In my opinion the cleanest way to handle this is still to specify -datadir, but due to the fact, that this will place awareness about other "save locations" into the code. That way we can assure, that custom save locations are taken into account in future app updates.

@benma What's your opinion? Also, is this complicated to implement?

[benma]

A -datadir flag should not be hard to implement 👍

[benma]

Here is a draft PR for -datadir: #3135

However, there is a problem: the app registers URI handlers (aopp: for now, but we might add bitcoin: later to automatically launch the BitBoxApp to make a transaction), which calls BitBox <uri> (see here), which would be missing the -dataDir argument. Not sure how to deal with that right now...

[benma]

@johndoe9459272 isn't the point of TailsOS to forget everything once it is shut down? Why not use your regular computer for the BitBoxApp anyway?

[benma]

A probably bad idea that could work for all cases is to specify a dotfile .bitboxapp-datadir (or -bitboxapp-flags) that contains the data-dir. I've never seen anything like it but would make launching the app use the desired directory no matter if it is launched directly or as part of an uri scheme 🤔

[johndoe9459272]

@johndoe9459272 isn't the point of TailsOS to forget everything once it is shut down? Why not use your regular computer for the BitBoxApp anyway?

Well that is correct, but to make it more comfortable to use, they introduced the persistent volume which is encrypted. All data stored onto the persistent volume will be available for the next boot - it's a tradeoff between comfort and security.

Instead of using a regular computer you can minimize your footprint and your attack surface as my regular computer is beeing used for all kind of stuff.

[johndoe9459272]

Here is a draft PR for -datadir: #3135

However, there is a problem: the app registers URI handlers (aopp: for now, but we might add bitcoin: later to automatically launch the BitBoxApp to make a transaction), which calls BitBox <uri> (see here), which would be missing the -dataDir argument. Not sure how to deal with that right now...

Wow, you were really quick for your first draft PR, I appreciate your effort 👍

A probably bad idea that could work for all cases is to specify a dotfile .bitboxapp-datadir (or -bitboxapp-flags) that contains the data-dir. I've never seen anything like it but would make launching the app use the desired directory no matter if it is launched directly or as part of an uri scheme 🤔

You mean like a dotfile, that just holds the location of the data-dir as "configuration". And the bitbox app then reads that on every launch?
It would be like a dotfile to configure where the "normal" dotfiles aka dataDir is stored.
Seems unusual but may work.

I will think about it, but I can't think of a solution right now.

In the end, maybe your solution:

As a workaround, you could symlink .config/bitbox to Persistent/bitbox and persist it this way? You'd need to repeat this after each reboot, but that could maybe be automated (e.g. a wrapper script to launch the BitBoxApp).

might be the best approach. When I find some time, I can create a script, that launches the bitbox appImage and creates that symlink. That way I will synchronize all your configuration changes onto the persistent volume and load that into the .config/bitbox after reboots.
In terms of time saving and the complete valid configuration state, this would be sufficient, but outside of the application itself. Do you think I will get problems that way in the future? How will I notice breaking changes or is the worst event possible the loss of the configuration after an update of the appImage? (i will notice it, when my settings are gone after an update)