With a Mac that is being shared I would have thought that the easiest thing would be for each user to have their own account on the computer – one administrator and one or more guest accounts (each person has their own password for using their account). I’ve never done it for sharing, but I’ve set up guest accounts to test things. Don’t remember all the details, but it was pretty easy.
That’s what I’d do too. It’s very easy System Preferences > Users and Groups, click the lock and enter your administrator password to unlock the system, then click the + button and proceed.
Mark
Yes, using separate accounts is the way to do it. You could also put your Scrivener projects (and their backups!) on an external disk and physically remove the disk from the computer when you aren’t using it.
Generally speaking, sharing a computer that has confidential data with untrusted people is a bad idea. You’ll want to think about exactly why you want to keep the data confidential, how curious the other people using the computer are likely to be, and what the consequences of a data breach would be.
Katherine
Yes, I thought about the different users, however know from experience of too many instances, someone forgets to log off and it’s open to everyone to have a play, plus if you make the mistake of having two users with elevated permissions it’s easy to grant oneself access to other’s folders.
Mind you, similar applies if you forget to unmount the volume in my example.
Not a great fan on relying on removeable media as primary storage as they are open to misplacing, and of course pays to password protect and remember to take with you every time.
Katherine’s final point is perhaps key. Nothing quite as effective as ‘It’s mine - go play with your own’
The solution is to only have one trusted user (you?) be the only administrator on the computer. Everyone else is locked into certain settings, such as having the screen lock after X minutes of inactivity so nobody can directly gain access to the previous user’s data unless they rush to take the empty seat.
I do like the idea of creating encrypted volumes (maybe even just one per project), which can then be synced with less risk of a data breach on a cloud service. This is something that Macs do pretty well, and I recommend anyone interested in encrypting their projects to look into that as a general-purpose way encrypting folders of any size.
As for the up-stream suggestion of encrypting the application; that won’t prevent someone from just copying the project (most documents live outside of the application that creates them) and then opening it on another computer. Nor will it even prevent someone from just viewing the contents of the project (which is just a folder with files in it, by the way) using a standard word processor, though it won’t be organized in an easily navigable way.
You guys are all overthinking this. I’m pretty sure recent version of macOS have FileVault enabled by default, which means that your home folder (and all files therein) is encrypted with your login password. The idea of encrypted individual files or folders on an already encrypted volume is a bit pointless. Just remember to close your laptop.
Contrary to what someone said, it is not possible for another user with admin privileges to access your home folder without your password. It’s encrypted.
Edit: FileVault 2 (released with Mavericks) changed the encryption behaviour from home folder to disk-level, so anyone with permission to unlock the disk can see your home folder, and admins can change the permissions to allow read/write access (which seems like a step backwards in security to me…).
That said, absolutely never upload anything of value to Dropbox. All files on Dropbox’s servers are encrypted with a single private key. Google the ramifications of this. (Personally I find the baked in use of Dropbox to tarnish the image of Scrivener.)
It is possible for a user with admin privileges to change another user’s password, though. Which doesn’t help casual snoops – you’ll know your password’s been changed, so you’ll know someone was snooping – but is a reason not to store confidential data on systems controlled by other people.
Katherine
Actually there is a way for an admin user to give themselves access to another user’s folder.
I’ll refrain from explaining.
And of course if someone has root level access…
Yeah I’d not kept up on the changes to FileVault. It used to encrypt a user’s home folder. Hmph.
In corporate environments, this meets two requirements:
- The IT department can help a user who forgets their password. They can also lock out a user more easily in the event that the password is compromised or the user is fired.
- The user can’t hide bad behavior from the company as easily.
“Step backward in security?” Not really. You shouldn’t be keeping your own confidential data on a system that you don’t personally control anyway. And if you do control the system, you shouldn’t be giving admin access to people you don’t trust.
Katherine
Please go away.
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