Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What is being backed up to iCloud? #5498

Closed
aaronraimist opened this issue Feb 3, 2022 · 12 comments · Fixed by matrix-org/matrix-ios-sdk#1361 or #5557
Closed

What is being backed up to iCloud? #5498

aaronraimist opened this issue Feb 3, 2022 · 12 comments · Fixed by matrix-org/matrix-ios-sdk#1361 or #5557
Assignees
Labels
O-Frequent Affects or can be seen by most users regularly or impacts most users' first experience S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect Something isn't working: bugs, crashes, hangs and other reported problems

Comments

@aaronraimist
Copy link
Contributor

aaronraimist commented Feb 3, 2022

@faenil:matrix.org noticed this a few days ago https://matrix.to/#/!pMBteVpcoJRdCJxDmn:matrix.org/$oJZGCUKoKELfzzljZ5Liq3PxQ8h9Qx-vybxdp6oLKwg?via=matrix.org&via=privacytools.io&via=tchncs.de

Steps to reproduce

  1. Have iCloud Backup enabled
  2. Login to Element iOS
  3. Open Settings.app
  4. Tap your name
  5. Tap iCloud
  6. Tap Manage Storage
  7. Tap Backups
  8. Tap on your device
  9. Scroll down to Element

Outcome

What did you expect?

Element iOS shouldn't be backing up message contents, encryption keys, or media since to iCloud Backup since it is not end-to-end encrypted https://support.apple.com/en-us/HT202303

Alternatively if does backup things to iCloud, it should be encrypted by the app before it is backed up. I'm not sure what there would be to backup to iCloud though considering Matrix already has it's own key backup feature and the homeserver should be storing all of the other stuff.

What happened instead?

Element iOS has backed up a somewhat large amount of data. For me it was 58 MB.

image

I then sent a 6 MB image in an encrypted room and backed up to iCloud again. The backup increased to 88 MB.

image

I'm not sure what exactly is being backed up but I searched the repos for https://developer.apple.com/documentation/foundation/urlresourcekey/1408756-isexcludedfrombackupkey and didn't see anything marked as being excluded from backups. I'm guessing this means everything stored locally is being backed up.

For comparison my Signal iCloud Backup is only 300KB. It looks like they have excluded most stuff from being backed up signalapp/Signal-iOS@fb0281f.

Your phone model

No response

Operating system version

15.3

Application version

1.7.0

Homeserver

No response

Will you send logs?

No

@aaronraimist aaronraimist added the T-Defect Something isn't working: bugs, crashes, hangs and other reported problems label Feb 3, 2022
@ara4n
Copy link
Member

ara4n commented Feb 3, 2022

This looks like a thinko; we shouldn't be storing anything in iCloud backup.

@faenil
Copy link

faenil commented Feb 4, 2022

@aaronraimist thanks for creating the report following my questions on the Matrix channel 🎩
I was planning to sync with the developers before raising the issue here, but thanks for taking the lead 😃 👍

First of all, I would like to thank the Element (and Matrix) teams for the awesome project they have created and all the effort they have put into it.
I have been visiting your booth at FOSDEM for a few years, I hope to see you there again next year, in person! 🤞

Back to the ticket:
I have been self-hosting my server for some time.
Some of the users on the server own iOS devices.

Given the core values of Matrix and Element, I fully trust the app not to share any data with iCloud (unless explicitly requested by the user).
However, I have recently borrowed an OS device for a few minutes to try and verify those assumptions myself.

Unfortunately I did not have the needed equip to do actual debugging, so I only did a few user-level tests.

I created a E2EE room with only myself and the (just created) iOS user and shared one high res video and about 10 pictures.

While running the experiment, I checked the iCloud storage overview in the Settings app on the iOS device and noticed that the iCloud data for Element kept increasing, as I sent more messages.

After sending the 10pics and the video, the Element iCloud backup was about 2MB (if I remember correctly).

