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!
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.
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.
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.
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.
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 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…
Nextcloud needs to work on its security and privacy, mainly adding E2EE. The Files E2EE is buggy and breaks after 5 minutes of use and they need E2EE for Nextcloud calendar, contacts, notes, etc.
And E2EE needs to offer all the features and not have to sacrifice features for using E2EE. Once Nextcloud does this, it will be a solid cloud storage solution. But sadly it does not meet my security needs since server side encryption is not as secure as client side encryption.
…sadly it does not meet my security needs since server side encryption is not as secure as client side encryption.
Hey, this old thread definitely won’t be integrated based on the discussion previously. However, you can setup your own client side encryption in a safe and secure manner. It simply must be done on your devices directly. As you’ve noticed, Nextcloud’s e2e tool is not a good choice at this time.
Cryptomator - encrypt/decrypt all files and folders from every available platform. DecSync for Android - allows you to sync your contacts and calendars as a file within Nextcloud, then access on your mobile client via Davx5. Encrypt this within Cryptomator.
EteSync - another option with all the caveats mentioned previously.
If you need the client side encryption you must use cryptomator, GnuPG, or similar. Nextcloud cannot know the contents of your encrypted data if this process is supposed to work.
If client side encryption is important, you must use the proper tool and make backups. If these tools are a bother, e2e encryption is not important enough to bother with. I hope this is helpful. It is just the reality of this kind of technology as far I understand it. Good luck and let us know if you make any further progress.
The comments to this topic point out to some important features that should be implemented by a mobile app or a frontend application (client), as well as the backend (server), in order to meet the expectations:
zero knowledge by the service provider
end-to-end encryption of the payload (contacts or calendar events) between the client and the server
tight integration with other prevailing client applications, e.g. mobile dialer, email, calendar, conferencing, etc.
contacts / calendar synchronization between multiple clients (Nextcloud’s advantage, big thanks!)
I see the difficulty in sharing the encryption key among the clients. I agree with @rugk that Etesync is a good example. In this case the encryption key is bound to a single user which is a typical use case.
I understand that this promotion is accepted here and I want to suggest a similar product I am associated with. In addition to EteSync it allows multiple synchronization units organized by accounts (e.g. project team, customers, prospects, sport club, family, private contacts, etc.). They are securely separated from each other. The contacts in an account can be shared and kept in sync on the mobile devices of the shared account, e.g. those of the team members, of the family, etc… All users are authenticated individually and the encryption key is not bound to a single user. Of course, no user is in the possession of the key and all data / communication is encrypted end-to-end.
Please have a look at https://teamsync.dbtech.ch/#background for more information about the motivations of the application. It has just been released and more features are in the pipeline.
That is, of course, insane.