Well, that's kind of the point.
> You just have to be damn sure that you back it up correctly.
Exactly. And that's as easy as plugging in an external hard drive occasionally, or storing critical files in the cloud.
>Well, that's kind of the point.
Not that I don't appreciate a security-minded platform, it just seems overkill for 99% of the people who'll purchase them, and do nothing but cause heartache when the internal SSD fails. And fail they do. it's rare, but I've had several SSDs (Toshiba and Crucial, if it matters) fail within 1-2 years of moderate usage. No warning there was an issue, the drives just disappeared one day and I was left looking for backups.
I think you underestimate this number. Most businesses are going to want security/encryption over ability to recover data to prevent leaking secrets in the case of a lost/stolen laptop.
as for everyone else, backups really need to become the norm for everyone because as you say any HDD/SSD can fail for any reason anytime beyond any possible recovery apple laptop or not.
No man is an island. If my mom is insecure, then all the messages I sent her are leaked, too, no matter how secure I try to be. If my boss is insecure, then I'm even worse off than that.
Also, if high-security stuff is normalized, then you don't wind up stuck in a place where you have to choose between "the secure option" and "the option that can actually run the apps I need." E2E encrypting the whole world is also the best defense against the government passing laws that make E2E encryption illegal.
The government doesn't need to pass laws to ban encryption (at least in America) since they design the encryption standards themselves. It's basically common knowledge at this point that everything NIST cranks out is vulnerable to differential cryptanalysis beyond the domain of public understanding. Apple, Google, Facebook and the other top dogs all help create the illusion of choice in exchange for keeping the SEC off their backs.
What is asserted without evidence can be dismissed without evidence.
And what's really annoying is that you are doing a bad job of arguing for a position that I actually kinda agree with. NIST has published a backdoored elliptic curve-based RNG[1]; don't trust them. Encryption algorithms need some sort of verifiable provenance for where those numbers came from.
There are many places in the world where information on your laptop even criticising the government can end up in you going missing e.g. China, Hong Kong, Saudi Arabia, Myanmar etc.
It took about 12 hours to decrypt it, and restore sanity.
Availability is part of security, if it's encrypted, and you don't (or can't) boot just the way Microsoft wants, all your data is gone.
Being able to yoink the SSD from the original machine, plug it into another compatible one, and decrypt the contents with your password, is not a vulnerability, it's a feature.
I mean, why even encrypt it in that case?
It’s not like the drive is a web service that will detect and block your password attempts…
Or, well, fine, let there be an active element. But let me export the master key then. It's my device, I have root access to it, I should be allowed to do that. And, yes, do still put the SSD into a slot.
> I mean, why even encrypt it in that case?
Yeah because your time machine backup drive that's encrypted with "just" a password (you did encrypt it, right?) is somehow more secure than an internal SSD encrypted in the same exact way.
You can do this encryption shindig with the ability to export by not using FileVault and using your own encryption software - Apple just doesn't allow this by default. In fact, why only store it on the computer? Rclone can upload and replicate an encrypted (via a long salt + password) copy of your data to dozens of cloud providers. Your encrypted data could be on 3 cloud providers in 10 physically separate locations on 30 different hard drives at once, possibly even in separate hemispheres. Or chuck it into S3 replication and be in all 81 availability zones if you so wish.
I don’t think you grasp how the encryption keys are generated, derived, and stored.
And I doubt you are using a password the length of the key. Well, maybe you create a USB human interface device that fits on your keyring to type it for you. I do have something like that for one time codes, but if that is your sophistication level, then we wouldn’t have this discussion really.
I feel for the “it’s mine, I bought it” logic, and I miss the days when our rights were more absolute. But that’s not today.
> I don’t think you grasp how the encryption keys are generated, derived, and stored.
And you're wrong.
And if it is encrypted with a secret with sufficient entropy, then making your hardware design non-repairable serves no reasonable purpose.
> Well, that's kind of the point.
Great; how do we opt out?
It has advantages and disadvantages. The disadvantage is obvious: few options. But the advantage is that they can make a consistent ecosystem, with sensible choices, and not dragged down by compatibility issues. It "just works". Not my thing but I totally understand those who love Apple.
The way you do recovery with Apple is via Time Machine backups, use that.
Desktop Linux is the opposite, lots of options, but perhaps because of it, it doesn't have the same polish as Apple, and even Microsoft products, or, using your words "it is annoying".
/s
That combination has broken just about every modern cloud backup application I've tried to use over the ~10 years that meets a short list of minimal features I require (locally stored encryption keys for one). It actually breaks $OTHERBIGVENDOR in its default configuration as well, but I've collected a pile of tweaks/etc that keep it functional although I've managed at one point to cause my account to go into a reindexing mode on the servers that didn't complete for months too.
So, maybe at some point. I've got some experience in the space :) and I've considered writing my own when I eventually give up on $OTHERBIGVENDOR. So many of them are written in "modern" languages and the clients are outrageously slow, or get exponentially slower as the data set grows.
I've looked at tarsnap in passing in the past, but haven't gotten around to trying it because from their description of what appears to be a traditional referenced counted global dedupe. I suspected it of having problems when the hash map need to track 50T+ unique hashes from all those video files across backups.
PS: That doesn't mean there aren't good tools, my local backups are via rsnapshot to an offline USB+RAID I plug in once in a while.
Not security. There is no additional security here
You can't just physically remove the SSD from the machine, place it in another and brute force the encryption.
It's another story, a part of the encryption is stored in yet another place on Macs, which it'd be still stored there if the SSD could be moved in/out.
There was another simple option. You're free to use that one.