3 ms·

> So why not macOS backups in iCloud? If anything, you'd expect it to be the other way around—in iOS devices, you/apps can't litter your homedir with random gar

by dwaite 5y ago

> So why not macOS backups in iCloud? If anything, you'd expect it to be the other way around—in iOS devices, you/apps can't litter your homedir with random garbage, while in macOS you can. So it's more useful to back up macOS. This is somewhat the reason why no full macOS backup to the cloud. iOS naturally normalizes the content due to its use of iTunes Store content (apps, movies, television shows, books, music). On macOS, you can't necessarily just ignore apps and say you'll download from the store - not only can you move applications around, you can delete parts of them and _many_ devices have apps which were not downloaded from the store. So a 1TB Mac backup will take 1TB of iCloud Data and require 1TB of data to be uploaded/downloaded to their storage account. This also affects the speed of restores on higher-speed connections - a lot of the iTunes content winds up being cached by CDNs. Apple's solution so far has been to back up just the user's Documents and Desktop folders to iCloud, since these are the two most important "general purpose" locations on the Mac.

derefr 5y ago
> On macOS, you can't necessarily just ignore apps and say you'll download from the store - not only can you move applications around, you can delete parts of them and _many_ devices have apps which were not downloaded from the store. Sure, but they're by-and-large the same apps. You can delete parts, but the parts that are there will inevitably be parts someone else also uploaded before. Apps are a highly backend de-dup-able kind of data. 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? 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.) So they could have an explicit policy that certain filetypes that aren't "user-generated" would be "backed up in the open, to the commons"; while all other filetypes would get individual treatment. And presumably you could also set some Finder xattr to override that policy one way or the other, if e.g. you had some proprietary binaries you were under NDA to not release.
- dwaite 5y ago
  > Apps are a highly backend de-dup-able kind of data. AFAIK Apple's backup systems do not de-dup data. Backup data is encrypted and that key never touches the data center. Instead, they: 1. de-dup data at the local application layer, such as sharing a common link to an image for photo albums along with the encryption key. 2. de-dup the environment by scripting the reinstallation from their controlled sources (stable CDN links to immutable/integrity protected packages with privilege-reduced installation)
- dwaite 5y ago
  > 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.

by dwaite 5y ago

derefr 5y ago

> On macOS, you can't necessarily just ignore apps and say you'll download from the store - not only can you move applications around, you can delete parts of them and _many_ devices have apps which were not downloaded from the store. Sure, but they're by-and-large the same apps. You can delete parts, but the parts that are there will inevitably be parts someone else also uploaded before. Apps are a highly backend de-dup-able kind of data. 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? 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.) So they could have an explicit policy that certain filetypes that aren't "user-generated" would be "backed up in the open, to the commons"; while all other filetypes would get individual treatment. And presumably you could also set some Finder xattr to override that policy one way or the other, if e.g. you had some proprietary binaries you were under NDA to not release.

dwaite 5y ago
> Apps are a highly backend de-dup-able kind of data. AFAIK Apple's backup systems do not de-dup data. Backup data is encrypted and that key never touches the data center. Instead, they: 1. de-dup data at the local application layer, such as sharing a common link to an image for photo albums along with the encryption key. 2. de-dup the environment by scripting the reinstallation from their controlled sources (stable CDN links to immutable/integrity protected packages with privilege-reduced installation)
dwaite 5y ago
> 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.