Encryption by default?

[justyns]

Trilium already has the ability to encrypt notes, and I actually encrypt almost all of my notes other than backend/frontend scripts.

What is everyone's thoughts on switching to full e2ee by default? E.g. maybe by using https://sqlite.org/com/see.html or https://github.com/sqlcipher/sqlcipher

If we push the encryption to the sqlite extension, I could see potentially either removing the encryption logic in trilium as it is now, or even leaving it as a second layer to protect specific notes with a password, but still let the overall app unlock itself with a remembered password if desired.

One goal of this would be to make it safer to host trilium on a vm or other server you don't have total control over.

[eliandoran]

@justyns , I think it's not a bad idea.

Full end-to-end encryption at database level should not be that difficult to implement. And I think it would also not be very costly in terms of performance since it's done outside the JavaScript realm.

But how would we manage the key? Reuse the password field that is used for syncing, or something else?

On my side I run the Trilium Server on a trusted server with disk encryption, so I'm not particularly affected or benefiting from this use-case.

I use password protected notes only to hide sensitive notes, for example if I let someone browse through my notes and I wouldn't really want them snooping around in some more sensitive notes.

[justyns]

But how would we manage the key? Reuse the password field that is used for syncing, or something else?

That was my thought, re-use the existing password to derive another key used for encryption.

On my side I run the Trilium Server on a trusted server with disk encryption, so I'm not particularly affected or benefiting from this use-case.

I do as well, but I like having the extra layer of security too. For example, if a server gets compromised, or even if I'm using a local client that doesn't have FDE (admittedly less common these days)

[rom1dep]

Some considerations:

• The decision should ultimately rest on the user with stern warnings (encryption is not desired in all circumstances, may cause accidental irrecoverable loss, and can get in the way of some workflows and off-tool data processing)
• If Trilium is heading towards more collaborative features, this will probably become a complexity worm-hole

[zadam]

If Trilium is heading towards more collaborative features, this will probably become a complexity worm-hole

This is a good point.

The combination of sharing and encryption are possible with public/private cryptography, but it's a complexity hell and mistakes / bugs will often cost you data.

[justyns]

That does make a lot of sense, I agree it would complicate things related to collaborating and maybe wouldn't be worth it in most cases.

Maybe if full encryption is allowed, it could come with a warning that sharing/collaborative features would be disabled?

[deajan]

I am also against encryption, at this point as many others said, it can quickly become a big pile of complicated stuff.
Those who need at rest encryption can go for filesystem encryption via LUKS or the alike.
Perhaps this is one of the features than can make it after a v1.0 release.

[bonnepioche]

IHMO, in today's times where everyone trying to get their hands on your notes/personal info, I think end to end encryption is a must.

I am not interested in a multi user application. That is not Trilium's purpose anyway.

A true mobile app would be nice too ;)

[capi]

I would not do that automatically, the current distinction between unencrypted and protected notes is fine in my opinion.
My take:

• Doing crypto is always complicated and error prone and may give a sense of wrong security. Doing crypto right is hard.
• My main concern would be to accidentally lock me out of my notes. I intentionally do not encrypt notes, they reside on encrypted disks (LUKS) anyways. I am happy that worst case I could simply look into the sqlite file and extract information. If it's encrypted, I lose that ability and might lose irrecoverably easier than now.

[Br0kenSilos]

I am a bit torn on this one. From my perspective, encrypting the DB is "usually" not as important as protecting the access to it. For instance, I dont really encrypt my notes because I generally dont put anything in there super secret like passwords or PII. Typical end users tend not to consider security much and will put all kinds of things in there (including account passwords) and then protect the data with a very weak password.

For me its about protecting access to it in the first place. I use only very strong passwords. I run Trilium on a VM server, in a docker container on my internal network. Then I run the desktop installed on the three machines I frequent. But MOST of the time I am accessing via the webUI. Encrypted SSL based access on the lan side is routed via haproxy on my firewall. For external access, my instance is behind a reverse proxy (CloudFlare), and then direct access is further limited to a handful of IP addresses that I tend to frequent (work, family etc). Access to the webUI beyond that is handled by CloudFlare WAF. I do however, shut my instance down nightly via script and pull a copy of the DB into a compressed file which is heavily encrypted and sent off to a cloud storage (amongst other locations).

That being said, I do realize that most non-tech users will not have the knowledge, environment, nor the desire to go through all of that.

Thinking about this also makes me wonder how do most people run Trilium. (ie Server Only, Desktop only, mixed)