backup folder not always desirable

[brainchild0]

I read many recent issues related to saving files, autosaving, and backups.

I am slightly confused about the current status and the eventual goals, but the latest release, v 2.4.1, has a backup folder entry in the Help menu, and I definitely see files in the folder.

For cases in which a user opens a local file, and has not designated it for syncing or sharing, I think it is likely to be undesirable to keep backups anywhere but the directory of the original file.

If nothing else, could this behavior become configurable, for users who might have concerns about security?

[AdrianoFerrari]

Thanks for taking the time to read through existing issues, and to explain your reasoning for wanting backups paths to become configurable.

I've been uploading a large number of changes, including having rewritten much of the file-saving logic (though basic structure and file format are the same). I'm just waiting on fixing a Windows bug on application launch, and then will release 2.4.2. You can see the list of changes here:
https://github.com/gingko/client/blob/master/CHANGELOG.md#unreleased

It's true, for those that are more worried about privacy/security, having to keep those backups in mind is an annoyance. I have to weigh that, though, against the more common (I believe) fear of data loss and corruption.

Here's how backups work as of upcoming 2.4.2 release:

• A backup is made on opening the file, and on every save
• Backups are culled to the last 8 per file, 3 minutes into launch, and every 30 minutes thereafter
• Backup folder is still accessible from Help menu as before

Perhaps keeping last 8 backups is excessive. And I could also delete backups older than, say, 30 days. But neither of these address your core issue : if your computer gets hacked or stolen, those files are still sitting there 😕 .

Are you hoping to, for instance, configure backups to save to an encrypted location?
If so, what I could do, is add a backup-path option to the config file (config.json, one level up from backups folder), and read from that. It'll take some time to surface in the UI though (as we don't currently have a UI for any preferences besides fonts).

Would that help?

[brainchild0]

A basic use case in which security is at issue would be mounting a removable volume, or encrypted, internal volume, whose contents need to be obscured either from general users of the system, or from potential thieves or intruders.

We can outline the simple case through the following sequence of user actions:

1. Mount the volume.
2. Open a file from the volume in the application session.
3. Change the file contents in the application session.
4. Save the file (meaning explicitly by the user, not automatically by the application).
5. Close the file.
6. Unmount the volume.

In this case, are copies of all or part of the file stored outside the volume that is now unmounted?

Suppose instead that after step (3), the system crashes. The user never returns to the application session, but is shortly after the target of snooping.

Again, the same question arises: Are copies stored outside the volume?

If the answer in either case is "yes" or "maybe", then I would suggest that the information available is sufficient to conclude that the application has a vulnerability that some users may find unacceptable, in some cases without even realizing that the vulnerability exists.

There are a wide variety of possible solutions, but the obvious one to me is to write the backup copies in the same directory as the source file. Such practice has common precedent. Did you specifically decide against this approach for some reasons?

One observation I make is that we are invoking the term "backup", but it appears that what you might be describing is snapshots or versioning. Perhaps this discrepancy is leading to some misunderstanding. But in either case, the files, whatever their count or purpose, can still be written to the same location as the working document.

In fact, use of the same location may be much preferred in cases even where security is not an issue. Suppose the document is stored on a removable volume that is being mounted on various machines in succession, each one with a separate application installation. The backups being on the removable volume, not the system volume, might be advantageous to the user by a large measure.

---

Edit: And yet another case with a related set of concerns is of the parent folder of a file, between application sessions, being relocated. If the backup is tied to some absolute path of the file, then it will not be recognized correctly even for the same file.

I am curious to know whether the pattern you are using is practiced elsewhere. If so, knowing how these concerns are addressed in general would be helpful. If not, perhaps the reason is that no one has found a way to make it work well.

[brainchild0]

Are you hoping to, for instance, configure backups to save to an encrypted location?

In case the above was too detailed or too distracting, the simple answer to your question is no, I wasn't hoping to be able to configure a specific encrypted location or backups, but I was hoping that backups might simply be saved to the document location.

[AdrianoFerrari]

Thanks for the input and clarifications.

I'm marking this as "open for discussion", because I'd like to hear what other people have to say about this, to gauge it's importance relative all the other tasks that are possible.

[brainchild0]

One observation is that greater security for users is possible with minimal design changes. A preference toggle simply to disable backups would achieve this effect, even if it is not an optimal long-term solution.