What the... I was under the impression that iCloud backups are end-to-end encrypted. This is a HUGE problem.
The borg website is here:
https://borgbackup.readthedocs.io/en/stable/
and a good description of how it works and why you should use it is here:
Quickly looking at Borg's website (thanks for the heads up - great tool/option) I see it doesn't support iOS or backing up an iOS device.
I assume you're just suggesting it as a general purpose option for general backups on the desktop?
I wonder how efficient Borg would be with this setup.
One thing that irks me about these solutions is that they seem to scan my folders each time they want to backup. Are there tools that are smarter about this? For e.g., while running, they could keep a log of what's changing and only scan those while backing up.
I may have looked at Duplicacy. I'm sure that I looked at one of Duplicacy [1], Duplicati [2], and Duplicity [3]. Whichever one that was, I kept getting it mixed up with the other two when looking for information online, and finally said "screw this" and bought Arq.
I've used it on my macs for years without any issues at all. I switched after Time Machine broke down for the n'th time in a month saying it needed to recreate the backup, and not once in the 3-5 years i've been using it has it every given me any problems with broken repositories, and every integrity check/restore has succeeded.
Arq on Windows is a different beast though. I'm sure it's technically solid, but the UI leaves a lot to be desired. On windows boxes i default to Duplicaty.
Did you mean Duplicacy or Duplicati?
On my servers i use Borg like any sane person would, but the lack of a good client UI makes scheduling backups on a personal computer a lot more work than i'm willing to put in.
I've found arq backup overall slow once you start hitting 0.5TB overall. It's a design issue.
I believe most operating systems have a mechanism for this. E.g. on macOS it's called fsevents, Linux has inotify
For linux servers, borg is great, and me and my companies are happy users.
Rclone simply copies data. If you `sync` `~/Documents` to your remote it will keep an exact copy.
This is a simple backup since you only have one version. Anything deleted, the next time it syncs, gets deleted.
Borg is a backup tool. Versioning is at its core. It does that efficiently by deduplicating file (chunks really) even if they’re not in the same location.
So with Borg, if you create a backup 1 of `~/Documents` today and a backup 2 tomorrow of `~/Documents` you can see both backups and work with each snapshot. The size it takes should be close to the amount of data changed in the whole source.
If you move directories or files inside, rclone has to reupload them. Borg detects but doesn’t have to store it again.
With rclone some remotes have versioning (Google Drive, Dropbox). This could help in this case, but it depends on the remote. With Borg this is built in and you can change the underlying storage and migrate without loosing any data. Using versioning with crypt would probably be a pain too due to the file names. Not sure if rclone has commands/flags to help with this that I simply don’t know about.
...
"This is a simple backup since you only have one version. Anything deleted, the next time it syncs, gets deleted."
This is correct. It is widely advised to not consider a "sync" like this a proper backup.
However, for what it's worth, rsync.net does support rclone[1] and because of the ZFS snapshots that are created and maintained[2] in your account, you can just do a dumb sync because the retention is handled by the snapshots.
I am not sure if rclone is really the right tool for plain old cloud backups - I think rclone distinguishes itself for the ability to transfer data between cloud providers.[3]
[1] https://rsync.net/products/rclone.html
[2] ZFS snapshots reside in the .zfs/snapshot directory inside your rsync.net account.
[3] ssh user@rsync.net rclone file/in/rsync/net/account s3:/some/bucket
As Mark Zuckerberg once opined: “They ‘trust’ me. Those dumbfucks.”
https://www.businessinsider.com/embarrassing-and-damaging-zu...
And it’s not just mere words, here is he actually set up a honeypot site to get people’s passwords and break into their emails to satisfy his burning curiosity when he first launched Facebook:
https://www.businessinsider.com/how-mark-zuckerberg-hacked-i...
Instead, he decided to access the email accounts of Crimson editors and review their emails. How did he do this? Here's how Mark described his hack to a friend:
Mark used his site, TheFacebook.com, to look up members of the site who identified themselves as members of the Crimson. Then he examined a log of failed logins to see if any of the Crimson members had ever entered an incorrect password into TheFacebook.com. If the cases in which they had entered failed logins, Mark tried to use them to access the Crimson members' Harvard email accounts. He successfully accessed two of them.
In other words, Mark appears to have used private login data from TheFacebook to hack into the separate email accounts of some TheFacebook users.
In a world where we are sending our Alexa data to “the cloud” and the companies are admitting people are listening to it, in a world where Facebook secretly records everything it can, why would you assume your password isn’t being sent?
To the downvoters... you may say that this was only when Mark Z was a young man and now Facebook the company is far more responsible. But then we have this from just a few months ago:
https://www.independent.co.uk/life-style/gadgets-and-tech/ne...
I can understand trusting a browser or a software release that can be tested by many people, and was signed with a checksum. But a website and all your extensions on every website?? Those can ship new code at any time.
(Am I wrong? Any counter-arguments?)
iCloud backups always were encrypted based on a key derived from your iCloud account credentials, since the beginning...
Optionally encrypted: https://support.apple.com/sl-si/HT205220
FileVault too is optional: https://support.apple.com/en-us/HT204837
First party backups from Apple (iCloud/iTunes) restore a perfect replica of the phone, including app icon locations, arrangement, notifications, offloaded storage etc. I'm honestly skeptical that anyone else would be able to pull that off.
Yes, Apple has private APIs that it uses for its monopoly abuse benefit. That is why Apple's "Music" app can't be deleted from your computer ("'Music.app' can’t be modified or deleted because it’s required by macOS.") but Spotify can be deleted.
The solution is for Spotify to sue them on this specific issue and for other people to sue them similarly.
Edit: or since it is "derived" and not really password which is used for encryption -- the derived thing could well be the hashed password. We are doomed. They might as well serial number their user and use that as key then. Never mind.
Does that clear it up at all?
FYI these concepts are originated from military crypto. The foundations are solid. Implementation... well you know how that always is.... one CVE away from perfect!!
But of course, we are talking about local backups so if you have full-disk encryption or back them up to an encrypted virtual drive, you don't even need whatever encryption comes with them.
Also, all your photos and notes and email and other stuff in iCloud are available to Apple (and by extension the FBI et al) as well. Even Apple CSRs have a ton of access to the contents of a lot of iCloud services.
The situation is a lot better if you have all recent devices and 2FA turned on, then it can use iCloud Keychain for some stuff which is trust-circle based. You can read more in Apple’s latest platform security doc released late last year.
To answer your question directly. TLS encryption from your phone to apple's servers means they terminate encryption at the other end when they receive your data. This means "they decrypt the information that was in transit". Then they explicitly apply another encryption to the received and decrypted data before storing it on disk. Since these are two separate steps, you have no protection what-so-ever since apple will have a registry of all decryption keys for the disk backups that they'll happily use for whatever reason when they want to get hold of your data.
The only thing their disk encryption protects against is if someone were to walk away with the physical disks. It protects squat against the threats customers actually care about (unauthorized access to the data by someone other than the customer owning that data).
And seeing as they run on AWS, physical security means that the only way metal leaves the data center is if it's in millimeter sized shredded metal grain. So the threat model of concern here is exactly what apple has decided not to provide customers any protection against.
So claims of "encryption" are meaningless.
Instead, claims of "only X, Y and Z could access to this" are meaningful.
"Could" is a strong word because it includes unforeseen circumstances such as writs and court orders.
~/Library/Application Support/MobileSync/Backup
Since we hold the key it's a blob nobody can get to without brute forcing it.
https://techcrunch.com/2018/07/17/apples-icloud-user-data-in...
I don't think the general public would understand end-to-end encrypted backups. It would probably hurt their company if all backups were totally unrecoverable.
I imagine you're right; it would still be nice for individuals and organizations to have the _option_ though.
You can’t even turn off the backup password on an existing device for a new backup without knowing the old password (protecting against Evil Maid problem).
I’ve had to reset a device when I forgot my local iPhone backup password to get it back to unencrypted backups.
I had in mind an e2e encrypted backup on Apple's servers, which would be far more convenient than doing it locally. That's all.
> More than two years ago, Apple told the FBI that it planned to offer users end-to-end encryption when storing their phone data on iCloud, according to one current and three former FBI officials and one current and one former Apple employee.
> Under that plan, primarily designed to thwart hackers, Apple would no longer have a key to unlock the encrypted data, meaning it would not be able to turn material over to authorities in a readable form even under court order.
https://www.alexa.com/siteinfo/mega.nz
https://play.google.com/store/apps/details?id=mega.privacy.a...
What did suck on Apple's part was that they wouldn't allow you to disconnect the actually end-to-end encrypted iMessages from the iCloud backups for many years.
So since most people kept their iCloud enabled, that meant their "iMessage end-to-end encryption" was nothing of the sort, as all messages had a copy that Apple could read on its servers.
I actually don't know if this is still true since I haven't used an iPhone in some time, but I sure hope it isn't anymore.
But this makes me wonder if they have our local boxes totally owned already which is why the local encrypt feature would not hamper investigations?
Well, you can choose not to use iCloud for that reason (as some of us do).
A bigger problem is that Apple deliberately locks up iDevices so it's hard to get your data off them using only local means, particularly if you don't also want to buy an Apple laptop just to do it.
Let me know when iPhones and iPads support standard plug and play protocols that work universally without relying on either Apple's proprietary and frequently broken software or someone else's commercial alternative that attempts to do what Apple should have been doing all along.
iTunes hasn’t worked well on any platform in over a decade.
What other devices perform all of the backup, restore, and os upgrade, functionality of iTunes.
The iPhone doesn’t use the standard “usb mass storage” protocol to allow you to download pictures. It uses the picture transfer protocol.
I've never claimed anything about any other functions of iTunes. I just said it was a problem that Apple devices make it difficult to get your data off using only local transfer.
The iPhone doesn’t use the standard “usb mass storage” protocol to allow you to download pictures. It uses the picture transfer protocol.
Yes, exactly like your camera, as I said.
We already have a good, properly secured backup system that we use for all our workstations and servers. We just want to be able to export data from any mobile devices we use and manage that data using the same policies and tools. In most cases, that is straightforward. The one big exception is the iOS devices.
And this is the same myopic geek viewpoint that came out with the iPod “Less space than the Nomad. No wireless lame.”
Do you actually believe that most people have a good backup solution at all? Is that really what you are suggesting for a general backup solution?
That’s just like when DropBox was introduced and people on HN came up with a convoluted Rube Goldberg solution that they could do themselves.
I'm saying that iCloud isn't properly encrypted, which for some people and organisations will be a problem, and that it is then a greater problem for those people and organisations that it is unusually difficult to transfer data between iOS devices and other systems through other means because of the inhibiting choices that Apple has made.
It's much like the argument that the default behaviour for consumer software should normally be to install security updates automatically, but installation of updates should still be configurable for those who do know what they're doing and need more control over their systems.
I doubt many businesses are using iWorks with iCloud.