What the app uses of the device

Status: Accepted · Audience: Both · Area: N — Companion

---

Purpose

A phone offers things a terminal does not — a camera, a secure enclave, a fingerprint, a notification that arrives when the app is closed — and each one is a permission somebody grants and a surface somebody can lose.

This feature is the whole of what the app asks of the device, why each is asked for, and what happens when it is declined. It is separate from N1 because the answer to “what does this app do with my camera” should be readable in one place by somebody who is not going to read the rest.

The rule underneath all of it is G8’s: nothing leaves the device that the operator did not ask to send.

Behaviour

Every permission is asked for at the moment it is used

Nothing is requested on first launch. The camera is asked for when somebody taps scan, notifications when they choose to be notified. A permission sheet on launch, before the person knows what the app is, is a request they cannot meaningfully answer.

Each one states what it is for in the app’s own words before the system asks.

Every permission is optional, and the app works without it

Declining the camera leaves typed pairing. Declining notifications leaves an app that is checked rather than one that tells you. Declining biometrics leaves a passcode. Nothing is a dead end, and nothing is asked for twice after a refusal.

The session lives in the platform’s secure storage

A session token is kept in the Keychain or the Android Keystore, never in application preferences, never in a file the app writes, and never in a backup that leaves the device unencrypted.

The app locks

Anything that can stop a stack or read a household’s requests is behind a lock: biometric where offered, passcode otherwise. It engages on backgrounding rather than after a timer, because the case it exists for is a phone handed to somebody for a moment.

Biometric failure falls back to the device passcode. It does not fall back to nothing.

A lock over nothing is an obstacle, not a protection

N4-R19 asks for the device’s own authentication on a cold start. Read without a qualifier that is also true of the first launch of a freshly installed app, where no stack is paired, no session is held and the secure store is empty — and the first thing the app does is demand a fingerprint to see a screen that says no stacks yet.

What the lock is for is what decides when it applies. It stands between a person holding the phone and what the operator’s credential reaches: a stack that can be stopped, a household’s requests, a diagnostic. Where the device holds none of that, there is nothing on the other side of the prompt, and an authentication that protects nothing teaches an operator that the prompt is noise. That is the way a lock gets turned off.

So the first run is the case the requirement does not cover, and the way to tell it is not a flag the app sets but the store it already reads: nothing paired and nothing held is a device with nothing to protect. It is the same question N1-R35 answers on the other side — a launch with no stack configured is an invitation to pair, and a lock in front of an invitation is a door onto a field.

It is not a grace period and it is not configurable. The moment the device holds a pairing, the prompt applies on the next cold start with no further condition. An operator who has paired once is never again offered the unlocked launch, which is what keeps this from being a setting somebody can leave on.

Notifications say what happened without saying too much

lemonfiber already decides what is worth telling somebody about (B5). A notification on a lock screen is read by whoever is holding the phone, so it carries what happened and never a credential, a household member’s name, or a title somebody requested.

The app does not invent alerts of its own.

Notifications reach the phone without a vendor’s push service

No notification passes through Apple’s or Google’s push service, or through anything that could read it (ADR-0047). The app raises each one itself, from its own pinned connection to the stack: while it runs, and when the platform wakes it for background refresh, when it reads what the stack raised while it slept. On Android, where a UnifiedPush distributor such as ntfy is installed, the stack can wake the app through it; the push says only that the stack has something to say, and what is notified is read over the app’s own connection.

A closed app on iOS hears its stacks when the system lets it, which may be rarely. The app says so where notifications are turned on, rather than promising what it cannot do, and says the same of Android without a distributor.

What it reads on waking is what the stack hands back of what it raised meanwhile. Unless the stack says that hand-back is whole, the app cannot tell whether an alert was lost while it was not listening, so it never presents what it told as everything, and says to the operator, where notifications are turned on, that some may be missing.

Nothing is sent anywhere else

No analytics, no crash reporting to a third party, no telemetry. A diagnostic the operator chooses to share is assembled and handed to them (C4’s rules apply to its contents), and they send it. The app does not.

The platform’s own accessibility, not a second one

Because the UI is the platform’s own components (ADR-0017), text scaling, screen readers, contrast and reduced motion are the system’s and are honoured by being used rather than re-implemented. G3’s bar applies here as it does to every surface.

What the brand does and does not assert on this surface is its own mapping: the accent, the neutral roles in a light and a dark value each, the app icon and the launch mark, and nothing that would override the reader’s own type size or choice of light or dark.

States

Edge cases

Acceptance criteria

Related

• N1 — the session this stores and locks
• G3 — the accessibility bar every surface is held to
• G8 — nothing leaves that was not asked to leave
• B5 — where a notification comes from
• C4 — what a diagnostic may contain