Add end-to-end encryption for contacts & calendar

You now have e2e crypto for files, so the next logical step is to add it for contacts & calendar, as these are (also or, maybe, even more) sensitive data!

So in a thread you (@Jospoortvliet) already replied me.

Then the web interface wouldn’t work anymore and that is very important for those features,

Yes, I understand that. But you also accept feature loss for the files e2e encryption, so this is totally not a problem. It should be the user’s choice, after all! Make it optional, and I would gladly appreciate this feature loss!

And of course this encryption may not affect all contacts. You could also make it selectively, or, at least, it of course won’t matter for contacts received from other servers/usernames on the NextCloud instance or mails, which are used for sharing files. (so these are saved on the server anyway)

it would break compatibility with every application out there (no way your phone could use it unless we built a unique calendar app

That is not true. E.g. on Android it does not need yet another calendar app, just one app, which syncs the stuff. Same for many other OSes.

A good example is e.g. this app:

It e2e encrypts all contacts & calendar, and integrates with many platforms. The Android app is e.g. based on DavDroid, so you can do that, too.

1 Like

True, it is possible to build a custom Calendar app that supports E2E. As a company and as core contributors I am not aware of any plans to develop our own Calendar app, we have no plans to develop a E2E calendar app either, however we’d be happy to see other community volunteers step up and work on this.

Yet again: It does not need a (new) calendar app, it only needs an app for syncing, Basically you can take DavDroid, fork it, add your e2e crypto and that’s it!

This is what etesync did, and their model looks solid.
Other platforms sometimes also have e.g. calendar apps (GNOME) or other software, which may get interoperable with an addon (Thunderbird e.g.).

I would love to see e2e crypto for all aspects of nextcloud too, but I get @jospoortvliet point. Nextcloud is awesome because it keeps to standards and avoids reinventing wheel.

I think the best option out there would be implementing crypto into caldav as a protocol so that all the caldav supporting clients would have to support it but it would be a standard for all of them. Otherwise just like eteSync everyone starts fragmenting and forking so at the end you end up with multiple davdroid clients, not to mention other apps such as gnome calendar, thunderbird etc.

3 Likes

I agree with @rugk that e2e encryption for contacts & calendars would be an awesome feature. You could start with implementing it server-side and then client apps (like DAVdroid, Thunderbird Lighning, …) would have to adapt in order to support it.

While it’s true that the web applications no longer would work with encrypted contacts & calendars, that tradeoff would be quite ok in my eyes. I know lots of Nextcloud users who merely use the contacts & calendars apps for syncing via cardDAV/calDAV and don’t use the web interface at all.

I filed a related feature wishlist bug against the Contacts app: https://github.com/nextcloud/contacts/issues/569

1 Like

As @jospoortvliet said, special apps or plugins would be needed to use E2EE Caldav/Carddav at all. This would make it yet another proprietary standard nobody else would use out there.

To be honest, the only way to get E2EE in Caldav and Carddav standardized for everybody would be to lobby at the IETF (and probably a few big companies) to get this published as official RFC’s.

1 Like

I know it’s server side but its a step forward. I wonder how posteo does encrypted calendars and contacts. They do use cal/carddav
https://posteo.de/en/help/how-does-encryption-of-the-address-book-and-calendar-work

They simply encrypt the content with your password. That means that it gets synced encrypted - a third party won’t work. Or they automatically decrypt when syncing, which means storing your password on the server - not really any improvement, security-wise, over not doing it at all.

But that is the case anyway, they have to decrypt it for you to use it and they offer a web interface. You can’t do end to end encryption with a web interface, at least not in a way that is any more secure than not bothering with it at all.

If you wonder why that is, just think over how that would work.

Situation:
Data encrypted on server with your password. Secure!

You open web browser, go to the calendar app. Browser has to display data. Transport is https (Secure). But data is encrypted. So, either:

  • Sent the password to the server for decryption of data. End-to-end protection is now broken, an evil server could store the password.
  • Use the code FROM the server (as that is what is running in the browser) to decrypt the data client-side. End-to-end protection is now broken, an evil server would just sent compromised code that sends your password to a third party server for storage.

The third option would be to only display encrypted data and let you copy-paste it in a text file and decrypt it manually :wink: That is, of course, insane.

Conclusion: you can’t do end-to-end encryption in a browser. Everybody promising you that is lying/deceiving and does not deserve your money and promotion. Yes, I look at you Threema, TressorIT and MANY others.

This really annoys me - so many companies advertise with something that is just plain technically impossible, lying to users about how secure their technology is. I get it - they have no choice - users want privacy and prefer to be lied to than having to self-host or at least federate/distribute over many providers, which is the only real solution…

1 Like