Sample architecture review
A covert duress-alert feature, reviewed before release
This is what the $750 review looks like. The system is my own: the discreet trigger tier of GCMP Security’s emergency-alert app, which lets someone send a duress signal without an observer noticing. I reviewed it the way I review a client’s system: after it was built and working, looking for what functional testing can’t find.
Condensed for publication. A client report also includes the evidence log, code references and a starter eval set.
1. Summary
Verdict: the feature did exactly what it was designed to do, and had three ways to fail that no functional test would ever catch. One let a user jump the emergency queue, one kept sending live alerts to devices nobody controlled any more, and one showed an SOS button that silently did nothing.
| # | Finding | Severity | Status |
|---|
| F1 | Priority could be self-asserted when an alert was created | High | Fixed, verified |
| F2 | Signed-out devices kept receiving alert notifications | High | Fixed, verified on device |
| F3 | Lock-screen SOS button survived sign-out and did nothing | High | Fixed, verified on device |
| I1 | Anyone holding the locked phone can fire a covert alert | Info | Accepted tradeoff, documented |
2. Scope and method
- In scope: the discreet trigger surface (quick-settings tile, opt-in lock-screen SOS, background trigger engine), the alert data model’s priority field, and the sign-in and sign-out lifecycle around them.
- Method: static read of the native trigger code, backend access rules and push-notification lifecycle; direct writes against the database emulator bypassing the app; sign-in and sign-out sequences on a physical device.
- Not checked: the classifier, the dispatcher console, load, and infrastructure outside the repository.
3. Findings
F1. Priority could be self-asserted when an alert was created
High Permission surface
What happened
The backend accepted any alert whose priority flag was a boolean. Nothing tied priority to the covert trigger that is supposed to set it.
Scenario
A user writing directly to the backend, skipping the app, tags every ordinary alert as priority duress. They jump the queue ahead of real duress alerts, the priority badge dispatchers are being trained to trust stops meaning anything, and the paid tier is bypassed.
Fix
Restrict the trigger type to the two values the app actually sends, and allow priority only when the trigger is the covert one. Priority was already immutable after creation.
Verified by
A new emulator-backed test harness, eight cases: legitimate manual and covert alerts accepted; spoofed priority, unknown trigger type, wrong data type, spoofed user and injected classifier fields all rejected.
F2. Signed-out devices kept receiving alert notifications
High Session lifecycle
What happened
Signing out never removed the device’s push token from the account. Token cleanup only ran when the push service reported a token as invalid, and a signed-out app’s token is still valid.
Scenario
A returned tablet or a departed employee’s phone keeps receiving full emergency alerts, indefinitely, for an organisation that no longer controls it.
Fix
On sign-out: a best-effort server call removes this device’s token only, then the token is invalidated locally so it dies even if the call failed. Sign-out is never blocked by network state.
Verified by
Physical device: sign-out removed exactly that device’s token, and an injected assignment afterwards produced no notification.
F3. Lock-screen SOS button survived sign-out and did nothing
High Failure handling
What happened
Found while verifying F2. The opt-in lock-screen SOS notification stayed visible after sign-out, and the app re-showed it on every launch. Pressing it created nothing, because there was no signed-in user.
Why it’s High
From a security view this fails safe. From a safety view it’s the worst outcome: a live-looking SOS button that does nothing, discovered in an emergency. No button is better than a dead one.
Fix
Tie the button’s visibility to sign-in state at both layers: hidden on sign-out, restored on sign-in, without touching the user’s opt-in preference.
Verified by
Release build on a physical device, launched signed-out: no SOS button, nothing resurrected.
I1. Anyone holding the locked phone can fire a covert alert
Info Design tradeoff
Note
That is the point of a lock-screen panic button, and it’s opt-in. But the organisations deploying it need to know, so it goes in partner documentation rather than staying implicit in the code.
4. Checked and sound
- The native trigger components can’t be invoked by other apps; the one exposed entry point is guarded by a system-only permission.
- No data from the triggering intent flows into the alert itself.
- The background trigger binds to the real signed-in session and fails safe when there isn’t one.
- The operating system still enforces the microphone permission; nothing in the fast path skips it.
A good review says what it checked and found nothing. That tells you where not to spend time.
5. What to build next, and what to skip
Skip for now: full paid-tier enforcement on alert creation. The obvious next step after F1 is to reject covert alerts from users who haven’t paid for the tier. Don’t. A rule like that would reject a real covert SOS if billing data were wrong or late, and life-safety outranks revenue protection. Revisit when the tier is actually sold separately, and stamp priority on the server from the entitlement rather than blocking the write.
None of these were found by testing whether the feature worked. It worked. They were found by asking what happens around it: who else can write, what happens on sign-out, what the user sees when the system can’t act.
Want this for your system?
Fixed price, $750, one week, written. Failure modes, eval coverage, permission surface, what to build next and what to skip. Get in touch.