Cloud storage security: if that sounds like an oxymoron, keep reading. (Or don’t, this post might be pretty boring.) It’s a big problem, but I’ve come up with what I think is an excellent solution.
One of the basic problems with some cloud storage is that in order to return a file to the person who saved it, the server has to be able to read it. While it’s password-protected, that password is also sent to the server to verify file ownership, so that password is just protection from the outside world: nothing technically protects a lot of cloud storage from the inside.
But as of today, that’s changing in WriterDuet Pro with a new option: client-side encryption. Refresh the WriterDuet page twice to see it, via the wrench icon then Misc.
Client-side encryption means that your script content is not stored on WriterDuet servers in a manner that is readable by anyone unless they have an additional password which should never be sent to the servers. This additional password is needed only on you and your collaborators’ computers, encrypting/decrypting script content before/after it’s sent to/from WriterDuet servers.
Okay, this is a big deal, but I should add some qualifiers: no encryption is perfect, and I’m not a security expert. I’ve done a bunch of research and had a security analyst take a look at my code, but there is no guarantee about the encryption behavior (sorry).
- I could’ve missed a place where it should be encrypting (bad) and it’s possible there are places I missed that need to decrypt (not as bad, but you’d get a jumble somewhere). I’ve tested writing and outlining, examined the files that live on our servers, etc., but you can’t sue me if anything goes wrong! This is not guaranteed in any way. (Covering my a$$.)
- It doesn’t encrypt metadata about your script (e.g. title, number of lines, line types, names of authors, who made what changes, etc.) but it does encrypt script content, notes, chat messages, outline, names of characters, scene colors, emoticons, etc.
- Some functionality requires sending non-encrypted script data to WriterDuet servers. I tried to find any such places, and added a warning where you’d have to approve the sending. It’s not going to permanently store that data, but you should be aware. An important example is PDF generation, since that can’t be done in a browser, it has to send the non-encrypted script temporarily to our servers. Once the desktop program is fully released (coming soon!) that problem will be mitigated, since it creates PDFs offline.
- WriterDuet currently will not encrypt work done before you add the special password. The same is true for collaborators as well – they will be prompted to add the password once they’re online in the script and the password-required update comes through.
- The password should be easy for you to remember because it is *not* recoverable or resettable (that would defeat the purpose if it were), though you can optionally add a hint which is stored on our servers in case you want help remembering the password later.
- Because this is new, there’s a very unlikely (I hope) chance something could go wrong and your script will not be decryptable anymore, or a slightly more real chance you’ll forget the password and be SOL on getting your script back. You should use the local backup options to store non-encrypted files on your computer.
- Don’t share your script password in the message when you share with a collaborator. That message is sent by our servers, and thus would defeat the purpose of the password.
If you have any questions or feedback, I’d love to hear them. The encryption process is in its early stages, and I want to make sure everyone understands the process and limitations. It’s not guaranteed to keep scripts 100% secure, but that’s certainly what I’d like to do.
And if you happen to be a security analyst who wants to chat about my methodology, that’d be cool too. 😉