That was 2024. I wonder what could possibly be different about today, in 2026?

And 20 years ago people were making the exact same kinds of comments and everyone had the same reaction: yeah, MySQL has been putting numbers up like that for a decade.

Even more complications for a “why can’t they just…”. It’s almost as if this kind of thing is difficult to do in practice.

Absolutely every aspect of it?

What’s so hard about adding a feature that effectively makes a single-user device multi-user? Which needs the ability to have plausible deniability for the existence of those other users? Which means that significant amounts of otherwise usable space needs to be inaccessibly set aside for those others users on every device—to retain plausible deniability—despite an insignificant fraction of customers using such a feature?

What could be hard about that?

> despite an insignificant fraction of customers using such a feature?

Isn't that the exact same argument against Lockdown mode? The point isn't that the number of users is small it's that it can significantly help that small set of users, something that Apple clearly does care about.

Lockdown mode costs ~nothing for devices that don't have it enabled. GP is pointing out that the straightforward way to implement this feature would not have that same property.

Lockdown mode doesn’t require everyone else to lose large amounts of usable space on their own devices in order for you to have plausible deniability.

The 'extra users" method may not work in the face of a network investigation or typical file forensics.

Where CAs are concerned, not having the phone image 'cracked' still does not make it safe to use.

Android phones are multi-user, so if they can do it then Apple should be able to.

And how do you explain your 1TB phone that has 2GB of data, but only 700GB free?

The "fake" user/profile should work like a duress pin with addition of deniability. So as soon as you log in to the second profile all the space becomes free. Just by logging in you would delete the encryption key of the other profile. The actual metadata that show what is free or not were encrypted in the locked profile. Now gone.

Good idea, but this is why you image devices.

Sorry I explained it poorly and emphasized the wrong thing.

The way it would work is not active destruction of data just a different view of data that doesn’t include any metadata that is encrypted in second profile.

Data would get overwritten only if you actually start using the fallback profile and populating the "free" space because to that profile all the data blocks are simply unreserved and look like random data.

The profiles basically overlap on the device. If you would try to use them concurrently that would be catastrophic but that is intended because you know not to use the fallback profile, but that information is only in your head and doesn’t get left on the device to be discovered by forensic analysis.

Your main profile knows to avoid overwriting the fallback profile’s data but not the other way around.

But also the point is you can actually log in to the duress profile and use it normally and it wouldn’t look like destruction of evidence which is what current GrapheneOS’s duress pin does.

The main point is logging in to the fake profile does not do anything different from logging in to the main profile. If you image the whole thing and somehow completely bypass secure enclave (but let's assume you can't actually bruteforce the PIN because it's not feasible) then you enter the distress PIN in controlled environment and you look at what writes/reads it does and to where, even then you would not be able to tell you are in the fake profile. Nothing gets deleted eagerly, just the act of logging in is destructive to overlapping profiles. This is the only different thing in the main profile. It know which data belongs to fallback profile and will not allocate anything in those blocks. However it's possible to set up the device without fallback profile so you don't know if you are in the fallback profile or just on device without one set up.

Hopefully I explained it clearly. I haven't seen this idea anywhere else so I would be curious if someone smarter actually tried something like that already.

What you say makes sense, just like the true/veracrypt volume theory. I can't find the head post to my "that's why you image post" but what concerns me is differing profiles may have different network fingerprints. You may need to keep signal and bitlocker on both, EVERYTIME my desktop boots a cloud provider is contacted -- it's not very sanitary?

It"s a hard problem to properly set up even on the user end let alone the developer/engineer side but thank you.

The same way when you buy a brand new phone with 200GB of storage that only has 50GB free on it haha

System files officer ;)

"Idunno copper, I'm a journalist not a geek"

That is about one fiftieth of the work that needs to go into the feature the OP casually “why can’t they just”-ed.

This is called whataboutism. This particular feature aside, sometimes there are very good reasons not to throw the kitchen sink of features at users.

Truecrypt had that a decade+ ago.

Not sure if you know the history behind it, but look up Paul Le Roux

Also would recommend the book called The Mastermind by Evan Ratliff

imo Paul Le Roux has nothing to do with TrueCrypt

He wrote the code base that it is based on in combination with code he stole. The name is also based on an early name he chose for the software.

Whether he was involved in the organization and participated in it, is certainly up for debate, but it's not like he would admit it.

https://en.wikipedia.org/wiki/E4M

Maybe one PIN could cause the device to crash. Devices crash all the time. Maybe the storage is corrupted. It might have even been damaged when it was taken.

This could even be a developer feature accidentally left enabled.

It doesn't seem fundamentally different from a PC having multiple logins that are accessed from different passwords. Hasn't this been a solved problem for decades?

Apple's hardware business model incentivizes only supporting one user per device.

Android has supported multiple users per device for years now.

You can have a multiuser system but that doesn't solve this particular issue. If they log in to what you claim to be your primary account and see browser history that shows you went to msn.com 3 months ago, they aren't going to believe it's the primary account.

My browser history is cleared every time I close it.

It's actually annoying because every site wants to "remember" the browser information, and so I end up with hundreds of browsers "logged in". Or maybe my account was hacked and that's why there's hundreds of browsers logged in.

Multi-user has been solved for decades.

Multi-user that plausibly looks like single-user to three letter agencies?

Not even close.

Doesn't having standard multi-user functionality automatically create the plausible deniability? If they tried so hard to create an artificial plausible deniability that would be more suspicious than normal functionality that just gets used sometimes.

What needs to be plausibly denied is the existence of a second user account, because you're not going to be able to plausibly deny that the account belongs to you when it resides on the phone found in your pocket.

Android has work profiles, so that could be done in Android. iPhone still does not.

What's the risk? On Android, the company can remotely nuke the work profile. The work profile has its own file system and apps. You can turn it off when to don't want work notifications.

you're surprise corporations are cheap

Police ask: give me pass for work profile. If you don’t: prison.

> iPhone and macOS are basically the same product technically

This seems hard to justify. They share a lot of code yes, but many many things are different (meaningfully so, from the perspective of both app developers and users)

The TL;DR is they radiate it into space via large, high surface area arms that stick out of the station.

Claude Code has zero issue using jj, for what it’s worth.

I noticed it get a lot better with the 4.5 models specifically. Before then, I would have to tell Claude "do a web search for the docs for jj, then do XYZ." Now I just tell it to "do XYZ using jj"

do you use it with git worktrees? or how do you handle multiple claudes?

I use jj workspaces, which are pretty similar to git worktrees. But 95% of the time I just use one Claude.

> the human driver would usually drive more closely to the centerline of such a residential road

I certainly do this. But asserting that most humans would usually do this? Have you ever actually seen humans drive cars? This is absolutely not what they do. On top of that, they run stop signs, routinely miss pedestrians in blind spots, respond to texts on their phone, or scroll around on their display to find the next song they want to put on.

The car was driving 17mph before braking. I don’t think I’ve ever seen a human drive at 17mph in a school zone or other area children congregate.

Meaning you’ve never seen a human drive that slowly in such an area, or you've never seen a human exceed the speed limit in a school zone?

Drive that slowly. I’m exaggerating obviously but the norm is to speed.

There are always going to be outlier events. If for every one person who still manages to get hit—at slow, easily-survivable speeds—you prevent five others from being killed, it’s a pretty obvious choice.

Gosh, no, the self-driving cars will be forced to drive at safe speeds in pedestrian corridors as opposed to voluntarily driving at safe speeds in pedestrian corridors. How awful.