[RESOLVED] Joplin leaks private info despite end-to-end-encryption enabled

Features
1

EDIT: I can confirm that this is in fact not true, I may have experienced a transitory effect (or a bug) after enabling encryption in conjunction with Dropbox, maybe Dropbox caused/related. After all sync finished, all fields except updated_time and type have empty data. An example full .MD is:

id: 11e1201eb3224320939ec58fb715e5b4
parent_id: 
item_type: 
item_id: 
item_updated_time: 
title_diff: 
body_diff: 
metadata_diff: 
encryption_cipher_text: JED0100002205f1f60d8da27242aa808135a3ecaeaf39002858{"iv":"0k2jGukC53PhvHG/+PjKCA==","v":1,"iter":101,"ks":128,"ts":64,"mode":"ccm","adata":"","cipher":"aes","salt":"VUibmEIycrc=","ct":"...LONG_ENCRYPTED_STRING..."}002800{"iv":"maw5HoszAuoiT0gSwiS/BA==","v":1,"iter":101,"ks":128,"ts":64,"mode":"ccm","adata":"","cipher":"aes","salt":"VUibmEIycrc=","ct":"...LONG_ENCRYPTED_STRING..."}0003a4{"iv":"kQizOiVsNYxxePocxuyaiQ==","v":1,"iter":101,"ks":128,"ts":64,"mode":"ccm","adata":"","cipher":"aes","salt":"VUibmEIycrc=","ct":"[...LONG_ENCRYPTED_STRING...]"}
encryption_applied: 1
updated_time: 2022-04-24T10:02:20.142Z
created_time: 
type_: 13

INITIAL REPORT (OUTDATED, SUPERSEEDED BY ABOVE):
I was looking for a true e2ee of all data. Joplin claims it uses e2ee but in fact leaks important private info. I enabled e2ee and then checked the files that it uploads. The following fields are not encrypted:

  • created_time
  • updated_time
  • latitude
  • longitude
  • altitude
  • author
  • sourceurl
  • istodo
  • tododue
  • todocompleted
  • source
  • sourceapplication
  • applicationdata
  • order
  • usercreatedtime
  • userupdatedtime

That is a lot of private info that is stored unencrypted -- basically it seems only the body text is encrypted. This defeats defeats the purpose of e2ee to a measurable degree.

