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).
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.
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.
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.
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.
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.
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.
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.
Most somewhat serious NAS appliances offer being a TimeMachine server which is more than enough for most people.
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.
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."
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.
Whether you consider those actions to be a threat would depend on an individual person's or organization's assessment of the impact of those actions.
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.
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.
That's not true. Blocks degrade when written to. Most files are written once and read many times.
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.
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
What am I missing
+1. The part that fails on consumer SSDs is typically the controller.
Actually, even more than that - here are some examples:[1]
Intel SSDSC2KB019TZ01 ("S4520") with 8.8 PB of lifetime writes
Intel SSDSC2KB019T801 ("S4510") with 7.1 PB of lifetime writes
Seagate ZA1920NM10001 ("Ironwolf[2] 110") with 3.5 PB of lifetime writes [2]
Samsung MZ-76P2T0BW ("860 PRO") with 2.4 PB of lifetime writes
[1] https://www.rsync.net/resources/notes/2021-q3-rsync.net_tech...
SSD wrote endurance is an unavoidable ticking time bomb. But it is nowhere near as unpredictable or imminent as many people assume. It's a failure mode that doesn't sneak up on you, and usually takes real effort to trigger. Other failure mechanisms are much more important.
Granted, been a while, but I do nightly full-disk backups due to the first such experience (so was well prepared for the second).
In general, you should be aware that the "life remaining" indicator may merely be the "warranty remaining" indicator. If the unused reserved block count isn't approaching zero, a drive can usually keep operating long past the official write endurance rating. However, in addition to the above bug, Intel is also known for putting a kill switch in their SSD firmware tied to the "life remaining" counter, so you might have actually experienced the SSD going read-only when that hits zero.
8 Gb should be enough for everyone :)
You can't wear-level against blocks that are in use, only blocks that are free.
If every person I've helped socially and professionally is any indication, people keep their storage anywhere between 80% and 95% full.
At 95% full, all your write cycles are focused on just 5% (plus spare provisioned blocks.)
Think about how browsers consume all available memory and then readily push the system into using a lot of swap. I have to restart my browser regularly because of how much ram it uses even if I've closed every tab.
Think about how whole-system file content indexing is the norm, and all the write operations that occur every time a file is added or updated.
Think about how a lot of applications are just electron apps and they routinely update themselves.
Think about all the filesystem metadata changes.
Etc.
It only takes a bit of arithmetic to prove that this cannot possibly be true, or else all of those 95%-full drives would have long since failed, and QLC SSDs would have been a disaster and never would have been adopted by system OEMs that provide multi-year warranties. (And if it were true, then SSDs prior to TRIM wouldn't have been viable.)
You can include static data in wear leveling, and all SSDs do. It does lead to some write amplification, but that's already factored in to a drive's endurance specs.
Failure rate was much less than enterprise spinning disks, but at least with the spinners failed, you could still see them and get most of the data off, if you needed to. And they had reliable pre-failure indications.
TLDR: take regular backups and plan for storage to fail (which for soldered storage means plan to get a new device, I guess)
Particularly for "enterprise" equipment the expectations isn't that it fails, but that the failures are more graceful and understood.
So complain... that is why your paying the "enterprise" tax.
Although we did get a couple of bad batches on our single disk systems, almost all of those failed within 2 weeks of install and we had the rest replaced.
I also suspect firmware bugs, but it wasn't convenient to upgrade them, so who knows. I did have to upgrade some of the same disks on single disk systems with low usage; the disks would sometimes timeout for no reason and confuse some of our OSes. The upgrade procedure was more or less PXE boot the manufacturer upgrade utility and hope it worked with whatever disk controller was there (eta: 5 minutes) or let the hoster firmware upgrade script run and hope it upgraded the ssd firmware and didn't mess anything else up (eta: 40 minutes per run, probably run it twice).
SSDs are wear items. Especially when they're quite full, it is very easy to blow through spare writes and brick the drive.
That’s a totally different reason, and afaik, they should be using proper caps to let the controller write/flush their buffers.
My last MacBook Pro was 7 years old, almost always full, and still works fine. Granted I’m not a video editor, but I had quite some write cycles.
Or did the entire module electronically fail, as distinct from the SSD "no more writes" case?
I don’t know how much time do you expect your mac to last, but write cycles on your firmware should not be much of a concern.
Sooo that means the wear leveling had better be ahead of whatever lifetime writes you throw at the system, or...
Except as explained by the parent, when the SSD dies on an Intel Mac it can be recovered via Internet Recovery via EFI.
Only way to brick that it is to have a bad flash onto the EFI ROM.
On Apple Silicon when the SSD dies, it cannot be recovered as the firmware is also on the SSD and remains bricked which that is that.
Because it partly is. It's just a lame defence / justification of soldering SSD, RAM and other parts, the major advantage of which is to make modern electronics more complex, hard to repair and prevent upgrades (i.e. "planned obsolescence"). If SSDs were reliable beyond 5+ years, manufacturers would be highlighting that and even offering guarantees for such a period. (Hell, most RAM today come with "lifetime" guarantees, even though RAM modules too fail occasionally).
The modular design for computer hardware was chosen for a practical reason - that hardware can, and do fail. While electronic manufacturing has advanced a lot, minimizing failure rates to a great extent, the pros of replaceable modules absolutely still outweigh any of the alternative hardware designs so far.
So you can either go modular and have a slow PC, or you can have decent performance and just accept that everything is going to be soldered on and irreplaceable.
Also our PCs are not slow, modular or not. In many cases hardware is not the bottleneck.
Maybe the fan was more of a case fan and it simply ran air through the whole machine INCLUDING the CPU heatsink, which is AFAIK exactly how it worked.
But we do know how far DIMMs can go. Mainboard memory trace layouts have gotten ridiculously optimized. DDR4-5200 is a totally "normal" XMP spec now, there are even 5400 kits out there I think.
This is unsurprising given what I already pointed out about power being more important than maximizing performance. Sure, you can overclock the memory controller on a desktop platform and with sufficiently expensive DIMMs and probably a bit of an overvolt for the memory controller/uncore you can reach higher bus speeds than any laptop CPU (though still not anywhere near as high as GDDR used with high-end mobile GPUs).
But take a look at the fastest memory speeds available through SODIMM slots vs the speed of LPDDR4x supported by the same CPUs. Within the constraints of laptop power levels and using standard grade memory parts rather than requiring premium binned chips, soldering currently corresponds to a 33% performance advantage.
Imagine 8 DIMMs next to each other, and then fitting that into a laptop form factor.
Sorry, but how? That's just reads like BS.
SSDs have limited lifespans due to the limited write cycles of the NAND chips. So no, what damages NAND does not damage the rest of the board. The more you write and swap to flash, the faster it wears out, taking your Macbook down with it when it dies.
Granted, I expect the controller to keep moving your data around to the cells with the least ammount of wear and isolate the ones that have worn out, reducing your storage space and speed of the drive over time.