Filter every OpenTagViewer escrow record, not just this session's - #224
Merged
Merged
Conversation
Joining the trust circle writes an escrow record beside the user's real hardware, and the recovery picker then asks for "the screen-lock passcode of one of your Apple devices" about a program that has no screen. There is no answer: that passcode was generated, never shown, and was never the user's to know. The app already dropped one such record. It dropped exactly one. The filter compared each record against the serial the current session presents, which was correct only while every install presented the same constant. Serials are drawn per install now, so the equality test hides this install's record and leaves every other one of ours on the list: the record from before a reinstall, the desktop exporter's, and one more for every trust-circle join. All equally unusable, and there are more of them than there was of the one being filtered. So the match moves to the prefix, which is the part that is stable by design - SERIAL_PREFIX exists precisely so an entry is identifiable as ours. Both legacy constants fall out for free, since 0PENTAGVIEWR and 0PENTAGXPORT begin with their own prefixes. written_by_opentagviewer lives in exporter/identity.py because that module is one of the handful shipped into the APK, so it is the one place the app bridge and the desktop exporter can share a decision rather than keeping two that drift. The exporter had no filter at all before this; its wizard and CLI now use the same one, applied before the "nothing to recover from" check so that message stays true for an account holding only our records. Tests both directions, because they fail in opposite ways: too lax leaves unusable tiles, too eager hides a real Mac and presents as "the app cannot see my device". A record with no serial is kept rather than guessed at - the escrow schema is unstable enough that the field is genuinely sometimes absent. The duplicated prefix literal is pinned against Java on a device, since a copy nothing compares is a copy that drifts silently. Verified the key test fails against the old equality check. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This was referenced Sep 16, 2026
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Joining the trust circle writes an escrow record beside the user's real hardware, and the recovery picker then asks for "the screen-lock passcode of one of your Apple devices" about a program that has no screen. There is no answer — that passcode was generated, never shown, and was never the user's to know.
The app already dropped one such record. It dropped exactly one.
The filter compared each record against the serial the current session presents, which was correct only while every install presented the same constant. Serials are drawn per install now (rule 11), so the equality test hides this install's record and leaves every other one of ours on the list: the record from before a reinstall, the desktop exporter's, and one more for every trust-circle join. All equally unusable, and there are more of them than there was of the one being filtered.
The change
The match moves to the prefix, which is the stable part by design —
SERIAL_PREFIXexists precisely so an entry is identifiable as ours. Both legacy constants fall out for free, since0PENTAGVIEWRand0PENTAGXPORTbegin with their own prefixes.written_by_opentagviewerlives inexporter/identity.pybecause that module is one of the handful shipped into the APK by name, so it is the one place the app bridge and the desktop exporter can share a decision rather than keeping two that drift.The exporter had no filter at all before this. Its wizard and CLI now use the same one, applied before the "nothing to recover from" check so that message stays true for an account holding only our records.
Tests
Both directions, because they fail in opposite ways: too lax leaves unusable tiles, too eager hides a real Mac and presents as "the app cannot see my device". A record with no serial is kept rather than guessed at — the escrow schema is unstable enough that the field is genuinely sometimes absent.
The duplicated prefix literal is pinned against
AdiDeviceIdentity.SERIAL_PREFIXon a device, since a copy nothing compares is a copy that drifts silently, and the symptom would only ever appear on an account nobody testing has.Verified the key test fails against the old equality check. 303 bridge tests and 675 exporter tests pass; flake8 clean.
Not verified here: no Android toolchain on this machine, so the new instrumented assertion is CI's word, not mine.
🤖 Generated with Claude Code