Allow encryption of calendar/parts of calendar via gpg/keybase or other (the same for Contacts too)

[mannp]

As the encryption module doesn't really add value according to most threads that I have read, perhaps allow users to encrypt all or part of a calender details so confidential data is secured in case the nextcloud server is compromised.

The QNotes app does similar by allowing the importing of a keybase or gpg key and a button press allows encryption/decryption of that data.

Thanks for your consideration

[MariusBluem]

Nice idea in general, but I think this is not possible ... especially if you want to use CalDAV clients ;) @georgehrke

[mannp]

Why would you say that when you could use say 'Appointment on dd:mm:year [encrypted data] and the calDAV would still sync it as text, just encrypted.

[mannp]

Wow a police state, closed before even hearing more information on the proposal?

It works with notes but dismissed out of hand for CalDAV? and CardDAV as you've closed that one too.

[MariusBluem]

Police State - seriously? I just wanted to merge your 2 issues (one about CardDAV and the other about CalDAV) into one - makes no sense to discuss this encryption topic for Calendar and Contacts into 2 separate issues since this is about the same app called dav ;)

[mannp]

Came from the forum where threads were being locked if they were resolved, which doesn't allow other people to ask for help on the same issue, which is odd for a community forum.

As I mentioned in the other thread, I assumed as they have separate forums/apps they would be developed by different people/teams, so I separated CalDAV and CardDAV out. Is it the same app DAV, as I have calendar and contacts installed as separate apps.

Apologies if I was a little over zealous, but the issue of encryption seems a large one that nextcloud hasn't yet resolved and it could be helped along with some simple gpg/keybase interaction perhaps.

The idea used in QNotes to encrypt notes still allows those notes to sync with Nextcloud Notes, they just have an encrypted text part and a normal part.

[MariusBluem]

Calendar (frontend-app): github.com/nextcloud/calendar Contacts (frontend-app): github.com/nextcloud/contacts

Calendar/Contacts (backend!!! - we are talking about here) ==> github.com/nextcloud/server

[mannp]

Then why don't you move one to calendar and one to contacts if I have posted in the wrong place rather than closing them and getting all upset about it.

[skjnldsv]

Encryption should be done in backend, not in front end. So this is the right place imho.

[MariusBluem]

I do not understand that ... Encryption is backend - so you are correct!

[mannp]

Isn't is worth understanding what the intention is before blindly closing tickets and then reopening them.

The current encryption is server based and from what I have read it does not offer much in the way of usability or protection to files at rest.

I am suggesting the clients (including server web gui) do the encryption/decryption so the existing CalDAV/CardDav syncing works without much change.

If the contacts and calendar are gpg encrypted and someone gains access to the server, then that data is still encrypted.

The keys are stored on keybase or the gpg key servers and not sitting on the nextcloud server somewhere.

[georgehrke]

Nice idea in general, but I think this is not possible ... especially if you want to use CalDAV clients ;)

@MariusBluem WebDAV stays fully functional even with the encryption app enabled :)

Why would you say that when you could use say 'Appointment on dd:mm:year [encrypted data] and the calDAV would still sync it as text, just encrypted.

I'm not a big fan of messing with the iCalendar data at all. Storing the actual calendar data encrypted in the database would be a possible enhancement. Creating half-encrypted calendar entries that no other caldav client can read is a bit weird.

There is a feature request for attachments in the calendar app. That would allow you to set Appointment on dd:mm:year [encrypted data] as a summary and attach an encrypted text file with more details.

[MariusBluem]

@MariusBluem WebDAV stays fully functional even with the encryption app enabled :)

Did not say anything different by intention ... encryption does simply not touch CardDAV and CalDAV.

[georgehrke]

especially if you want to use CalDAV clients ;)

^

But it would definitely be possible to encrypt the data in the database without breaking CalDAV/CardDAV clients.

[mannp]

@georgehrke why wouldn't any other client be able to read the calendar data?

It would be a line of text that is synced across the clients and they would be none the wiser if the data was encrypted of not.

The idea of only encrypting part is that the confidential data is encrypted, but the less critical data of an appointment on a date is not.

I am not talking about attachment at all really, I am talking about encrypting the confidential data so that a company is protected and the users data is too.

For CardDav the persons name could remain unencrypted but the telephone and address would be encrypted.

Qnotes app does the encryption with keybase or gpg its synced to the server and back to my other devices where I can decrypt, if I have the correct key on those devices.

If the data in the database was encrypted where would the key be stored, as if that is on the server it defeats the object of the encryption.

[tflidd]

I am suggesting the clients (including server web gui) do the encryption/decryption so the existing CalDAV/CardDav syncing works without much change

Is there a common standard? It would be great to have client-side encryption for that and the web-front-end is a bit tricky (the certificate is stored in a browser plugin? Or a separate password?). Is there a common standard for other calDAV clients for client-side encryption?

The idea of only encrypting part is that the confidential

What part is confidential and which one is not, this is impossible to define in general (e.g lawyers or doctors probably want to protect the names of their contacts as well).

[mannp]

@tflidd through my searching I have not found an implementation of at rest encryption for CalDAV/CardDav, but after using QO*$notes app which interfaces with gpg or keybase gpg keys and allows encryption of text in a note, which syncs via the standard nextcloud notes app, it seemed logical that CalDav and Carddav could do the same, as it wouldn't need to know the data was encrypted, just sync the records as it sees them.

True but that definition would be for the user to set. If the name is encrypted for a Lawyer they still need a reference to who that client is.

