I know the backup question, which also applies to snapshot files,: in my personal version I create a Backup folder in the folder that contains the .scriv file so everithung is included in the tar generated before encyption.
Not knowing where the user puts their own backup, or snapshot, files, I didn’t includethem in the script, so to avoid errors like 'file not found ’ which could scare users not accustomed to the bash.
IR
Snapshot files should be in the .scriv file with the rest of the project.
Another alternative is to disable automatic backups, and depend on your own (presumably secure) alternatives.
Katherine
Having my own security process, ie very strong password and fingerprint plus encrypted drive, secure anti-virus and malware protection, I see no reason to spend precious time protecting against the remote possibility someone goes to the extreme of chopping off my fingers and checking which ones I used, all for the dubious benefit of seeing what fairly ordinary work I’m writing.
Shrug. Different users have different needs. I’m not terribly concerned about security either, but I’m not a Chinese dissident, a vocal critic of the Saudi government, a US government whistleblower…
Nor do I deal with confidential data about other people on a regular basis.
Katherine
That’s what I use a Very good VPN for 
And yes I do handle very sensitive data on a regular basis and my security is audited.
But as you say, each to their own needs.
This is the reason why i created the scripts: people not terribly concerned about security but concerned enough to prevent people, not minding to their own business, to try to access, and read, my projects.
Especially those who are unaccustomed to the use of bash, but would like a minimum of security for their project.
For my part I have my home folder encrypted and the projects are stored in a VeraCrypt container shared via Mega, so I can access it from wherever I need it.
Using Mac to write my projects, for all the other jobs I use Linux, I’m sure I always have openssl and VeraCrypt, available.
IR
Well let me resurface this at almost the start of 2021. (I am new to Scrivener and writing, but it is one of my life dreams to produce a written work and quench my desire for creative outlets, so forgive possibly some newbie opinions).
After installing Scrivener and creating few projects for my backlog of ideas, I discovered one topic which I was not comfortable having wide open accessible as other projects. This means more of accidental read, rather than malicious hacking and prodding. I immediately looked up for any “password protect” this project, and to my surprise did not find it, which lead me to this thread. I was fully expecting this feature to exists in 2020 for long established and successful (hopefully) product, assuming people might be writing sensitive project with the tool (journal, memoirs, erotic literature, polarising opinions or research, etc…).
I get it, it is not in place, yet the arguments of the developer seems to me moot. There are few levels this “user expectation”/“demand” could be satisfied.
At the end my point is that there is a need or expectation from your customers. This can be satisfied and your product can be better without having to going fully nuclear to the last detail approach.
Password to protect it from who? The Mac user login has a password, why isn’t that enough?
The ”no” from the developer is partly for technical reasons. A project is not a file, it’s a folder with possibly thousands of files in it.
Enceyption… you can let Mac OS encrypt the whole HD.
A Scrivener project is a folder, not an individual file. It is, by design, possible to inspect the entire contents of the folder using Finder (or Windows Explorer), without using Scrivener at all. For that reason, password protection of the file has to be implemented at the Finder/OS level: limiting access through Scrivener itself simply won’t work.
Abundant tools for securing data folders already exist. Possible approaches might include limiting physical and network access, using a secure user account, and/or storing the project on an encrypted volume.
Looking at it from the other side, the “simple” task of implementing Scrivener-level password protection would require changing the project format so that everything would fit in a single file, and then encrypting/decrypting that file from within Scrivener itself. That approach would severely impact performance, and might well make it impossible to include the diverse research materials that many users depend on. In other words, encrypted Scrivener would no longer be Scrivener in several important ways.
Katherine
If you are concerned about accidental reading by someone in your own household, you should give that person their own account so that they don’t need access to “your” stuff. (And so that you don’t need access to theirs: privacy works both ways.)
Katherine
On the contrary – the opinions and arguments of the developer are the only ones that matter, at the end of the day.
Katherine as already explained why they don’t want to —and not they aren’t able to— set this feature, why you guys insist on asking something that in anyway could be done directly by the user?
There is more than a handful of software that have the specific task of protecting files, folders and more.
Once Katherine agreed that it is a matter of principle and not of capability, I really don’t understand this insistence on asking for a feature that goes against the spirit of whoever created this wonderful software.
Just to help you, I will list just some of the tools you can use to protect a Scrivener ‘file’ (click on the world to se wiki related page):
These are tools that you can use on the three most common operating systems: Mac, Linux and Windows.
In particular with reference to the Mac environment, the disc utility app can generate native encrypted containers for the system, thus obviating the use of tool as in point 2.
It goes without saying, that it is up to each user to decide if and how to protect their data, if it is sensitive. If Literature and Latte has decided not to create a protection option, as a matter of principle, I agree with them, that data protection is up to the user, not to the application.
Clearly this is my point of view that can be shared or not.
IG
This would be one of my priorities, along with the ability to choose sync via iCloud instead of Dropbox
I’m closing this thread since our reasoning has already been given and elaborated upon, but this doesn’t seem to stop posts coming in asking about it all over again. 