@alecmuffett On devices where updates bring antifeatures (e.g printers newly banning 3ed party ink) people have long known to block updates.

Under these scenarios, you get a known good snapshot OS and KEEP IT. If the device cannot be defended against hackers except by periodic factory reset, stop using it for shopping, banking, or secure communication.

@LukefromDC
The problem is that Apple is between a hard place and bad place.

They literally brag how they their platform under their thumb. So whenever little fascist states decide upon stupid ideas they need to implement, it's the China CCP scenario again and again: Apple needs to deliver and deliver promptly.

And because they have their platform nailed down like that, it's just a question of time till they'll start forcing upgrades on devices that are "not legal".

@alecmuffett

@LukefromDC
The reality bad part of the "force device manufacturers to break devices by law" is that the different jurisdictions can potentially force manufacturers to change their designs globally.

So then to end up with devices and software being shipped with hundreds of binary blobs for "age verification", "id checking" provided by authorities dormant. Absolutely brilliant from an ItSec perspective.

Trust us that age verification module from @alecmuffett

the Peoples Republic of North Korea is totally benign, and there is absolutely no legal reason it should not be sitting dormant on the secure mobile phone that President of the United States uses.

Oh sure it's loaded only once during initialisation like all the others to query it off it recognizes itself relevant for the locale.

Totally benign and harmless.

But unused shared libraries are additional attack surface for exploits.
@alecmuffett @LukefromDC

@yacc143 @LukefromDC

As I wrote previously on another website:

@alecmuffett @yacc143 This actually goes all the way back to the MS "Palladium" proposals for locked computing circa 2004, which came complete with failed proposals before Congre$$ to ban unlocked/older computers from the Internet.

MS ran into a problem: an internal document revealed a plan to first lock law firms to MS Office by changing the file format to an encrypted proprietary one, then making MS office subscription-only. This was way, way before Office 365 keep in mind. It blew up in their face, because the basic idea was to hold all files at law firms hostage for presumably very high subscription fees.

Secure boot was a limited implementation of Palladium, but with the antitrust law of that time we forced MS to require that "windows certified" x86 computers must be able to unlock the bootloader and we also got the ability to enroll user-generated keys. Some but not all phones (a decreasing percentage) also got this.

Pixels did-and the reason it is hard for cops to modify a captured Graphene phone they capture to log and report a passphrase or boot into an OS they control is the use of secure boot with Graphene's own keys. Secret Service and NSA are presumed to have Google's keys, but Google's keys cannot unlock Graphene.

The normal rule remains however that possession=root, and any device that has been unsupervised in enemy cannot be trusted for wartime or "felony level" purposes. I have destroyed such phones myself.

Suppose that F15 pilot shot down over Iran today was carrying a Graphene phone and it landed undamaged in the bushes.Suppose Iran returned it to the USAF? Would anyone in the Air Force not appoinrted by Trump be dumb enough to boot it?

They'd probably get away with it short of an exploit against the TPM itself, but the risk would still be there. ANY other phone, forget about it: unlocking it would also be presumed to unlock the copy of the filesystem held by the adversary that "returned" the phone.