> As such, couldn't Apple just treat .app bundles (and a few other bundle types, e.g. .framework, .kext, .plugin, etc.) specially for purposes of iCloud backup,

> As such, couldn't Apple just treat .app bundles (and a few other bundle types, e.g. .framework, .kext, .plugin, etc.) specially for purposes of iCloud backup, by e.g. content-hashing all the files in each bundle, shoving those files into an object store keyed by content hash (i.e. a Content-Addressable Store), CDN-mirroring that CAS, and then saving the .app bundle in your backup as a BOM for reconstructing the bundle from the CAS CDN? Many macOS apps are not sandboxed. Even apps which have native iOS ports litter crap all over the macOS filesystem. Of course, the primary offender is apps which have their own always-running autoupdater services. My money Apple will eventually do a devteam-bound overlay filesystem for apps which have not adopted sandboxing. > Keep in mind, Apple have never promised E2E encryption for iCloud backups, only "encryption in flight" and "encryption at rest." (See https://support.apple.com/en-ca/HT202303 https://support.apple.com/en-ca/HT202303). And even then, that's never included an implied encryption of your applications, only of "your data" (since, as you say, the apps are being turned into symbolic references to ITMS CDN objects.) I don't know if Apple wants to have more caveats to their privacy story at this point. I suspect the best system would be the hash-encrypt-hash of Freenet, at which point the privacy leak would be in the downloading/leasing of blocks of identified material - e.g. if someone was upset about a particular app being pirated they could still court-order ask apple for information on which devices were backing that object up.