[gruez]

There really isn't. You can try avoid the "30GB volume on 128GB phone" problem by putting the hidden volume inside the free space of another volume, but since the outer volume doesn't know about the hidden, you have to be very careful not to overwrite the inner volume contents. The safest way would just be to not use the outer volume, but that's also suspicious. Who carriers around a phone that doesn't have any activity for months/years? Not to mention trim/discard means that free space will get wiped by default, and disabling it also makes you stick out like a sore thumb.

You're better off traveling with a wiped phone, and restoring from backup after you've crossed.

[dredmorbius]

Who carriers around a phone that doesn't have any activity for months/years?

An activity-generator might help address that.

[gruez]

Well the activity generator is going to have to be very careful to not accidentally overwrite data on the hidden volume, and somehow able to hide itself from adb or forensic tools that it's enabled.

[cromka]

The activity generator may be a tool on your PC which is well aware of the hidden partition's presence. All it has to do is changing partition size before writing anything, then restoring it. It may also generate using your real data, which you explicitly ack. Some safe communication with your grandma and mother, some messages from your employer, banks, other recent 2FA codes. You white flag contact names and it does the job for you.

[dredmorbius]

The problem with pre-generated activity is that it must cut off at (or shortly in the future of) generation time, to be plausible.

Otherwise that activity would be suspicious due to either a lack of recent records, or of presumably implausible future ones.

Generating data in advance and applying or updating timestamps later, on an ongoing basis, or when a duress code is entered is a possible way of mitigating this. There's the question of how convincing such data would have to be. White-flagging and generating (or appropriating from public sources, e.g., business or institutional entities) contacts for this might be a part of it. This is similar to but not entirely the same as data fuzzing, which is generally seen as applying to a primary data trail.

[dredmorbius]

Those are ... relatively minor concerns.

Firing off as part of a duress key entry, and removing itself (from the decoy partition) as its work is done, would suffice.

ADB / forensic tools would be ineffective if USB access is denied (as discussed elsewhere in this thread).

[gruez]

>ADB / forensic tools would be ineffective if USB access is denied (as discussed elsewhere in this thread).

Well no, because if you gave the pin, you'd expect the phone to work normally, including enabling adb. If you gave the pin but adb doesn't work that would be massively suspicious. Same if adb worked but logs were scrubbed. Otherwise you're back at "border guards found out you gave a duress pin, now you're being prosecuted for tampering with evidence".

[layla5alive]

It doesn't feel like you're very interested in solving this problem - you seem more interested in defending the status quo

[dredmorbius]

In fairness, an adversarial challenge can be useful in pointing out weaknesses (and possible mitigations) to a particular technical approach.

It's not clear that all of those objections are substantive or insurmountable.

"The USB port may have died" might be one possible response. (Not technically a lie, and hence defensible in court.) Or just silence.

Alternatively, some way of directing such probes to the decoy partition and presenting a sufficiently coherent impression of a valid partition might be another approach.

Much of this comes down to risks presented and costs of mitigation (or of getting mitigations wrong).