Secondly, it is important to get as many people to use GrapheneOS as possible, including non-tech people. The more widespread it becomes, the harder it will become to paint this picture.
The recent Darksword exploit should give everyone pause in asserting that iOS is secure:
https://www.malwarebytes.com/blog/mobile/2026/03/a-darksword...
I trust iOS with my banking and financial apps in a way that I would never trust Google, but I am under no illusion that any architecture can be completely secure.
On the Linux side, I have found SELinux maddening at times in forcing me to the syslog to enable and permit what I need the machine to do.
I have never seen anything this obstreperous in a BSD, but perhaps I have not looked with sufficient depth.
In any case, the Trust / SELinux / Enforcing status is a sizable advantage against iOS.
It might have to do with e.g. Apple having rolled out MIE at a broader scale than Google rolling out MTE on PixelOS, where AFAIK it is still largely opt-in (not 100% sure, I always wipe a Pixel immediately).
That's impressive!!
iPhones are probably the most secure off the shelf phones you can buy, but based on leaked documents it's clearly inferior real-world security compared to a Pixel running GrapheneOS. Apple and Google have copied many security features from GrapheneOS like the reboot timer.
GrapheneOS is built from the ground up with a primary priority placed on security. GrapheneOS has much more robust USB port hardening. You can see the full list of features added on their website. Apple bolts on some additional security features in lockdown mode but they are mostly fixes to Apple's services which have large attack surface like iMessage. Additionally they are all built together and not on by default which makes the users willing to use it way lower.
Probably the latest models. Cop told me they have problems cracking those. Older models not so much, that's pretty common knowledge.
So then the best chance for security is to stay up to date with everything, including the latest HW model. At least this gives an attacker a window of only ~1 year to find and exploit a vulnerability.
That is diametrically opposed to their interests in data collection.
When your job depends on not understanding and all that.
Also worth mentioning that you can set auto-reboot to a shorter period (down to 10 minutes). So if you anticipate situations where your phone can be seized (border crossings, demonstrations), it's worth temporarily setting this to a short time period (or rebooting your phone yourself to get to BFU).
Delete the contact book? Clear calendars?
Where exactly should one stop?
Just as the border guard can’t require you to fetch something from your house before entry, they can’t require you to restore from a remote backup that they don’t even know about.
On the other hand I don't know of any juridiction that force you to carry all the personal data in a single device when crossing borders. It would moat likely not even be possible.
Self-hosting is the way obviously
Also, you could set up a system where the phone cannot restore the backup on reentry. Perhaps a single use restore key that you use at your original destination, so the restore cannot be performed again until you return home and generate a new code. This evades the (flimsy) charges that were applied in this case.
The best option, however, is to bring a blank disposable device, restore from backup at your destination, then discard the device before you cross the border again.
If your devices are seized having encrypted data can pose extra risk.
Deniable encryption exists and burden of proving that you haven't used it can be put on you.
Basically I'm trying to say "it depends". I'm not a fan of "let's just slap a(nother) layer of encryption on it" security model. My home servers aren't encrypted and I see no reason to do so. Sensitive data is encrypted based on the sensitivity.
> The best option
The best option is the one that is most convenient to the user and fits the task at hand.
If you are on a demonstration and need to broadcast status live then you don't have a luxury of bringing in a blank phone and restoring backup before each transmission
I don’t think you can even set up an iPhone anymore without encryption. It’s just “on”, not even “on by default”.
> My home servers aren't encrypted and I see no reason to do so. Sensitive data is encrypted based on the sensitivity.
If you do sensitive work, you should be concerned about someone breaking in and running off with your storage. It’s unfortunate but that’s just how it is. Encryption adds very little overhead on modern hardware.
> If you are on a demonstration and need to broadcast status live then you don't have a luxury of bringing in a blank phone and restoring backup before each transmission
That’s not crossing a border then, is it? The case under discussion was about a border crossing, where (apparently?) Constitutional rights are suspended. A used phone adds little to the cost of an international trip.
Not even kidding here, it's time to bring out thin client computing to cellphones. Let the spicy stuff sit somewhere else. I could bootstrap a Tailscale or Netbird signin remotely, install the access client, and remote back into the 'normal phone'.
Would be then funny to map that to lockscreen PINs - enter a PIN to unlock the device, be remoted into "phone A", enter another pin and be remoted into "phone B", enter another PIN and you're on the 'local device' session. (Or duress-PIN kill "phone A" if someone attempts to bruteforce PINs, etc, etc...)
You can use TeamViewer for that. Or maybe scrcpy could be coerced into working in a similar way.
You can't even make them different sizes because that gives away which one is duress. You could have more partitions with a static split like 32+32+32+32+32+32+32+32 but then you have to manage so many independent partitions it isn't practical.
The main problem with any deniable encryption system is that while your adversary might not be able to prove if you gave them the decoy or real data, they can at least force you to wipe anything you fail to decrypt. In your partitioning scheme, that would mean wiping any partition that doesn't decrypt with the set of PINs you gave them. In the more advanced granular scheme that Betrusted devices use, that would mean border control unlocking all the basis keys you dared to give them, and then them running the storage reclaim tool that wipes all other keys.
In either case, it would probably be easier (and less suspicious!) to pre-wipe your device and then redownload a backup after you pass through border control... assuming you can get access to an untampered Internet connection after the fact, AND assuming your backup is actually complete. Like, I'm pretty sure most apps exclude their login tokens from backup, because every time I do wind up restoring a backup, I have to log into everything again, which makes me wonder what the point of the backup even is?
(The Computer Weekly item was submitted but saw no significant discussion.)