Obviously this was not on oversight but intentional (I assume Joplin devs aren't incompetent), so my question to Joplin is: do you intend to change this in the future?

Trivia: 1password, a password manager which has enjoyed popularity, used to do the same, encrypting only the password and leaving all other fields in clear (websites, etc). They were obviously aware that making websites and other private info known to attackers can put owners at risk, but the appeal of harvesting data was too great and 1password resisted complaints for many years, and lost many customers because of it.

2

That's not true, all of this is encrypted except for updated time which is required for sync.

3 Likes
3

Just had a look and whilst the items themselves are present (e.g. latitude), they shouldn't have any data in them when encryption is enabled:

i.e.
Unencrypted:

latitude: 99.999
longitude: -0.999
altitude: 0.0000

Encrypted:

latitude: 
longitude: 
altitude:
2 Likes
4

Got to love how you assume we are competent, so probably we are doing this to harvest people data. Nice.

5

Hmm, maybe I'm looking at the wrong thing, or somehow my uploaded data didn't upload correctly, or maybe even a bug. To be specific: I'm using Dropbox sync, and I enabled encryption after notes have initially been uploaded without encryption (*), then I enabled encryption after I noticed it wasn't enabled in settings, I waited for some to be re-uploaded, and checked the .MDs again, noticing the content encrypted but not the rest. I'm not sure if it's a sync issue or perhaps a bug with this very sequence of actions.

I'll review it all and will have zero problems editing my 1st post if I was wrong and all data is indeed encrypted inside the MDs from Dropbox.

(*) Just curious - why isn't encryption enabled by default? I thought it was, or at least nothing warned me that encryption isn't enabled by default, and the Joplin website has "encrypted" in bold letters on the landing page too. It uploaded notes to Dropbox that I wouldn't have wanted uploaded in clear :frowning_face:

Easy there. Devs may choose to do this as an intermediary step while the product isn't in its final form, hence my question "Do you intend to change this in the future". In 1password's case, where the product was already many years old and important private data was still not encrypted, then, well, yes, there isn't really any other explanation.

6

I mean I don't think we'd call that encryption if all the metadata was in plaintext, but I see what you mean it could have been a beta version or something. It's production ready though, and we haven't enabled it by default yet because of usability issues.

As for the other setup issues you had you might want to open a new thread with specific info as it's hard to tell what may be the problem otherwise.

7

I don't have a use for Joplin e2ee, I self host my data and really don't have much of a need for it. The risk of potentially losing my data to password issues outweighs the benefits for me. I can only imagine the mess of support questions if this was on as default (for example the people that enable file system sync to work as a backup solution - not that this is an acceptable form of backup but people still do it).

2 Likes
8

Joplin is a note taking app, not a password manager. I don't have anything privacy worthy in it, mostly web clippings of recipes and craft patterns.

I don't need encryption, though I have enabled it at some point which made storage twice as large and syncing five times slower. Plus it's yet another password to remember (the password manager does that for me) So I can see why it isn't enabled by default.

9

Please keep in mind that even when using encryption, data is stored locally in its unencrypted form, so you still do need to use some other type of encryption (e.g. full disk encryption) to ensure its full safety on the local device anyway. Encryption as used in Joplin is only useful if you intend to sync your data relying on 3rd party services and such (which, to be fair, you do do), but for people like myself who use already encrypted P2P solutions like Syncthing to transfer the Joplin data between own devices, encrypting it one more time only would only create overhead with no real benefit.

1 Like
10

[the forum doesn't let me tag users, oh well]

I looked again now that all sync is finished and I can confirm that Daeraxa is right, most fields are empty. I updated my first post with a full example as well, so that anyone getting to this thread is not mislead into thinking Joplin does indeed leak important private data. The update_time and type fields are not encrypted.

Please consider encrypting type as well (want me to post a github enhancement?) which would prevent the 3rd party host from building a profile of what types I have and when/how often I use them. The updated_date is less private, the 3rd party sync host would get this info anyway from the file time (and if type is encrypted then I really don't care).

laurent as for enc enabled by default: if the decision is final and you guys won't be persuaded, then please at least visibly warn the users that encryption is disabled by default. Right now it all looks as if it's enabled by default (website has it in bold letters in the first paragraph, etc) and users end up sync'ing unencrypted data with 3rd parties believing it's encrypted ... just like I did on Dropbox before enabling it.

Judging by all the responses in here it seems like everyone is in fact against encryption ... which makes one question the boasting about it on the main page and elsewhere :man_shrugging:.

I for one think enabling it by default brings more benefits than downsides. Local storage and backups aren't affected, but notes by definition are on the same privacy level with emails, sometimes higher (shopping lists, medical stuff, etc).

I am genuinely surprised by the decision ... it's also what sets Joplin apart from the big names.

You wouldn't have been the first one :), e.g. the 1password story.

Perhaps I should have been more specific: My point was about the copy that's sync'ed with a 3rd party storage like Dropbox, not the local storage. I'm not bothered at all about local storage, I don't need that to be encrypted, in fact I prefer it unencrypted as I don't need to worry about the password. Having encryption built in is far more convenient and time efficient than putting the onus on the user to encrypt beforehand using external tools. It's the reason I'm considering Joplin (leaving Evernote).

I don't see the issue, since the data is stored in clear locally. Losing your password would not lose or affect your your data. It's just the remote sync'ed copy that's affected, you can always sync it again with a new password as far as I understand. I noticed database.sqlite has the entire set of notes and settings in clear despite encryption being enabled, which is great, that's what I actually wanted, so I don't need to worry about losing my encryption password (it's just the sync'ed copy that's affected).

Again, I'm not sure I understand this given the data is locally kept unencrypted. Local backups would be unaffected.

11

The plan eventually is to enable e2ee by default, and I keep making improvements in each version so that hopefully we'll get there at some point.

We won't encrypt the type field as it's needed to structure the note collection and to get certain parts of sync working.

12

You're not the only one. This is a goal of the project. There have been changes recently that make the ergonomics of using E2EE nicer, which will maybe tip the scales in favour of E2EE by default.

You're right to point out that the current UX isn't great, whether or not it's enabled by default, it should always be clear to the user. There was an on-boarding addition recently to give the user a more friendly selection of sync targets. Probably a selection about E2EE should be added to that workflow.

13

An additional explanation using simple terms would probably be required as well, because technical terms like "end-to-end" mean nothing to a non-tech-savvy compute user. They will enable E2EE encryption and then think that their local data is encrypted too. Just to be clear, I mean an explanation in the Joplin application itself, not buried in the Docs or somewhere else that the average user is never going to look into.

14

That's true. Encryption has been part of the app for such a long time that I got used to the way it is, but it's true it's not clear.

The section is called just "Encryption", which could indeed mean that all data, including local, is encrypted, which of course is incorrect. And there should probably be some description at the top to explain what it's about.

15

Mostly paranoia because I mess around with my envionment a lot and can never have enough layers of redundancy. I also find it easy to resolve any sync related issues when I'm able to read the markdown in the sync target files which would be much harder when encrypted.
I self host so who am I protecting the data from? Anyone who can gain access to it would be able to gain access to far worse things than the kinds of stuff I store in Joplin (much akin to what @Sophia mentioned).

When I move to a hosted Joplin Server instance I may enable it because of the speed increase is far less impactful (NextCloud is cripplingly slow enough without encrypt/decrypt overhead - NextCloud's fault, not Joplin's).

16

Also maybe just move the encryption menu item right underneath the sync menu item to emphasise the relationship? Or add an additional internal link (or button) within sync menu?

17

That of course is a bit of a straw man argument... why would anyone be against encryption? I just mentioned that in my case I have very little need for it.

I also have no need for a vegetable garden but that hardly makes me against vegetable gardens. It just means that for me personally it's easier to buy that stuff in a store.

2 Likes
18

Judging by all the responses in here it seems like everyone is in fact against encryption ...

That of course is a bit of a straw man argument

Splitting hairs, fine, not like I have anything better to do. All/most replies above the one you quoted, if you had read them, express some view against enabling encryption (pointless, more hassle than it's worth, not fit for purpose, etc), which gave the impression that people have something against it, rather than simply not caring about it. Your very reply starts with "Joplin is a note taking app, not a password manager.", which is as straw man as it is friendly.

19

To be clear I think the encryption is absolutely an important feature, I'm just saying that I have no current need for it as it adds complexity for no benefit for my use. If I was using dropbox or onedrive I might absolutely consider it but as I don't host my Joplin data with a third party, I don't.

I'm also acutely aware of some of the tangles that some users have found themselves in with e2ee - making 20 different master keys, weird mixes of encrypted and unencrypted notes on different clients and a bunch of other things. All could be mitigated by properly reading the documentation and trying to understand but people have gone straight for it, broken something, then come running for assistance. That isn't a good user experience.

I don't think this is true. Sofia and I both said it doesn't fit our use cases, not that it isn't useful for other situations. Laurent and CalebJohn both said that it is a project goal but there are a few UX issues to iron out before it is ready for the box to be ticked by default.

1 Like
20

Ok then, I'll bite one last time and that's it :slight_smile:

The reason WHY it's more hassle than it's worth RIGHT NOW is because it's not very user friendly. No one ever argued that if it were enabled by default without any additional actions needed that would be a horrible thing to do.

As for me saying that Joplin is a note taking app, not a password manager: that was not intended to be unfriendly, it was intended to manage expectations.

Joplin offers good enough encryption and I think it's agreed upon that it could be improved. I think we found our point of agreement here :slight_smile:

Edit: cross posting with @Daeraxa so yeah, definitely that.

1 Like