Disclaimer: I am a developer/tinkerer, but no background on iOS :-)
I could not find any info on Element's website/docs about what data the iOS client is backing up to iCloud.
I went through Apple documentation for iCloud and CloudKit, but that did not lead to a clear answer.

I would like to propose the creation of a document which would provide info on:

  • what data is backed up to iCloud and in what format (encrypted messages? thumbnails? metadata?)
  • pointers to the component (snippets of source code, or at file/folder level) managing each data type
  • options for admins to minimize the amount of data shared with iCloud (without trusting the user to disable iCloud backup for the app)

I will be happy to contribute to this effort as I can, toddler allowing :)
(no iOS dev experience though, so writing it from scratch won't be feasible, but I'll be happy to review, edit and/or provide feedback)

Thanks again for all your effort on this project!

@stefanceriu stefanceriu added S-Major Severely degrades major functionality or product features, with no satisfactory workaround O-Frequent Affects or can be seen by most users regularly or impacts most users' first experience labels Feb 4, 2022
@faenil
Copy link

faenil commented Feb 6, 2022

Great! Thanks for working on this with high prio! :)

@faenil
Copy link

faenil commented Feb 10, 2022

Hi @Anderas, thanks a lot for working on this!

I saw some of your comments to the PR which seemed to imply further changes might be needed to fully resolve this (e.g. the comments related to the application container).

Could you confirm whether the issue is fully or partially fixed?

Regarding documentation: would you guys like to have a separate issue to track updating the official documentation, as proposed above?

Regarding testing: are you planning to add tests to ensure there are no regressions on this and all files are excluded from iCloud?

Thanks again! :)

@Anderas Anderas reopened this Feb 11, 2022
@Anderas
Copy link
Contributor

Anderas commented Feb 11, 2022

Hi @faenil . Thank you for raising this issue to begin with.

You are right that this hasn't yet been completed (but was rather autoclosed by the first PR), I've reopened it now. I am going to raise a PR against the main app that integrates the blanket exclusion of all folders.

As Element, we do not aim to store anything in iCloud at all, so in that regard documentation of what is being stored should not be necessary. Tests are also feasable as we can launch the app and ensure attributes are set correctly on all key folders. This will be a part of the PR against the app.

@Anderas
Copy link
Contributor

Anderas commented Feb 11, 2022

@faenil you can check the app-side PR. When testing this on a device, local backups did not contain any data at all, however iCloud still reports some small amount of kbs. On my device this was around 200kb, less than signal. Local and iCloud backups should be identical, so believe this disparity is something on the Apple side, and not containing any Element data. I created a separate issue to look into this, but it has a much lower priority than the one you reported.

IMG_899D2821D499-1

@faenil
Copy link

faenil commented Feb 11, 2022

Hi @Anderas, thanks for the update!

It's great to see real progress on this. It is very appreciated! :) 🚀

As Element, we do not aim to store anything in iCloud at all, so in that regard documentation of what is being stored should not be necessary

While this is great to hear, I believe it would be beneficial for this to be part of the official documentation as an official statement/promise 😅
Even just adding it to the readme would be an acceptable start, if posting it on the official website/documentation is not feasible.
If privacy is indeed at the heart of Element, one could argue that the other issue (thanks for creating it) should be a high priority item too, not a minor enhancement.
Until tests are in place, your promise not to share anything with iCloud could be broken at any point (not intentionally, of course...we are all human, bugs happen)

@faenil you can check the app-side #5557

Thanks for the link. The PR description seems to imply the task is not fully implemented, as any file created during the first app execution will be backed up to iCloud, including potentially sensitive data (if I understood correctly, the exhaustive list of files that were previously being backed up is not known)

Quote the PR description:

Note that if this is the first time a user has installed the app, some folders created after app start and not explicitly excluded will be backed up to iCloud. Once the app is relaunched, the newly created folders will not be excluded as well and removed from the backup.

Thanks again!

@faenil
Copy link

faenil commented Feb 16, 2022

