This is a technical problem.

Instead of wiping and rebooting, it should wipe while showing a lame spreadsheet application, or possibly a grocery list.

▲

woodruffw 2 days ago | parent | next [-]

I don’t think a judge would be impressed by this. If anything it actually makes the legal case easier: there’s a legitimate use for a wiping feature on a phone (e.g. for theft or tampering), but actively producing false information demonstrates an intent to deceive or mislead.

▲

olalonde a day ago | parent | next [-]

Deceiving a kidnapper into thinking you complied with their order to unlock your phone would be a legitimate use.

	▲	rbanffy an hour ago \| parent [-]
		My RSA app accepts a PIN before it generates a passcode. If I enter the wrong PIN, it’ll generate a wrong passcode. Do, I guess the cops will continue to beat me until I produce a valid passcode.

▲

cherryteastain 2 days ago | parent | prev [-]

Easier solution: phone wipes itself if passcode is not entered every X hours

▲

Andromxda 2 days ago | parent | next [-]

GrapheneOS already has an auto-reboot feature that can be set to time intervals ranging from 10 minutes to 72 hours. Rebooting puts the device back in before first unlock (BFU) state. This wipes all memory contents, including the encryption keys. Any unlock attempt will have to go through the secure element, which is basically impossible to tamper with (no successful attacks on the Titan M2 so far, or the Apple SEP for that matter), and includes substantial security mechanisms, such as throttling key derivations (through the Weaver API), or insider attack resistance (requiring user authentication before new firmware can be flashed to the secure element).

Leaked documents from mobile forensics companies, such as Cellebrite or XRY confirm this. It's impossible to crack a Pixel with GrapheneOS in BFU state. See https://grapheneos.social/@GrapheneOS/112462758257739953 and https://grapheneos.social/@GrapheneOS/112826067364945164

▲

atoav 2 days ago | parent | prev | next [-]

Deadmans-switch, nice. I always had a weird fascination for that kind of mechanism, because it inverts the whole situation. Where before you have to actively wipe a phone, now them taking your phone may be the mechanism that triggers the wipe.

▲

bilegeek 2 days ago | parent [-]

Is it legally better? Absolutely. But all they have to do is say "they did this as a legal workaround for that" and you're no better off, at least not without spending the same amount on lawyers. You can't out-tech your way around a corrupt system, they will find a way to get you.

▲

8note 2 days ago | parent [-]

if you have it running constantly, i dont think that argument can be made

id expect that youd be ordered to retain the data though, if an investigation is being done

▲

margalabargala 2 days ago | parent [-]

Any argument can be made, and accepted by a judge, in a sufficiently corrupt system. Like the parent said, you can't out tech this because logic ceases to be applied to laws. It instead become heads I win, tails you lose.

	▲	atoav 2 days ago \| parent [-]
		Yes sure, given a sufficiently corrupt system nothing helps. Even being innocent and revealing everything won't help. But this stance amounts to giving up. Within the wiggle room a system gives us there are still ways to widen cracks or attach a lever, however small they may be.

▲

ragall a day ago | parent | prev [-]

There's a problem with that too: it would often force the owner of the phone to input the code when outside a secure environment, so a simple video surveillance could obtain the code.

▲

cherryteastain a day ago | parent [-]

GrapheneOS has a feature to scramble the locations of the numbers on the passcode unlock screen to prevent this exact problem

	▲	ragall a day ago \| parent [-]
		That can be helpful only if surveillance cannot film the screen directly, and surveillance relies on the position of the fingers. Given modern 4k cameras it's unlikely the latter can be done but not the former.

▲

HybridStatAnim8 a day ago | parent | prev | next [-]

That would be a bad idea. GrapheneOS operates under the assumption that every attacker has encyclopedic knowledge of GOS at all times. This is by far not an unreasonable assumption. GrapheneOS does not add features relying on ignorance that they exist.

The duress wipe feature shuts the device down to let RAM discharge, this is an important step to remove any components of decryption before they can be lifted.

▲

Cider9986 a day ago | parent [-]

What about a duress timer working as the reboot timer but it wipes if you don't unlock within the time period. Would that have any advantages for destruction of evidence or deniability?

	▲	HybridStatAnim8 a day ago \| parent [-]
		That would not be viable because the hardware does not support it. It cannot be implemented in the OS because the OS can be turned off or exploited endlessly. For GOS to consider it, it would likely need to be backed by the secure element. Duress PIN is deemed acceptable to implement in the OS because it is expected that the user is the one to enter it, so it has not fallen into the hands of attackers who may bypass it. Once attackers have it, you are effectively gambling. Account for that in your threat model and do not let it get to that point.

▲

a day ago | parent | prev | next [-]

[deleted]

▲

Cider9986 2 days ago | parent | prev [-]

Or just don't wipe your phone and let the reboot timer do its work and bring your phone to BFU state, effectively uncrackable.

▲

cogman10 2 days ago | parent | next [-]

The issue here is CBP was (illegally) demanding he give them his passcode (5th amendment violation).

Doesn't really matter if the reboot timer is triggered if the thugs have beaten your code out of you.

	▲	blooalien 2 days ago \| parent [-]
		There's an XKCD for that: https://xkcd.com/538/

▲

unethical_ban 2 days ago | parent | prev [-]

Or turn your phone off while transiting airports. Not a catch-all solution in life, but considering the extra-lack of rights we have there, it makes sense. No need for them if you write down your confirmation number before arriving for departure, in order to get your ticket printed. On landing, have it off until you clear TSA and Customs.

It shouldn't be this way, but oh well.

▲

pstuart 2 days ago | parent [-]

At least disable biometric login.

	▲	Andromxda 2 days ago \| parent \| next [-]
		And fully disable the USB port (GrapheneOS-exclusive feature). This will make it impossible to extract data with mobile forensics software/devices (such as the Cellebrite UFED).
	▲	Cider9986 2 days ago \| parent \| prev [-]
		Grapheneos has pin+biometric second factor as secondary unlock so it should be fine if you use that.