In practice, exhausting NAND write endurance is usually not what causes SSDs to fail in the field. It is especially unlikely to be the underlying cause of unexpected and seemingly premature catastrophic SSD failure.
Also, it is not possible for an SSD to decrease your usable storage space over time. That would break any partition table format or filesystem that expects an ordinary block device. It also wouldn't win you any significant increase unusable lifespan, because when your drive starts retiring large numbers of blocks, all of your blocks are on the verge of failure. (Though keep in mind that "failure" here is defined as "only able to retain data for one year" for consumer SSDs).
> It is especially unlikely to be the underlying cause of unexpected and seemingly premature catastrophic SSD failure.
One of my graduate students experienced this, the hard way: writing up his thesis, his mum plugged in "the wrong USB C" charger. I don't know exactly what happened, but the board was utterly fried. The problem with the soldered-to-the-motherboard, everything-utterly-encrypted approach is that it's almost impossible to do data recovery. On the M1+ models, you literally can't do anything except semi-fix the motherboard as the flash and its controllers are integrated and the keys are cryptographically securely stored. This video [1] shows what data recovery is really like -- I don't often link to YT videos, but it is an hour long, involves an awful lot of BGA de-balling and re-balling and the scouring of spare chips from other donor dead machines, as Apple doesn't let manufacturers sell the chips separately and datasheets are all NDA'd.
We're very much in the part of the curve where you'd need a lab and a lot of serious work to get data off these things without either sacrificial macs or luck (e.g. one blow voltage regulator). Of course, the flip side of this is that your data is really, really secure. You just have to be damn sure that you back it up correctly.
I work for my university's helpdesk and a lot of students learn this the hard way every day. We always require users to assume full risk of data loss whenever they check in for a repair. For most computers, if they aren't okay with that, we can just tell them to go to a third party shop and have the drive pulled out and imaged first. For recent Macs we basically just have to tell them it's gone for good if we can't get the machine booting without having to swap the system board.
>> soldered-to-the-motherboard, everything-utterly-encrypted approach is that it's almost impossible to do data recovery
>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.
> Not that I don't appreciate a security-minded platform, it just seems overkill for 99% of the people who'll purchase them
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.
>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.
On that note, it's unfortunate that T2 can only create ecdsa-sha2-nistp256 secret keys. Right now I use Secretive but I might resort to a different utility that generates ed25519 and stores it within keychain, if there is one.
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.
I recently learned that my hard drive was encrypted with Bitlocker, had I not been attempting to get Genode running off a USB stick, I might have gone on for a year or to in blissful ignorance of how remarkable insecure my stuff was as a result of this.
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.
> it just seems overkill for 99% of the people who'll purchase them
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.
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.
No it's not a joke. If the password is sufficiently complex, it can't be brute forced in a reasonable amount of time. But it's still a way for you to get your data back having only the SSD on which it is stored.
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 mean, just turn off encryption if that’s what you want.
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.
There are key-derivation functions like PBKDF2 that are computationally expensive enough that it would make brute-forcing infeasible at best and impossible at worst. Perhaps only if your password is 1234 or qwerty, but even then it would take literal years.
> I don’t think you grasp how the encryption keys are generated, derived, and stored.
If data is not encrypted with a piece of secret information (usually a password) with enough entropy to keep it secret in the face of offline attacks, then it is as good as not encrypted, period. The hope that your hardware design is sufficiently complex and non-repairable to prevent your attacker from disassembling it and performing such an attack is not a replacement for proper encryption.
And if it is encrypted with a secret with sufficient entropy, then making your hardware design non-repairable serves no reasonable purpose.
You can easily limit password attempts by requiring a sufficiently difficult password hashing algorithm and then just use a secure passphrase. Nobody is breaking into my encrypted drives via a guessing attack (other attacks exist, but they ~all also exist on macs).
Encryption is based on math, not on some hardware gimmick. I'd absolutely clone my laptop drive and move it to a new one if I want to, having exactly the same setup.
Apple is not about giving you options. Either you go the Apple way or you leave the ecosystem entirely, and except for the very beginning when Steve Wozniak still had some influence, Apple has always been like that.
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".
That really just shows that everything has tradeoffs. I'd Love if Windows could run on top of the Linux kernel (as in, nvidia drivers and all the Windows compatibility while being able to do stuff like `lspci` to see my real hardware - WSL2 doesn't do full PCI device passthrough yet) but that's unlikely to happen with how much the Windows team is seemingly trying to simplify their testing infrastructure (removing CPU support and removing user choice).
Thanks, I don't remember trying tarsnap. I use $OTHERBIGVENDOR and its been sticky, because I have ~60T of large files (miniDV .mpg captures/4k video/etc) mixed with an insane number of .5k files from git repos/etc.
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.
of course you can desolder and move the chips - all you need is a hot air station and some flux. It's of course harder but nothing even remotely close to breaking the encryption itself, like orders of magnitude easier - any hobbist can do it.
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.
> or storing critical files in the cloud.
No. I refuse to let my vacation photos, hard drive images or hell, even my wallpaper collection to leave my house.
No. I refuse. My data is my data.
Encrypt it? There are some strong algorithms that allow you to enjoy the most highly secured, fault-resistant buildings on earth without letting the capitalists that own them view your data even if they were to hook your storage up to their entire GPU/ASIC/etc farm.
I don't know about the mac, but I tried to do this for the wife/kids i-devices, and it was an utter failure. 3rd party backup apps are at a huge disadvantage on ios because apparently they can't run in the background long enough to keep things synced unless they also require _GPS_ service notifications (or at least that is how the nextcloud app works around it). Which in turn eats even more battery to work around ios's inability to flag apps as trusted system services and provide extra warnings/whatever during install (or app store acceptance might be a better plan).
If you seriously consider a state actor to be a threat, then you likely make many other compromises to your ability to conveniently perform disaster recovery.
There is not much overlap between these use-cases:
* I need an easy way to recover my family pictures because I didn't make backups
and
* I have state actors interested in my data
If you really have state actor threats, you probably like that M1 Macs are very hard to perform data-recovery from.
If you are a state actor you probably love M1 Macs.
You literally can't restore them without phoning home.
Everone should consider state actors as a threat because they are. They maybe are not specifically after you. But every now and then some big box gets popped leaking all kinds of personal information (including yours) and the actors are probably state sponsored. Also it is not state actors scanning your data, many cloud providers do so.
If you have a state actor as threat model you probably want to remove iCloud backups (see link):
"Apple’s iCloud, on the other hand, can be searched in secret. In the first half of last year, the period covered by Apple’s most recent semiannual transparency report on requests for data it receives from government agencies, U.S. authorities armed with regular court papers asked for and obtained full device backups or other iCloud content in 1,568 cases, covering about 6,000 accounts."
Your concerns are not unfounded, but there is a very significant functional difference between being generally concerned about data privacy posed by any third-party bad actor, and having a threat profile that includes specific state actor threats.
If you think it is a realistic scenario that the US would serve a warrant against you, then yes, your iCloud backup will probably be disclosed to the authorities. But if this is a real concern of yours, then you probably have much bigger things to worry about than whether your SSD is soldered to the board or not.
It feels like you're using "state actor" as a motte and bailey. It usually means targeted espionage affecting very few, with strong motives for why security services are interested in them specifically. Whereas that article is ultimately talking about a dragnet surveillance system, which is technically a state actor but affects literally everyone.
Using your loose definition of "state actor" means that every single person who uses mainstream cloud solutions has "state actor" as a threat, whether they acknowledge it or not. It's not just the occasional person super focused on security as you're making it out to be - in fact people less in touch with security have a larger threat from their system being hijacked and used to distribute contraband bits, thereby running afoul of cloud scanning.
No it doesn't mean that, because threat assessments consist of multiple variables, including the footprint, probability, and impact of a potential threat.
No it's not. Consider the risk that a street criminal could throw a rock through my window and steal my computer off of my desk. Do I put bars on my window? No. Why? Because I have nothing to hide? No, because I don't consider that attack vector to be a high enough priority that I need to take steps to mitigate it.
Threat assessments are purely an engineering exercise. This is orthogonal to the ethical, philosophical, and political discussion of civil liberties. If you have ethical, philosophical, or political concerns about this topic, those are something to be addressed in their respective realms. It is naïve to believe that engineers have power to protect anyone from abuses of civil liberties. Apple hardware engineering team is neither capable nor equipped to be addressing these concerns in their designs.
That’s fair but if someone is concerned about it they should invest into backups. It’s unconscionable to entrust days of someone’s work to a single device.
Seriously. It's 2021, you should have a remote backup. Use backblaze, tarsnap, anything. SSD failure is one of a thousand ways you can lose access to files on your laptop.
You always do backup (another hard drive), GitHub (these days free private repro), Dropbox, iCloud, … etc. Totslly rely upon a hard disk … a big lesson to learn.
> Also, it is not possible for an SSD to decrease your usable storage space over time.
It totally could be possible. For Windows/Linux, you could have a daemon that creates a 'ssd_wear' file which grows in size as the SSD wears out, and messages to the SSD which physical blocks it occupies. Mac could obviously do a deeper integration directly into the OS.
> all of your blocks are on the verge of failure
A failed block still stores some information (in an information entropy sense). It's totally possible to store one blocks worth of information across two, four, or eight failed blocks (with extra error correction information).
Combining these two techniques, an SSD should never fail. Instead it slows down and gets smaller. Sadly as far as I'm aware, no consumer drive vendor has implemented these.
You should read up on Zoned Storage for NVMe SSDs, and some of the more recently added error handling features like Get LBA Status. The gist is that it is only practical for the SSD to be in charge of determining what has failed-not the host, and that retrofitting NAND retirement into the traditional block device/LBA model is not worth the trouble when there are also other reasons to migrate to a different, more flash-friendly abstraction.
I used to work on SSD firmware. I did implement something like the above for a custom solution for caching. When the flash storage is running low on space, it reduced the reported storage capacity and notifies the host which will need to trim some data to bring it below the reported storage capacity. The striping of data across multiple blocks also has been implemented. You could fail an entire NAND die and it would still function though a little slower assuming you still have enough spare blocks.
>> It also wouldn't win you any significant increase unusable lifespan, because when your drive starts retiring large numbers of blocks, all of your blocks are on the verge of failure.
That's not true. Blocks degrade when written to. Most files are written once and read many times.
You're forgetting that SSDs use virtual addressing so writes are distributed relatively equally over the whole drive. Even data that is written once and never changed logically will probably move around on the SSD due to garbage collection. The virtualization algorithms are kept relatively secret, but I assume good SSDs will move full unchanged blocks around occasionally to distribute write load more equally on the physical blocks.
Yep, wear leveling actually works. On some SSDs, there are SMART indicators to tell you the average, max and min block erase counts, so you can see for yourself that the erase counts are all about the same across the entire drive.
>> I assume good SSDs will move full unchanged blocks around occasionally to distribute write load more equally on the physical blocks.
I hadn't considered that. Make sense. Better to move never-changing data to blocks that are still good but not worn out so those available writes can be utilized.
> Though keep in mind that "failure" here is defined as "only able to retain data for one year" for consumer SSDs
So the M1 Mac lasts a year before the owner has to shell for an apple authorised repair to replace the disk ?
Me thinks that may not be the story for apple or dell
Do you have a point? Linking to a story about an embedded system that experiences flash wearout is not really relevant here. You're trying to make a comparison against a far smaller and lower-quality storage module than typical consumer SSDs, subjected to a vastly different workload. There are no useful conclusions to draw about consumer PCs from that case.
Also, it is not possible for an SSD to decrease your usable storage space over time. That would break any partition table format or filesystem that expects an ordinary block device. It also wouldn't win you any significant increase unusable lifespan, because when your drive starts retiring large numbers of blocks, all of your blocks are on the verge of failure. (Though keep in mind that "failure" here is defined as "only able to retain data for one year" for consumer SSDs).