I’m dealing with confidential information in my current project. I want to ensure Scrivener leaves no traces behind on my Mac after closing the Scrivener project; how do I do that? Are there any temporary files left on a macOS system when a project is closed? 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.
To be honest IMHO, given one can’t really control or be sure what the operating system or even Apps do with stuff (memory caches, files, other app’s, malware, etc.) if the project is so confidential to warrant these worries, why use a computer? Typewriter (and destroying ribbon after use)? Pen and paper? Yes, perhaps doing full disk encryption on your Mac may satisfy you about prying eyes, but …
Just a thought based on a little bit of experience …
2 Likes
So you think that if FileVault and Advanced Data Protection for iCloud are enabled, data left on macOS won’t compromise the security?
Frankly, I do not know. I do not know the skills or risk (impact and probability) of the “attacks” you can expect. Nor, do I know what bad things might happen if your security is breached. A determined person or entity may be able to get your data. Or may not. Can we really believe any “experts” on this? Really up to you to judge who and what to believe based on your risk tolerance.
If the content you are worried about is such that you can’t judge for yourself, then find other means, I would say.
@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.
5 Likes
No, the Scrivener project package and its internal .scrivx file are not secure. It is easy to read the contents of a project.
One solution for you is to store the file on an encrypted drive, USB drive, or disk image. The latter is very easy on macOS. Once created, to open that disk image, you double click its icon and type the password, then the folder opens in a Finder window. From there, double-click to open your Scrivener project and work as usual. When done, save your work, exit Scrivener, and close the disk image. It remains locked and encrypted until you reopen it and retype the password.
As detailed in other posts, you have to know where your backups are stored. You could set this to be the encrypted disk image also.
People store backups of their encrypted internal drives on unencrypted backup media? Is this really a thing? 
I’m referring to Scrivener’s auto backup feature.
It would be easy to forget to change the backup location, since it is a global setting in Scrivener.
Yeah, but that should be encrypted anyways (FileVault), otherwise it’s like locking all windows and leaving the door open. 
Personally, I wouldn’t allow confidential data anywhere near the internet if I could help it.
But it really depends on exactly what the data is, who might be interested in it, and what the consequences of a data leak might be.
Is a government entity with access to legal process targeting you personally? Are you someone who handles confidential medical or financial information that is legally privileged and requires you to protect it from accidental disclosure?
If the Mac is encrypted and airgapped then access to the data requires physical access to the Mac by an entity capable of breaking the encryption. That’s the gold standard, but it also makes the system fairly difficult to use for many purposes.
3 Likes
AmberV, your answer was very complete and helpful. Thank you. There is much more information in it than I would understand to ask myself, so I have no further questions on the subject. The FAQs and User Manual might also benefit from including this information, I think.
I also explored several other apps on my computer—from Microsoft and Apple to others I regularly use, such as Ulysses, Bear, and iA Writer. Apple and Microsoft use their cloud services to keep their apps in sync, and with Ulysses and Bear, everything you’ll ever write is stored in their unified libraries, and somewhat magically syncing via iCloud. Also, Markdown editors, even the simplest ones, appear also to have auto-versioning on Mac. Backing up my work is also a key factor, and I wouldn’t use something like locked notes in Apple Notes, even when FileVault and iCloud’s Advanced Data Protection are enabled. I’m still uncertain how my data is handled across iCloud.
I’m now making an encrypted DMG folder to hold both the Scrivener project and the backups. At least I know where Scrivener keeps its data, unlike some other applications. I’ll back up the dmg files locally.
To be clear, I am not engaged in any illegal activity, and just have access to some confidential data sources that, although its online disclosure could make some individuals very unhappy, do not pose any legal or political questions.
Thank you once again.
Thank you. I want to clarify that I am not involved in any illegal activity. I only have temporary access to some sources of commercial information that, if published online, might make some people very unhappy, but certainly do not raise legal or political concerns for the authorities.
Sure, but with a thread like this it is good to cover as many cases as possible.
With your case, you can use a computer normally, with a few low-overhead tweaks. 
I still wouldn’t have the data anywhere near cloud sync, though. For me, the easiest answer is to draw a line at the WiFi antenna or ethernet cable, and say, ‘none of this data crosses that line’, than to try and find something that works over the Internet that is as safe as not using it. On a Mac this means checking your sync settings and making sure the stuff is stored outside of any area it touches.
If you are concerned about how Scrivener uses the Documents folder as an unencrypted dumping ground for projects it cannot save to, then disable iCloud’s Documents & Desktop sync setting and use it more traditionally.
I’m now making an encrypted DMG folder to hold both the Scrivener project and the backups. At least I know where Scrivener keeps its data, unlike some other applications. I’ll back up the dmg files locally.
Sounds good. I agree that is the best approach for your needs, and it’s really not that difficult to work that way. Scrivener’s backups are more along the lines of a long-range undo system, not a substitute for a real backup. So if you’ve got real backups going on, it’s perfectly fine to have them and the source project in the same container. In the unlikely event something goes wrong with the container, you can restore the whole thing from yesterday.
The FAQs and User Manual might also benefit from including this information, I think.
Funnily enough, the old user manual did have a section on this, and I even looked it up to remind myself of details—which in turn reminded me I still need to put it in the new manual. Now that I have the above first draft, it’ll be easier.
Also, Markdown editors, even the simplest ones, appear also to have auto-versioning on Mac.
That’s almost always going to be something the OS and file system itself is doing, not the Markdown program. Modern Macs employ a technology called copy-on-write, which in basic terms means that saving (or auto-saving) doesn’t directly overwrite the original.
This isn’t a security concern, because having an old encrypted copy of your file stored in the physical media is what you were already doing. Having a new encrypted copy that is exposed in Finder doesn’t change that, or increase your risk. I.e. it’s about the same as using Save As within your encrypted DMG; the main difference is that the old copy is hidden from most tools and you only see the new one listed.
Versions, what you can access from the File menu in many Mac document editors, are a user-friendly hook into the side-effects of that process, granting you access to these older copies.
But overall these are good questions, and I would say in most cases what you’ve done is the best thing to do: ask about it directly, because different programs will do things differently, and some might have caches or search indexes stored separately from the location of the data you work with, that you’d want to know about.
2 Likes
And some very much do store data in the cloud without warning you. Or collect all kinds of user information.
2 Likes
I absolutely agree; contacting product support is best, especially given Scrivener’s superb helpful customer service. I appreciate your help and wish you a wonderful spring and summer!
1 Like