Documenting privacy and security concerns

[micahellison]

I think a lot of users pick jrnl for its privacy and security features, such as encryption and local storage. However, no solution is perfect for everyone situation, and we should address potential vulnerabilities in our documentation.

The encryption page in the documentation is a great starting point, but I think there are some things we could add. If you have any thoughts, feel free to add them to this thread or send a pull request.

Some things I think may be worth mentioning:

• Entries unencrypted in transit: Even with encrypted journals, the entries aren't encrypted in transit. So if you're using an editor and saving an entry but haven't closed it yet, and your computer shuts off, that entry is still sitting on your computer as a temp file somewhere. You can mitigate this by only saving with your editor right before closing, but it's still unencrypted in transit.
• Discoverability / lack of plausible deniability: While encryption may be enough to prevent an attacker with access to your files from opening your journal, they can still open your plaintext config file and identify where your journal is, and when you last edited it (based on the timestamp). With a sufficient power imbalance, knowledge of information can be enough for an attacker to acquire the information.

Any other thoughts or ideas?

[MinchinWeb]

Maybe it should be pointed out that jrnl has no "password recovery" feature: If you forget your password, there is no way for us to get back your password, change your password, or restore your entries.

It starts venturing into legal questions, but maybe it's worthwhile pointing out that encryption is not a protection against legal requirements: subpoenas, freedom of information requests, etc

I do appreciate that they is a manual decryption option listed. Is this tested though? Should it be added as a test to the test suite? Or included as a separate script with jrnl?