Hi @Anderas just wanted to report that this fix is missing from the most recent release notes :)

@Anderas
Copy link
Contributor

Anderas commented Feb 18, 2022

The change was merged after the creation of the latest RC, so will be a part of the next release, change entry here.

As to your earlier query:

The PR description seems to imply the task is not fully implemented, as any file created during the first app execution will be backed up to iCloud, including potentially sensitive data (if I understood correctly, the exhaustive list of files that were previously being backed up is not known)

This would only affect files we do not explicitly exclude, which is mostly files whose lifecycle we do not directly control (UserDefaults is a great example). It would also help prevent future regressions where someone forgets to exclude a newly added folder, although the aim is still to exclude everything on creation, where possible.

@faenil
Copy link

faenil commented Feb 18, 2022

The change was merged after the creation of the latest RC, so will be a part of the next release, change entry here.

Oh I see, it was not included in the 1.8.1 branch. Thanks.

This would only affect files we do not explicitly exclude, which is mostly files whose lifecycle we do not directly control (UserDefaults is a great example)

I appreciate the explanation.
My main worry is that those details require knowledge of iOS APIs and iOS development practices, in general.

I am still not really sure what data exactly will be uploaded to iCloud after this patch :D

For instance, what is Element iOS storing in UserDefaults, exactly?

I think the whole community of users would benefit from a document that explains how Element iOS handles iCloud backup and possible issues that might arise in case of bugs.
It is very different to the Android client, where disabling the backup functionality pretty much covers everything.
In the iOS case, this sounds like something that can potentially go wrong at any time.

I think there is great value in ensuring those risks are known to the more privacy-oriented users :)

As you mentioned, if there is a regression and someone forgets to exclude a newly added folder, that would end up on iCloud, at least until the application is started again and the fallback logic marks those folders as excluded.
Some users might not want to take that risk, depending on exactly what data could end up being uploaded due to a bug.
For instance, could unencrypted pictures (or thumbnails) end up on iCloud in case of a bug in the exclusion rules, even when the chat is configured as E2EE?
Or does Element iOS always store media (pics/videos/etc) on disk in encrypted format and then decrypts it on the fly when they are shown to the user, so that the decrypted data is never saved to disk? (I doubt this is the case, but I hope you get my point :) )
Different users might have different levels of risks that they are willing to take:

  • some might decide to stop using Element iOS if there's a risk of their unencrypted pictures ever reaching iCloud via one of their less tech savvy users (assuming they don't save the pics to Gallery, as that would make everything void).
  • others might stop using it if any of their personal data reaches iCloud at all (even in encrypted format)
  • others might not care about what data is uploaded to iCloud :)

By having a document that explains what data is being stored on disk by the client and the risks related to that data being uploaded to iCloud, everyone would be able to make an informed decision based on their personal situation.

the aim is still to exclude everything on creation, where possible.

I do appreciate it is a non-trivial situation.
Given the privacy focus of Element, I think there would be great value in making this information available to users.

Something along the lines of:

Element for iOS aims not to share any data with iCloud. Despite our best efforts, there are some files which we have no control over, and those files might/will be uploaded to iCloud, if the iCloud backup for Element is enabled.
Those files are:

  • Application settings (such as <include_examples_here>
  • this
  • that

Would you agree that would be helpful? :)

@ara4n
Copy link
Member

ara4n commented Feb 21, 2022

Hi @faenil - agreed that we should have a "Here is a list of the data that gets stored in iCloud, if backup is enabled" section in the readme, once the fixed behaviour is released.

@faenil
Copy link

faenil commented Feb 21, 2022

Awesome! Thanks @ara4n!
I will create a new ticket to track that :)

Feel free to close it if you'd rather keep this one open until that is completed 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
O-Frequent Affects or can be seen by most users regularly or impacts most users' first experience S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect Something isn't working: bugs, crashes, hangs and other reported problems
Projects
None yet
5 participants