@AnotherGuy: I’ve set a custom backup folder for this project, turned off auto-save, and disabled taking snapshots of changed documents. Any other settings I should consider? Thank you in advance.
Some of these things are unnecessary. The custom backup folder is the most important one to get set right, either to turn it off or to redirect the backups to an encrypted volume or location.
But auto-save shouldn’t be “turned off” (I presume you mean setting the idle timer so high it will never function naturally) unless you have some other reason to do so. There is no difference between an auto-save and closing the project and having it save. Some people use these words in an unorthodox fashion though, so to make sure we’re on the same page:
- Backup: a separate copy of the work in a different location, that is typically inaccessible or difficult to load in the software.
- Auto-save: the act of writing data over the file that is currently open, on the disk, at a periodic interval, without the user having to manually use the Save command themselves.
So the latter could have no possible security implications. You’ve got to save, and presumably you are saving to a secure location. So saving more often, without you having to remember to, isn’t going to compromise anything—and will keep your work safer from your own mistakes.
The other unnecessary setting is turning off Snapshots. Snapshots are saved into the project itself and nowhere else, and thus share its security level. Turning them off only increases your own operational risks.
Scrivener file system use
As a disclaimer, Scrivener was never coded to be ultra-secure. We can make it semi-secure with some adjustments, described below, but we make no promises that no data leaks outside of the secured areas of the drive may never happen. There are some things we have limited control over, such as system logs and preferences files that could save some information considered sensitive (like project file names).
Here are the main things and settings to be aware of when using Scrivener for confidential work:
Settings
-
General: Scratch Pad: either don’t use it for this, or make sure the folder setting here is changed to save scratch pad files in a secured location. Note you will need to move the scratch pad files yourself, from the old location to the new, in your file manager.
-
Backups: for work where all projects are treated as confidential, you will want to make sure the general automatic backup folder is set to a secure location, instead of the default in your Library folder.
For cases where only some projects need to be treated with care, the
Project ▸ Project Settings...window should be opened, and the project either set to no longer backup, or to use its own backup folder. -
Project location: it should go without saying, but only use locations that are encrypted, and ideally that can be disconnected with the project is not in use. On macOS there are encrypted DMGs you can make with Disk Utility. On Windows and Linux there are third-party tools that do similar. The other alternative is an encrypted external drive, which will be easier in many cases.
- The save location should not be under the domain of any cloud sync or online backup tools, unless those tools are certified to a safety level that matches what you need. The safest approach will always be to not use the Internet at all, of course. But there are some services that are better than others at this. You should always check with IT or your regs to see what is allowed.
- If you need to use the mobile version of Scrivener, consider using local WiFi or USB cable to manage the device’s storage directly, rather than cloud services or its built-in sync.
-
External folder sync (
File ▸ Sync ▸ with External Folder): if the project is set up to export quantities of data from the project into text files, that location should be secure as well.
Events
-
Compiling: some file formats require the assembly of files, before secondary conversion commands can be run. For example, creating an ePub involves building the entire folder and file structure of the ebook, before zipping it up into a single file. Such processes will use the system temporary file infrastructure, on both platforms, which will mean sensitive data could be written to unsafe areas for short intervals of time (but potentially up until the next reboot).
If that’s a problem, full-disk encryption is strongly advised. But there are workarounds as well, such as using the source file export option for ePub, which will write everything used to create the .epub (along with the .epub itself) to a designation location instead of a temp folder. Markdown workflows can be done by hand instead of using Scrivener’s automation.
-
Data recovery: in unusual cases where a project goes missing, or suddenly becomes unwritable, Scrivener will force a shutdown and write whatever data it has in memory, that hasn’t been saved yet, into a newly created subfolder of your user folder’s “Documents” folder. These will typically be .rtf or .txt files.
There is no way to avoid this behaviour, so it’s more one of those things to be aware of, and take steps to secure the data once it happens. Move the files it creates to your encrypted storage area, then fully delete the originals. It will warn you before it does this, so you can be prepared.
Some general notes:
- Of note, if you use a mounted file system or encrypted vault to host the project, the chances of losing connection with it are greater.
- Again, full disk encryption seems wise to me (in all cases, really), as it will provide a basic level of protection and make it so you don’t have to worry as much about temp files and recovery output.
- Care must be taken if you have a cloud service that syncs the entirety of your Documents folder. Mac users in particular will want to check their iCloud Drive settings, to see if the Documents and Desktop folders are automatically synced.
System
-
Encryption: Enabling the system’s full-disk encryption would be a good idea, as it will protect areas like the system temp folder, documents, scratch pad, and so on. It’s a pretty good system, but it does have its flaws. The main two are:
- Access password strength: if there are user accounts with weak passwords the whole thing is compromised. Only use strong passwords, and do not use features that automatically log you in on boot. If you have no control over that, on a multi-user system, it is far better to use your own encrypted volumes.
- The system is only fully protected when it is shut down (sleep doesn’t count).
-
Logging: As noted above, there are some system functions we can’t control that will store project file names. The software’s preferences, for example, list numerous project-specific settings and window states (the size, placement). Crash or diagnostic logs may also reveal these names. Using unrevealing project names will be the best approach, and that works fine with Scrivener as the actual title of the work will be in the compile settings anyway.
-
Searches: If you use an external drive or mounted volume of some sort, make sure that the system’s global search indexing system (Spotlight or Cortana) is set to exclude these volumes. If you made a mistake and already indexed the confidential work, you will need to look up how to reset the index and rebuild it (which will take several hours). I don’t know about Cortana, but Spotlight is not secure at all on a multi-user system.
I think that’s it. If I think of anything else I’ll update the post and make mention of doing so.