The only previous topic I could find by searching for "encryption" and "encryption at rest" is this thread: "at-rest" encryption on the local database where there's only 1 dismissive answer, tessus saying it was discussed "many times" but without saying where or what was the outcome of those discussions. I could not find any of those old discussions he references.
So let's have a new discussion.
The problem
Joplin locally stores your notes in a basic SQLite db (basically an Excel file for the unitiated). Even a non-technical user who has your joplin.db file can read all your notes with something like Sqlite Browser. Furthermore, images are stored as normal PNG files on your filesystem. This data can be found in /.config/joplin-desktop.
I'm requesting that Joplin encrypt this local data so that someone who gains access to the filesystem, cannot read all your notes.
Suggested approach
a. Use SQLCipher instead of SQLite. SQLCipher is API-compatible with SQLite, you'd just need to send an SQL query at the very beginning with the user's master key/password when opening the DB.
b. When storing images, use a blob table inside of the SQLite DB, instead of image files on the filesystem. This is a common use of SQLite and doesn't hurt performance.
Pre-emptive talking points
since I can't help but wonder what was discussed in those threads tessus alluded to:
Considering how seemingly easy the above seems to be, I'm thinking perhaps it wasn't done because of platform support. For example, some lowest common denominator mobile platform is preventing desktop users from having their local data encrypted. If this is the case, then I ask that desktop don't be penalized, use a separate SQLite library for them.
"Data isn't encrypted in process memory, therefore it's pointless to encrypt data at rest". Some people in IT love to reject great improvements because they're not perfect. I disagree with this mentality. Because encryption at rest still protects you from the more common threat of someone copying your files. It's much harder to target Joplin's memory structures while it's running to extract notes as the user accesses them: you need to write a background process, you need admin privileges to hook into the Joplin process's memory (on Windows at least), and you need the user to open Joplin and decrypt their notes while this is happening. Nah, there's a lot to gain from at-rest encryption.
This is a very contentious point on the Joplin forums, mostly because it comes up so often and there is rarely (if ever) and new arguments/information presented. I'd like to remind everyone in this thread to act in good faith and please try to refrain from making accusations.
With that said, there was a thread 10 days ago that provides a few counter points that you may be interested in. It may also serve to help you kickoff a new search direction, I promise you this topic has come up more than twice...
The stance of the Joplin project (from what I've seen), is that the security conscious individual, which should include everyone, would be better served by using full disc encryption or at least use an encrypted home directory. Full disc encryption is obviously the ideal as it encrypts all Joplin data and all other user data. If this isn't possible, using veracrypt is the next best thing.
To specifically comment on your suggestion to use SQLCipher and provide context, that would work well for the notes, but Joplin resources are stored as files in the resources directory, so any solution for Joplin will need to include these as well.
@CalebJohn
While I agree with most of the things you said, there is one caveat :
when you say "If this isn't possible, using veracrypt is the next best thing." ... this is, unfortunately, not possible because Joplin does not allow you to chose where the profile folder gets setup and stored.
In the Linux Snap build, the $HOME variable is modified before Joplin is triggered and points to a different folder. This effectively shifts where it stores it's .config files (and even trivialialises having multiple side by side profiles) without seemingly any of the downsides of the profile flag. I'd imagine that the portable windows Joplin works similarly. You'd probably be able modify windows equivalent variables the same way to be able to make use of Veracrypt.
Full disk encryption only helps in the case of a device stolen by a stranger. It doesn't help in other scenarios I want to be protected from, such as if someone with physical access knows your Windows password, or you installed an untrustworthy app that turned out to be spyware. (note: in both these examples, if they don't have admin rights, they can't install a keylogger, or use memory extraction, so that counter-point is not valid. Furthermore ANY vulnerability is much more difficult to exploit than simply copying joplin.db, so just because they are possible, doesn't mean they are likely, doesn't mean we don't deserve protection from copying joplin.db).
The people in those old threads arguing that what Joplin does is good enough and why would you want anything more if the OS does full disk encryption, are mixing up different privacy scenarios, then using the fact that Joplin works in one scenario, to dismiss the other scenario. I haven't written a detailed post differenciating the different scenarios and their strengths/weaknesses, because I thought this would just be a basic discussion thread. If that's what it takes for Laurent to be motivated to do this, I'm happy to do that write-up.
I view notes as an extension of my thoughts. More private than my account on the OS. I share my Windows password with my family if I'm not home and need info from my computer. That doesn't mean I want them to be able to access my private notes.
This condescending xkcd comic is often brought up by people who misunderstand why others want some basic privacy. I'm not worried about the government extracting my notes, this is not the objective here. I'm legally compelled to provide my password in my country if they ask anyway or I go to jail. That doesn't mean I don't want privacy from the FAR MORE LIKELY scenario of a non-government person or app copying joplin.db.
Btw for anyone wondering, I looked into it and Standard Notes indeed encrypts your local data, if you set a password. If on Android you only use fingerprint unlock, if you don't use an actual password, then your local data is not encrypted, only the remote sync is (similar to Joplin). But generally phones are a lot more private than a desktop account, and an app has no access to the data or memory of another app.
You absolutely do not need admin rights to be a keylogger, it might help on Windows, but you can poll the status of the keyboard input in a trivial amount of code. Similarly, on Linux the entire X11 protocol is inherently keyloggable.
I understand that perfect is the enemy of good enough, and that small wins are better than no wins, but those wins need to truthful. False sense of security is also bad to have. Having to make stipulations like people knowing your Windows password is arguing in bad faith here. If you know my Windows password I have already lost, you will be able to indiscriminately ruin my personal and professional life, it's a loss by default. Similarly, installing untrustworthy apps is also a loss by default, Joplin isn't an antivirus.
Not knowing the Windows password IS the defense against indiscriminately copying the database. The system has FDE powered by a TPM. The Windows password becomes the biggest single point of failure, and acting like it doesn't exist isn't fair.
Even with no keylogger, someone could easily swap the installed version of Joplin with a hacked one that would dump all the notes as plain text to some local directory, or even upload them somewhere. If you give full access to your computer to someone, they can do anything they want whether they have admin rights or not.
In fact, it makes no sense to trust someone in that way - instead you need to define what the account is for: either it's shared by everybody, or it's yours only. But it seems you want an account with dual purpose - for everybody and for yourself only. That doesn't make sense - instead you should create two accounts. The cost of creating a separate account is exactly $0 and it takes 1 minute. The cost of implementing useless encryption is much higher.
I don't think it's a false. I think it's a valid, improved sense of security. It doesn't get you to 100% perfection, but it gets acceptably high for me.
If what you say is true, then why do the desktop apps of password managers ask you for your master password before decrypting the at-rest-encrypted database, even on desktop? Why don't they give the same excuse you just gave, and say "Just don't ever install a malicious app, bro. Just don't share your desktop password with your brother, dummy".
In fact why do people use password managers in the first place? Can't people just put their stuff in mypasswords.txt? The OS protects them after all, right?
No. My journal is as private to me as my Facebook username/password is (actually, it's MORE private). I don't see why in tech circles everyone agrees on how important it is to secure the latter, but it's seen as unreasonable/silly/naive if I want to do the same for the former.
I'm not familiar with all the password managers but Keepass for instance existed before disk encryption was widely available, and back then I don't think you even needed a password to open a Windows session, so app-level encryption was very necessary.
Today browser password managers for example don't ask for a master password by default, which for me is acceptable because of the reasons mentioned above.
I don't think that's true. Even today by default a Linux desktop install (the most popular desktop distro, Ubuntu 20.04) does not encrypt by default. All modern password managers, for example Bitwarden which only came out 2 years ago, require a master password.
Browsers dumbing down everything for the lowest common denominator is not a positive model to follow. They have to work for tech-illiterate people who don't know basic password management. Someone using Joplin is on a higher level, if only because they know how to find it and install it on their own. Browsers have to target crayon eaters.
It's your app and you do what you want. But I think the encryption-at-rest policy of EVERY password manager under the sun shows you are misguided about this. If you accept that for some people, their journal is as private as passwords, then Joplin needs at-rest encryption like passwords managers have.
For me for example, this is a huge downside to Joplin when comparing it to other apps. Joplin is great, but I am forced to use an inferior alternative overall (in other aspects I care about), just so I won't have to worry about the secrecy of what I'm writing in it.
Veracrypt allows mounting to any local folder (at least on linux this is true). If you want to encrypt your Joplin directory with veracrypt, you'll need to temporarily move your Joplin notes out of ~/.config/joplin-desktop (close Joplin first). Then you can create your veracrypt drive and mount it to ~/.config/joplin-desktop. Move the files back and voila! The caveat here is that you'll need to decryot and mount the veracrypt drive before opening Joplin.
@jerkstorecaller I think these are important points to discuss. You clearly understand that security is a continuum, and you note that Joplin's security model is currently not acceptable for you. That is a completely fair point which no one can argue. However, the Joplin security model is sufficient for a lot of us, which is why you're seeing pushback. Whether you'd like to admit it or not, you're in a security situation that is not covered by Joplin, I'd like to argue that you're in a "unique" situation, but given that this topic comes up about twice a month I have to concede that it is fairly common.
With that said, there are 2 paths forward. 1, the Joplin developers extend the Joplin security model to support your situation. 2, you enhance your security situation. By this I mean you use a tool such as veracrypt to locally encrypt the joplin-desktop folder (see above).
Option 1 is nice because it means very little setup for you, you don't need to learn another tool (veracrypt) and all users of Joplin will be able to take advantage (should they choose).
Option 2 is nice because it allows you to get what you want immediately (well maybe about 30 minutes) and it relieves the Laurent from the burden of maintaining at rest encryption. The other benefit is that being comfortable with a tool like veracrypt will allow you to secure any other application you feel needs heightened security.
I think an important thing to keep in mind is that for a lot of people notes are simply not as private as passwords (which is evidenced by the number of people that still use Evernote and OneNote). For you they are and you'll need to make security choices based on that, but please don't try to tell me that the security model that fits your needs is "best".
TL;DR Security is a continuum and different people have different security needs. You need your notes to be more private than the typical user of Joplin, and that's okay. There are many local encryption options that are compatible with Joplin (veracrypt being my choice) and you should use one of them, or find a note taking application that adheres to your personal security model.
In my case, I've setup Bitlocker on Windows and FileVault on macOS and never looked back, and there are solutions for Linux too. That it's not enabled by default is not relevant, is it?
But personal opinions aside, what's preventing you from implementing the solutions that have been discussed in this forum? Separate user accounts for personal and shared sessions, and OS level encryption. You can advocate for app-level encryption if you want, but even if we get there one day, there are things you can easily do now to secure your data.
"what's preventing you from implementing the solutions that have been discussed in this forum? "
Same reason why you bother with a password manager even though you have Bitlocker.
Because FDE is not enough.
Your suggestions are valid and help cover certain exposure scenarios (stolen PC, neighbor wants to use my PC), they don't cover other scenarios that I care about (girlfriend snooped my personal password without my noticing, rogue app uploading appdata of known apps like Joplin to remote servers, etc).
The required security protections of an application will be related to the sensitivity of the data it is designed to store. Any app that stores data can be used to store senstive data. It's just a question of whether you should. At the extreme, someone could store their username / password combos in a free public Pastebin paste. Doesn't mean Pastebin is at fault for letting the world see it. It's just the wrong tool for the job.
FDE is remarkably effective. When the system is out of your direct control everything on the system is safe. When the system is in your control then you have to practice OpSec commensurate with the data you are protecting. If the data is very sensitive and someone can shoulder-surf your login password they can do the same for your Joplin password, so you look before you type. Also care would need to be taken when installing unknown / untested / untrusted apps.
I am not trying to put anyone down here. I can see why so many people raise this question of encryption. People who raise these issues are, ipso facto, aware of the importance of data security and that is a good thing. I certainly wouldn't complain if it was added. But I can also see why Laurent has "drawn a line".
For every app there will be a design limit after which you should ask yourself if you are using the right tool for the job. The difficulty is that a piece of data one person sees as not important can be seen by another as very important. We all have our own experiences and perspectives. So I suppose that the reason this crops up again and again is that no-one can ever be "right". The arguments to add local encryption are equally as valid as those for not.
Joplin and FDE works for me. My notes are basically a collection of notes on computer customisation or installation procedures. The security is more than fine for that. However my logins / passwords are stored in a password manager, my ssh keys in an encrypted volume and my GPG keys on Yubikeys.
Okay, I am missing sth here (and in the Joplin documentation). How do I use the --profile switch under os-x. Now, please do not say "in the Terminal application", because that doesn't work.