I don't mean partial encryption to complicate things, it just seemed that if partial or full notes could be encrypted with existing command line and web page encryption tools, couldn't the nextcloud apps harness those tools to encrypt text in critical areas of data on the nextcloud server without changing the underlying format an encrypted text string in a data field....

[mannp]

Looking at SuiteCRM as an example they have a specific 'Encrypt Field' which allows the text / contents of that field to be encrypted. Allowing specific data to be chosen by the admin to be encrypted.

Seems that may be more appropriate solution as a business option for storing confidential data.

[LukasReschke]

We're striving to be compliant with as many clients as possible and adding an encryption layer here is making this way harder.

Considering the probably very low amount of users that would use something like this actively (since the native CardDAV sync on most OS will probably just ignore this), I'm going to close this one here. It's a nice idea but in reality, we have other higher priority issues and doing encryption wrongly or doing encryption in a way that isn't tested properly this is going to bite us in the long run.

If someone has active interest to work on this, they're as always invited to open a pull request :)

[mannp]

@LukasReschke Do you have a correct end to end encryption solution currently or in the works, as I would love to use it with all my data rather than just cryptomator files?

[calvadosxo]

Any update on this? People looking for privacy calendars are getting played at the moment since the database is not encrypted.

[tflidd]

Any update on this? People looking for privacy calendars are getting played at the moment since the database is not encrypted.

Did you read the posts here? Some general issues have been pointed out that makes it very unlikely to be implemented soon. But you are welcome to participate in this open source project:

If someone has active interest to work on this, they're as always invited to open a pull request :)

Until then, you can only get privacy when you host everything yourself. Or you don't use caldav and just a file in combination with client side encryption, there will be a solution in NC soon: https://help.nextcloud.com/t/nextcloud-introducing-native-integrated-end-to-end-encryption/21579

[4jNsY6fCVqZv]

@LukasReschke I discovered this project at an open source conference. https://www.etesync.com/ Would Nextcloud integration be useful and conceivable to solve this issue?

[georgehrke]

@4jNsY6fCVqZv See the reasoning above ...

We have absolutely no interest in rolling out our own desktop and mobile clients for contacts and calendar. Integrating etesync would require us to do so.

Furthermore it doesn't even support iOS which is a major downside. 👎

[4jNsY6fCVqZv]

@georgehrke

Integrating etesync would require us to do so.

I understand that very well, yes. Do you see another possibility?

Furthermore it doesn't even support iOS which is a major downside.

After all, her last monthly blog article (August 2019) says:

"Mobile Clients We have been working hard on the iOS client with financial support from NLNet, and important announcements regarding it are on the way."

Then it is at least an idea for an integrative and platform-wide concept, if you decide to develop Nextcloud further towards a comprehensive end-to-end encryption solution.

[trymeouteh]

I think this is needed and should a high priority since E2EE will ensure the best privacy and security for users. I do not know the standards for GDPR but I do not see Nextcloud meeting up to good privacy and security standards since it lacks E2EE.

Etesync is the best calendar, contacts and task cloud syncing service out there. It has E2EE and Etesync cannot read anyones contacts, calendars or tasks.

For Nextcloud to do this, this will require Nextcloud making a Nextcloud calendar app, contacts app for Android, iOS, Windows, Mac and Linux or having the Nextcloud Files Sync clients add a calendar and contact syncing integration into the clients.

EteSync is the king of privacy and security for calendars since they have E2EE. I would like to see Nextcloud add this security and even allow the ability to edit the calendar and contacts in the browser using JavaScript to encrypt/decrypt the client side encryption. And I would like calendar and contacts sharing to still be possible within the same domain and to be federated.

I know it is lots of work, but this is for users security and privacy on their data. Contacts lists show who someone knows and communicates with, calendars show what someone has planned for when and where. This is very sensitive data that should be encrypted on the client side.

[georgehrke]

For Nextcloud to do this, this will require Nextcloud making a Nextcloud calendar app, contacts app for Android, iOS, Windows, Mac and Linux or having the Nextcloud Files Sync clients add a calendar and contact syncing integration into the clients.

As I pointed out numerous times in this thread already, we have absolutely zero interest in developing our own mobile / desktop clients for Contacts and Calendar. Hence this feature won’t be happening.

[blu-IT]

What about encrypting the complete database?

https://www.zetetic.net/sqlcipher/

https://github.com/sqlcipher/sqlcipher

[ntninja]

@georgehrke @trymeouteh: What makes you believe that NextCloud needs to provide the clients for this?

Updating the database to support this? Yes. Extending the default calendar/contact web clients with EteSync? Somebody would have to do that at some point, but let's not pollute this issue with that. Providing a mobile/desktop client for this? No, EteSync (the company) already provides those for mobile and they support using your own server just fine. (They now also got GSoC students for working on Linux GNOME & KDE clients and have a Thunderbird extension in the works, as well as providing an EteSync2DAV adapter for arbitrary clients.)

So, to make this an actionable goal, I think this issue (nowadays) asks for the following:

• [ ] Encrypt the existing database entries in a EteSync compatible way
• [ ] Expose the existing DAV support (with server-side decryption) on top of this new schema
• [ ] Expose an EteSync-compatible client API with no sever-side decryption additionally to DAV

Does this sound more reasonable?

@blu-IT: That would require each user to have their own (SQLite) database file, which is not how NextCloud works and I don't think that is how the devs want it to work either. Also, it is a server-side only solution.

[georgehrke]

I would kindly ask you to stop mentioning me please. I have no further interest in discussing this topic. Thanks! :)