Files asks for your Flamenet passphrase, not a second secret #96

2026-09-05T14:42:57Z

paulhitt commented

2026-09-05 14:42:57 +00:00

(Migrated from gitlab.com)

Reported: "on android, the files passcode should just reuse the account like
ios does."

The difference was entirely in the words, and iOS has been right all
along. iOS says "your passphrase" and takes whatever is typed, so a person
naturally uses their Flamenet one and it simply works. Android said the files
were "encrypted with a passphrase of their own", labelled the field "Choose a
passphrase", and later asked for "your Files passphrase" — three separate
places telling somebody to invent, and then remember, a second secret.

Forgetting it is a one-way door. The label keys are derived from the
identity that passphrase protects and exist nowhere else, so a forgotten
Files passphrase makes every vaulted file permanently unreadable. Sending
people off to mint an extra secret for no reason put them one lapse of memory
from that, and the app already has a paragraph explaining the consequence.

Nothing in the derivation changed, deliberately. It is still a
free-choice string protecting the identity record, so anyone who already set
a different one keeps opening their files with it exactly as before. Making
the account passphrase the ACTUAL key would be a migration with permanent
data loss on the far side of any mistake, and it is not what was asked for.

That also means the copy IS the feature here, so a copy guard is the only
guard there can be. Proven by reverting the wording: both tests go red naming
the file and the phrase.

1194 tests pass.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

Reported: "on android, the files passcode should just reuse the account like ios does." **The difference was entirely in the words, and iOS has been right all along.** iOS says "your passphrase" and takes whatever is typed, so a person naturally uses their Flamenet one and it simply works. Android said the files were "encrypted with a passphrase of their own", labelled the field "Choose a passphrase", and later asked for "your Files passphrase" — three separate places telling somebody to invent, and then remember, a second secret. **Forgetting it is a one-way door.** The label keys are derived from the identity that passphrase protects and exist nowhere else, so a forgotten Files passphrase makes every vaulted file permanently unreadable. Sending people off to mint an extra secret for no reason put them one lapse of memory from that, and the app already has a paragraph explaining the consequence. **Nothing in the derivation changed, deliberately.** It is still a free-choice string protecting the identity record, so anyone who already set a different one keeps opening their files with it exactly as before. Making the account passphrase the ACTUAL key would be a migration with permanent data loss on the far side of any mistake, and it is not what was asked for. That also means the copy IS the feature here, so a copy guard is the only guard there can be. Proven by reverting the wording: both tests go red naming the file and the phrase. 1194 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

paulhitt commented

2026-09-05 14:42:57 +00:00

(Migrated from gitlab.com)

assigned to @paulhitt

paulhitt (Migrated from gitlab.com) scheduled this pull request to auto merge when all checks succeed 2026-09-05 14:43:10 +00:00

paulhitt (Migrated from gitlab.com) merged commit 76c548c727 into main

2026-09-05 14:44:04 +00:00

paulhitt commented

2026-09-05 14:44:06 +00:00

(Migrated from gitlab.com)

mentioned in commit 76c548c727

mentioned in commit 76c548c727c5f7484f6c9116ed01f99049239d64

paulhitt commented

2026-09-09 19:01:15 +00:00

(Migrated from gitlab.com)

changed the description

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: extant2000/flamenet-messenger-android#96