You do realize you’re being rude to one of the L&L staff, right? This is a public forum, not your private playground, and it’s part of her job to read and participate in the forums. If she’s taking the time to respond to your comments and explain things, that’s good.
Sorry to wade in on this, it is clear the thread has been running for a while… but I’m confused.
There are arguments put forward against encryption from a “how the product is engineered” perspective, which seems flawed to me? The user base is expressing a requirement, not asking for reasons why the current implementation can’t meet that requirement?
Furthermore, whilst it is meaningful to be able to encrypt whole file systems, user partitions etc. it is also meaningful for someone to want to protect a given file - for example, maybe it is being shared and there is a risk that it could be intercepted in-transit.
I’ve had a peep inside the package (macOS) and in my mind, I would have thought that a relatively simple encryption approach whereby an encryption key is held, per project (so package) which is unlocked by a password when the project is opened, the key could be anything at all really (although there are obviously some well established options) and the key is then used to encrypt/decrypt files as they are saved/read - symmetric encryption is hardly putting the moon on a stick in the modern era!?
The overhead of real time encryption/decryption is unlikely to be noticeable to most users and the implementation would be pretty straightforward (although some healthy QA would be needed - maybe that’s the real reason for the lack of desire, the prospect that even a small bug could render an entire project, or at least parts of it, unreadable)…
Anyway, just my two pennies, and I was mainly riled by the remarks about how the application currently works which lead me to register and waffle on for a bit…
Robert.
No, they are expressing a wish, not a “requirement”, and the developer has answered.
“I wish you would do this”
“No, sorry, I won’t.”
That’s it!
This is not a negotiation between two parties trying to reach an agreement, it’s a wish-list. Some things that users wish for are implemented, because the developer xdecides that he wants to do it. Others aren’t.
Explaining why a wish won’t be implemented is a courtesy to us users, a nice gesture.
wow! it’s friendly round here?! First post and I get my head torn off… 
My use of the term requirement was in relation to what the wish actually needs to do - as in a software requirement (I require it to protect my data from prying eyes) not a requirement that the developer does something… My issue is that telling the community how the app works, as an argument for not doing something, is bobbins and a rubbish way of engaging the community…
I really don’t see a “head getting torn off” here. Only a dry series of statements lacking 
or 
to imply tone. I’m not going to tell you how to feel about those statements, but if you’re seeing an attack in those words, I don’t understand how you’re arriving at that conclusion.
And maybe it is worth remembering that many people who frequent these forums are not native speakers of English. Tone is not an easy thing to convey, or perceive, in a language that is not your own. I know because I lived in another country for ten years and taught English there. And I must say that I have haunted these forums for about twelve years and have usually found the people here to be among the most generous and helpful I have found anywhere.
And if the user request can only be met by completely re-engineering the product?
Literature & Latte’s position has always been that users are welcome to choose whatever product best meets their needs. We understand that Scrivener will not always be that product, and that’s okay.
Your discussion of per-project encryption misses a critical aspect of Scrivener’s design: the project format is open for a reason. We want users to be able to recover their data without using Scrivener. “We will not hold your data hostage” is one of the most important promises that we make. So we have no interest in any encryption solution that forces us to break that promise. In practice, that means that the encryption/decryption tool cannot be part of Scrivener.
If you want to protect a project in transit, abundant third-party tools are available.
Katherine
For those interested, waiting for Scrivener to find time and resources to create a method to apply a password to the project, I have created two scripts that generate and edit a full project directory encrypt all via openssl.
First of all you need to initialize the encryption project:
- Create a directory where you project will stay;
- move to that directory;
- run Scrivener and create an empty project then save it with the same name of the directory and then close Scrivener;
- run che CreateProject script.
Here the code of the CreateProject script;
#!/bin/bash
CurDir="$(pwd)"
ProjName=$(basename "`pwd`")
cd /tmp
echo 'Creating file for ' $ProjName '...'
read -p "Press [Enter] to continue or [CRTL-C] to interrupt process..."
mkdir "$ProjName"
mv "$CurDir"/"$ProjName".scriv "$ProjName"/
tar cf "$ProjName.tar" "$ProjName"
openssl des3 -salt -in "$ProjName".tar -out "$CurDir"/"$ProjName".tar.encrypt
echo -e "\n\nSecure erasing all clear text files and directories...."
bcwipe -md -fI "$ProjName".tar &&
bcwipe -md -rfI "$ProjName"/
#echo -e "\n\nAll clear text files and directories safely destroied...!!\n"
cd "$CurDir"
echo -e "\n\nEncrypted project "$ProjName" generated and ready to be used via EditProject."
Once created the encrypted project, every time you need to work on it do these operations:
- Move to the direcotory containing your encrypted project;
- Run the EditProject script… it will decrypt, untar, and open the project and standby waiting an [Enter] to be pressed in the terminal window;
- Move to the opened project and do your whatever you have to do in the project;
- Once finished close Scrivener (it is the surest way to be sure that the modified project has been saved before re-encrypting;
- Go back to the terminal windows and press [Enter]
and that’s it!
Here the code of the EditProject script;
#!/bin/bash
CurDir=$(pwd)
ProjName=$(basename "`pwd`")
cd /tmp
openssl des3 -d -salt -in "$CurDir"/"$ProjName".tar.encrypt -out "$ProjName".tar &&
tar pxf "$ProjName".tar &&
open /tmp/"$ProjName"/"$ProjName".scriv
read -p "Press [Enter] to continue after your editing job..."
tar cf "$ProjName".tar "$ProjName"/ &&
openssl des3 -salt -in "$ProjName".tar -out "$CurDir"/"$ProjName".tar.encrypt &&
echo -e "\n\nSecure erasing all clear text files and directories...."
bcwipe -md -fI "$ProjName".tar &&
bcwipe -md -rfI "$ProjName"/
echo -e "\n\nAll clear text files and directories securelly destroied !!\n"The script EditProject must be run from the directory where the encrypt project is saved. All operations as, decrypting, untaring, running Scriver, saving and closing the project and rencrypting will be done in /tmp. The final encrypted file, result of your editind process, will be stored again in the directory from where it was initially read,
Notes:
- For secure erasing I use bcwipe if you prefere simply deleting the files in the normal way change the lines
bcwipe -md -fI "$ProjName".tar &&
bcwipe -md -rfI "$ProjName"/ with
rm "$ProjName".tar &&
rm -r "$ProjName"/ -
copy and past the scripts, once per file, and set them executable via chmod u+x ScriptName. The script can be in any executable directory reachable from the user.
-
You can also put a copy of the EditProject scritp into the folder containing the encrypted file.
-
if you want to run the EdiProject script via Finder remeber tha you must add .command suffix to the script name or Finder will not execute it. So the script name will be EditProject.command
Obviously, these two scripts can be used to protect anything: it is enough that what you want to open, can be opened via the open command via terminal.
Good writing!!
Note that Scrivener may “leak” unencrypted data, notably via the automatic backup function. You may want to either disable automatic backups – in which case protecting your data is entirely your responsibility – or ensure that the backup location is also encrypted.
Katherine
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.
- Give simple password protect option. Yes, people can go around and open up the file to get the content, but this removes the basic need some of the customers share in here. (add disclaimer that it is not true encryption, but is a protective UI/UX step). Aka mentioned Ulysses way.
- Consider encryption of the files. To be possibly unencrypted on opening and encrypted only on “encrypt and close” basis. As noted, more research might be needed to this.
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.