Hi, I like the murena cloud, but I’m not feeling exactly comfy when I know some people still have access to my data (trained staff, police, etc). One year back, when I found e/os/, I read about plans with end to end encryption, but I guess it is still not implemented, right? Or is there some setting already? Are there any near plans for this great feature? I think people would buy more space from murena, when they know it is secured - and support the project 
I’m grateful murena has 1GB free, but with photo sync disabled it is more than I will ever need 
6 Likes
I have been a Murena user for one year. Presently have ProtonMail, ProtonVPN, ProtonCalendar, and ProtonDrive. I would drop Proton if Murena started to encrypt, end to end, immediately. I also love the /e/ concept and fully endorse it but the OP asks this question back in April '23 and no one replied. Is this not high on Murena’s near future plans? The seamless Murena Cloud is great but let’s not stop there.
1 Like
Question, what is referred with end-to-end encryption? Is it about email? In that case, non federated solutions, like encryption only working if both end users are /e/ or murena.io users, don’t make sense to me. Yes I’ve read a lot about protonmail and tutanota, but in reality the encryption solution is sort of not federated.
Also, email, even with encryption is not as safe as one might believe, but I agree we should encrypt as much as we can, meaning both the body and the subject. But to me using gnuPGP keys encryption is the solution, since that works no matter the email provider. There are several email clients solutions proving such solutions, including Thunderbird and Kmail, though Thunderbird decided to stop using gnuPPG, but still uses its own openPGP solution.
Email wise, one shouldn’t depend on the email provider to encrypt/decrypt messages.
For other cloud services, like having photos encrypted, and sharing them encrypted, so that only specific people targeted can decrypt it is more complex. Not sure if there are services like that. Nextcloud, which is pretty much what /e/ uses, doesn’t support that.
Or having contacts and calendars encrypted in the cloud, and client syncing unencrypted with those encrypted services, is also not available, not though cardav/caldav that I’m aware of.
If you use storage just for yourself, not to share with anyone else, there might be syncing mechanisms which allow to keep stuff encrypted in the cloud. Or you can manually encrypt stuff through GPG prior to uploading stuff. It might be worth looking for syncing solutions with encryption on the cloud… But that won’t be shareable BTW.
Thanks for the insightful and thoughtful reply. I have been having doubts on continuing with proton once the subscription ends and going full on Murena and have these questions. I would like to get back with you at a later time about gnu/PGP.
In this discussion it is clear that some of the problems of nextcluoud that are being discussed here are now overcome. However, in the privacyguides forum they continue to talk about nextcloud as a system that is not sufficiently secure. In particular, it seems that the public instances based on nextcloud have vulnerabilities.
I am very sorry about this because the principles that underlie the nextcloud and /e/ cloud projects are of great value to me: either open development, the use of federated protocols, etc.
This recent article lays out the results of some audit on nextcloud’s ability to withstand attacks and the performance would seem to be quite poor (some comments on this article can be found in this thread). Conversely, the results of the tests carried out on proton services seem to be quite satisfactory:
- Security audit results for Proton Mail(new window)
- Security audit results for Proton VPN(new window)
- Security audit results for Proton Calendar beta(new window)
- Security audit results for Proton Drive beta
What can you tell me about it?
I would also like to know if it is true that the synchronization of contacts and calendar in /e/ os does not use encryption. Thank you
1 Like
A key phrase in the article abstract is
Nextcloud’s strong security claims motivate conducting the analysis in the setting where the server itself is considered malicious. (my emphasis)
So I guess it comes down to whether or not you consider that /e/ and their NextCloud instance are likely to be ‘malicious’. If you do, then I suggest not using their cloud at all.
The abstract also says
We have responsibly disclosed the three vulnerabilities
to Nextcloud. The second and third vulnerabilities have been
remediated. The first was addressed by temporarily disabling
file sharing from the E2EE feature until a redesign of the
feature can be made.
So the issues, such as they are, appear to have been mostly addressed already.
This topic was automatically closed after 30 days. New replies are no longer allowed.