Why are you even encrypting? What's the threat model it's protecting against? Clearly it's not "prevent me from reading your data" since you have access to the keys anyway.

KDE Connect sends data directly between your devices, while QuickClip sends data through QuickClip servers using useless encryption.

Privacy minded user : "Eh... what, no."

VC funding surveillance capitalism startups : "Here, take my money!"

/$

They made significant changes to the bootloader with the explicit goal of allowing boot of third-party operating systems.

Unless you can find a way to implement U-Boot on Apple Silicon, they can make more significant changes with no easy opt-out.

If you're new to the topic, this is a good place to start https://support.apple.com/en-lamr/guide/security/welcome/web

This article is definitely the latter, not just "fixing grammar".

The bootloader doesn't even have a USB stack capable of reading external storage.

If you have kernel access you can do an OS-to-OS takeover from the original OS. That's how MkLinux worked on old Macs.

Or you can just sign your Linux kernel from macOS recovery mode, which is what the Asahi Linux installer does already. No need for weird hacks.

You also don't have "kernel access" in macOS. After boot, the memory region corresponding to the macOS kernel is marked as read-only at the memory controller level.

> Or you can just sign your Linux kernel from macOS recovery mode, which is what the Asahi Linux installer does already. No need for weird hacks.

Does that work for USB boot?

> You also don't have "kernel access" in macOS. After boot, the memory region corresponding to the macOS kernel is marked as read-only at the memory controller level.

You can turn that off from recovery mode. (see `bputil`) It's needed to use dtrace.

And then the author posts it himself to Hacker News. Nah, that's not opsec.

There's many factual errors in this AI slop.

For example, it says quite unambiguously that the bootloader is encrypted directly with the GID key (loading the LLB ciphertext into the AES engine), but that's not how it works, the GID key is used to decrypt the LLB's KBAG into an AES key:IV pair and that is used to decrypt the LLB.

More:

> The behavior of the Boot ROM changes fundamentally based on the "Security Domain" fuse. > > Production (CPFM 01):

Security Domain (SDOM) is a different thing than CPFM. And production devices have CPFM 03.

> CHIP (Chip ID): Identifies the SoC model (e.g., 0x8101 for M1).

The M1 SoC is 0x8103.

Due to Brandolini's Law I will not continue to list everything else that is wrong here...

They just fixed the KBAG thing.

This quickly went from Brandolini's Law to Cunningham's Law. Learn how Apple's boot process works by explaining it wrong and waiting for people to correct you!

All of these errors have now been stealth-corrected.

New strategy discovered: Ask LLM to write article, nerdsnipe HN into correcting it, feed corrections back into LLM until people stop complaining

Yeah, definitely not at all a fan of stealth editing.

I suspected LLM rewriting or generation but I don't possess enough knowledge into how the Apple pre-boot environment works to make an accurate judgement on the accuracy of the post. But I definitely had very strong suspicions of LLM influence with all the bullet lists and hem-hawing the post does; I would expect that someone who successfully reverse engineered the boot chain this thoroughly wouldn't need to hedge anything but Apple's rationale on why they did things. But maybe I'm too overly focused on details.

That's exactly how LLMs are so effective: the text looks impressive to people who don't possess enough knowledge to make an accurate judgement. Meanwhile actual researchers with Apple experience found clear errors on a quick skim.

The large amount of rewriting being done within 5 minutes is another sign of LLM...

Can you recommend a more factual and complete overview on Apple security architecture and bootchain than this bug-ridden article? I'm interested in hardware security (models).

Or maybe fully AI-generated. There's many factual errors in the article too.

DigitalOcean lost some of my files in their object storage too: https://status.digitalocean.com/incidents/tmnyhddpkyvf

Using a commercial provider is not a guarantee.

DO Spaces, for at least a year after launch, had no durability guarantees whatsoever. Perhaps they do now, but I wouldn’t compare DO in any meaningful way to S3, which has crazy high durability guarantees as well as competent engineering effort expended on designing and validating that durability.