Service Announcement : 26 May

@JPM13 please confirm also when possible

Than have a look at the users’s settings page about security. It says (at least before the maintenance) that even administrators cannot access the files. And it links to an NextCloud Wiki page, where the different encyption modes are explained. Encryption with a server side key would mean, anybody with admin access can decrypt user files, and only user-key encyption would keep admins from reading the files.

So it doesn’t suggest, it clearly is false.

Sounds harsh, but I’d rather trust eFoundation than Google at the end of the day.

2 Likes

@Scytale
why are you downplaying how useless server side encryption is?

Per Encryption configuration — Nextcloud latest Administration Manual latest documentation

It encrypts only the contents of files, and not filenames and directory structures.

and

Encryption keys are stored only on the Nextcloud server, eliminating exposure of your data to third-party storage providers. The encryption app does not protect your data if your Nextcloud server is compromised, and it does not prevent Nextcloud administrators from reading user’s files. This would require client-side encryption, which this app does not provide. If your Nextcloud server is not connected to any external storage services then it is better to use other encryption tools, such as file-level or whole-disk encryption.

/e/ team could trivially modify their instance to decrypt user files if they wanted to.
(not saying they are to be clear)

Client side end-to-end encryption for cloud storage in 2022 is an absolute must have, especially for a service advocating privacy.

4 Likes

Thanks for your comment, we will look into improving this warning.
In fact, we changed that section to clarify even more than the default section of NC does:

Edit: I think even the per-user encryption can be rolled back in Nextcloud. Only end-to-end encryption is a guarantee and Nextcloud’s implementation is not reliable as you can see on their application page.

So while I agree with you, very few (if any?) cloud services offer this feature because it’s not trivial and has an impact on ease of use. But some apps like keybase or Matrix are simplifying this.

1 Like

All I wanted to read, thanks guys for the updates! I’d rather stay on a service that admits it when something wrong happens than one that tries hiding this kind of mess…
All my love to the dev team (working on this on a Sunday must be a real pain).
Good luck with all this!

3 Likes

The same thing happened here:

2 Likes

It breaks the concept nonetheless. Personal files were leaked to a different user, this is worse than data loss.

Indeed. GDPR articles 33 and 34 should apply, and some kind of meaningful independent audit should be in order.
For me it’s the end of the /e/ cloud as a service to be considered for the time being, but I didn’t use it so far anyway, so that’s pretty cheap for me to say.

Seconded. Commiserations.

2 Likes

thanks, already replied there too. Notes are files in the end.

It breaks the concept nonetheless. Personal files were leaked to a different user, this is worse than data loss.

I agree. We hope to recover your trust even if you’re not a cloud user yourself.
At the same time, push the roadmap for end-to-end encryption so you don’t even need to trust us to use our service.

Indeed. GDPR articles 33 and 34 should apply, and some kind of meaningful independent audit should be in order.

We will of course abide by all our duties in this regard.

Thanks everyone,
Arnau

6 Likes

I don’t want to trivialize the scope and relevance of this error, but I’m glad you guys at /e/ are so open about it. IT services and especially cloud computing don’t work entirely without trust. And my trust in you is still there!

P.S.: The new eCloud dashboard looks good :wink:

3 Likes

It seems that ecloud photo now synchronize better.
I’ve checked and one of my vidéo I recorded this month that was only present on my phone have been finally uploaded to the new ecloud.
I didn’t check for older ones that had this problem (don’t remember which ones they are and It would take some time).

Hello all,

Today I discovered 150+ photos from several other /e/users devices on my mobile phone. Around 50 of these are screenshots and the rest are photos taken with the mobile devices. My e/could storage has been full for ages, so not sure how this is even possible? I can see that these files were downloaded to my phone around 10am this morning (UK time).

This event has made me feel very vulnerable and I am now naturally questioning my trust in /e/. The thought of my own personal data randomly ending up in a strangers device is soo unsettling… The very reason I am using this operating system is exactly to avoid these kind of problems.

If anybody has any advice as to what I should be doing now, that would be much appreciated.

Many thanks,

S

2 Likes

… and perhaps you want to read this topic here from earlier on for more details.

So this is what’s happening, I discovered some pictures and screenshots that didn’t belong to me and I was wondering WTF? How did these pictures get to my phone? Now I’m wondering if MY pictures are on someone’s cloud or mobile :thinking:

Hi! If you read this thread you’ll find the answer to that question. In short: yes possibly if you have uploaded stuffs on the cloud during the 25 minutes during which there was a bug on the server. Only the pictures in question can have been uploaded to the wrong account. All other files should not be at risk of leak.

Well I didn’t upload anything so I guess I have nothing to worry about. The pictures and screenshots on my mobile were deleted so the owner whoever he/she is has nothing to worry about from my side :+1:

We want to report that we encountered an incident today impacting some of our cloud users over a limited amount of time.

Over the last few days, we have conducted major migrations of our cloud services, moving to a new infrastructure with a double purpose :

  • we have added the foundation for a SSO (Single Sign On) mechanism that will allow all users to authenticate using only one account across all our websites, instead of having a dedicated account for each of them. For instance, users of community.e.foundation will eventually be able to sign in to gitlab.e.foundation with the same account

  • we have deployed a new user interface at ecloud.global, and new features, that will make users’ life easier and the service more appealing.

This migration has gone globally well until today, when we detected a human error with one of a final migration scripts that was meant to fine tune the system performance.

On Sunday 29th of May, between 08:59 and 9:15 UTC, this error lead to an unexpected state of our cloud services, when we encountered some authentication issues. Some users may have been authenticated as a different user. For a limited amount of users, this resulted into viewing content from another users, especially pictures, notes and various files.

This bug didn’t impact email.

We’re still investigating if this issue had any impact with contacts and calendar data, but so far we haven’t been able to confirm it is the case.

After the bug was corrected, the authentication issues were solved and the service was working properly. Impacted users normally all got their own content back on their cloud.

We’re still figuring out if some users are still impacted since some side effects are possible.

We have found that this bug could have impacted at maximum 3307 users (about 5% of ecloud users) for 15 minutes, if they were connected to the service.

So far, 4 users have contacted us about this issue.

We ask users who would have some doubts about the situation to contact us at helpdesk@e.email to get more information whether their account has potentially been impacted or not.

Finally, we want to state again that personal data stored at ecloud.global is encrypted server-side. We have been asked why it’s not “End-to-end encrypted” (E2EE). E2EE is the ultimate answer to protect data, but it’ s a complex topic, and today, most clouds are NOT end-to-end encrypted. Moving to an end to end encryption is a goal to guarantee the best service possible in the long run. We hope to give some good news about this by the end of 2022.

Although this happened during an exceptional and major migration process, we sincerely apologize for this very unexpected situation. Privacy and transparency are 2 important cornerstones of our project, and what we strive for, to gain and keep your trust.

We’re consolidating our processes to ensure it won’t happen again.

We will share more information about our findings within 72 hours.

We thank you again for your trust.

Best regards,
Gaël & the team

12 Likes

This topic was automatically closed after 14 hours. New replies are no longer allowed.