IDENTITY-AWARE DEVICE PRIVACY II
Threat Modeling and Operating-System Architecture
for Handoff, Owner, and Emergency Access
A Secretary Suite Project
John Swygert
Ivory Tower Publishing
October 1, 2026
Abstract
The first Secretary Suite paper proposed an identity-aware device architecture organized around Owner Mode, Handoff Mode, and Emergency Mode. Its governing principle was: “Possession permits utility. Identity determines access. Emergency permits assistance. None implies ownership.” This second paper develops that concept into a technical threat model and operating-system architecture. It identifies the security boundaries that must exist beneath the user interface; maps major attack surfaces to required mitigations and failure behavior; defines ephemeral session, notification, credential, sensor, network, and inter-process communication controls; and proposes an implementation path for an Android Open Source Project-class prototype. The central claim is that a trustworthy Handoff or Emergency environment cannot be merely a visual overlay or application lock. It must be a system-enforced identity context whose permissions, data flows, credentials, notifications, and transitions are constrained by the operating system and, where appropriate, hardware-backed security.
1. Relationship to the First Paper
Paper I established the conceptual distinction among possession, identity, temporary utility, emergency assistance, and ownership. Paper II preserves that model and asks a narrower engineering question: what must the operating system enforce so that those distinctions remain true under adversarial or accidental conditions?
The three states remain:
Owner Mode — the authenticated owner environment.
Handoff Mode — an owner-authorized, temporary non-owner session exposing only explicitly permitted capabilities.
Emergency Mode — a minimal unauthenticated environment that permits emergency assistance without exposing owner data.
This paper does not replace platform encryption, secure boot, hardware roots of trust, or biometric authentication. It specifies the additional policy and isolation layer required to make the three-state model enforceable.
2. Security Objectives
A conforming implementation should satisfy six primary objectives.
Identity separation: physical possession must not silently inherit the owner’s identity, credentials, application state, or private data.
Capability minimization: Handoff and Emergency Modes expose only the capabilities necessary for the authorized task.
Information-flow control: data must not leak through notifications, clipboards, autofill, recent items, share sheets, IPC, cached sessions, account pickers, voice assistants, or other secondary channels.
Transition integrity: movement into Owner Mode or broader permissions requires genuine owner authorization.
Fail-safe privacy: timeout, restart, crash, abnormal termination, or uncertain state returns the device toward the locked owner boundary rather than broader disclosure.
Emergency continuity: privacy failure or authentication failure must not disable the narrow emergency functions the platform is designed to preserve.
3. Trust Boundaries and Adversary Classes
3.1 Trust Boundaries
The architecture requires explicit boundaries among the owner profile, restricted-session profile, emergency surface, system services, hardware-backed authentication, persistent storage, volatile session state, sensors, radios, and external services. The restricted user interface is therefore not itself the security boundary; it is only the visible expression of deeper enforcement.
3.2 Adversary Classes
Curious borrower — a legitimate temporary user who explores beyond the intended task.
Opportunistic non-owner — a person who obtains temporary physical access and attempts to discover private information.
Lost-or-stolen-device user — a person with possession but no owner authorization.
Malicious application — software attempting to cross the restricted-session boundary through IPC, intents, accessibility services, overlays, notifications, shared storage, or account services.
Peripheral attacker — a person or device attempting access through USB, debugging, paired accessories, casting, external displays, or previously trusted connections.
Local forensic attacker — an attacker attempting to recover remnants from storage or memory after a restricted session.
Privileged compromise — malicious firmware, kernel compromise, defeated secure boot, or a broken hardware root of trust. This remains outside the guarantees of the proposed layer and must be stated explicitly.
4. System Architecture
A robust implementation is best modeled as a policy-enforced restricted identity context integrated with the operating system. On an Android/AOSP-class platform, the architecture would require framework-level cooperation rather than relying solely on a launcher or third-party application.
4.1 Mode Policy Controller
A privileged Mode Policy Controller maintains the authoritative state: OWNER, HANDOFF, or EMERGENCY. It validates transitions, loads the applicable policy profile, requests reauthentication when required, and exposes only narrowly scoped state information to other services. Applications must not be able to promote their own mode or widen their own permissions.
4.2 Restricted Session Container
Handoff Mode creates an ephemeral or strongly isolated user/session context. The session receives its own application state, temporary storage, clipboard, browser profile, recent-items database, share targets, and permitted accounts or synthetic account handles. Owner cookies, tokens, saved passwords, private contacts, media libraries, and application databases remain outside the session namespace.
4.3 Emergency Surface
Emergency Mode should be smaller than Handoff Mode. It is a system surface with a fixed capability set: emergency calling, supported emergency messaging, owner-authorized emergency contacts, and explicitly approved medical information. It should not become a general guest profile and should not inherit arbitrary applications.
4.4 Policy Enforcement Points
The policy must be enforced where information crosses boundaries. Relevant enforcement points include activity/task launching, package visibility, content providers, binder/IPC calls, intents, account and credential services, notification delivery, clipboard access, media providers, file pickers, share sheets, autofill, accessibility services, voice assistants, sensors, USB/debug interfaces, Bluetooth and casting, network configuration, and security settings.
5. Notification and Interruption Firewall
Incoming information is a major disclosure channel because the borrower need not actively seek it. A Notification Firewall therefore evaluates every notification against the active mode before presentation. In Handoff or Emergency Mode, private sender names, message bodies, email subjects, calendar details, authentication codes, health information, financial alerts, and other protected content are withheld unless the owner has explicitly authorized the category.
Suppression should occur before rendering on the restricted display surface. The system may queue the notification for later owner delivery or expose a content-free indication such as “private activity received.” Notification actions, inline replies, deep links, and app-opening affordances must be filtered with the same policy so that a hidden notification cannot become an escape route.
6. IPC, Intent, and Application Boundary
A restricted session can fail even when its visible applications appear isolated if those applications can invoke owner-context services. The operating system must therefore apply mode-aware filtering to inter-process communication.
Block or mediate Binder/IPC calls that would reveal owner-only data or invoke owner-context actions.
Filter implicit and explicit intents so permitted applications cannot launch protected activities through deep links or exported components.
Restrict content-provider queries to the restricted session’s namespace.
Present a mode-specific package and account view so applications cannot enumerate private applications or owner accounts unnecessarily.
Disable or constrain accessibility, overlay, screen-capture, notification-listener, VPN, device-administration, and other high-leverage privileges unless explicitly required by the profile.
Ensure the share sheet and file picker expose only session-authorized destinations and content.
7. Credentials, Autofill, Browser State, and Clipboard
The restricted session must not inherit owner secrets merely because a permitted application is the same executable used in Owner Mode. Password managers, passkeys, saved cards, autofill datasets, browser cookies, authenticated web sessions, form history, predictive text history, clipboard contents, and account-selection dialogs require mode-specific state.
A temporary browser should begin with a fresh profile unless the owner deliberately grants a particular session. When Handoff ends, the implementation should destroy the restricted profile’s ephemeral encryption keys and remove temporary state according to platform capabilities. This paper deliberately avoids claiming that arbitrary RAM can always be cryptographically “purged”; the defensible goal is strong isolation, minimized persistence, key destruction, lifecycle cleanup, and hardware-backed protection where available.
8. Network and Metadata Isolation
Even a clean browser session can reveal information through network configuration and metadata. Handoff profiles should therefore define whether the borrower may view or modify Wi-Fi networks, VPN state, hotspot settings, saved SSIDs, private DNS configuration, nearby-device identities, paired Bluetooth devices, or local-network discovery.
Some metadata cannot be hidden while still providing ordinary network access. For example, an external service can observe the public IP address used by the device. The architecture should distinguish information the operating system can conceal from the temporary user from information necessarily exposed to a remote service by use of the network. Security claims must follow that boundary rather than promise a fictional “zero-leak” environment.
9. Sensors, Media, and Temporary Capture
Camera and microphone access in Handoff Mode should be capability-specific. A temporary camera can write to a session gallery without exposing the owner’s existing media. A permitted microphone session should not grant access to stored recordings. Location can be denied, approximated, or granted according to the profile and application need.
Sensor permissions should expire with the session. Background sensor use, camera roll traversal, EXIF access, media indexing, and cross-profile media providers require explicit controls so that a seemingly harmless camera or map task does not become an indirect owner-data channel.
10. Security-Event Evidence Layer
Paper I proposed an optional evidence layer for suspicious access. Paper II treats it as a separate subsystem rather than a default property of legitimate Handoff Mode. When an owner-defined suspicious condition occurs, the system may create an integrity-protected event record containing time, active mode, failed authentication status, attempted protected action, relevant device state, and—where lawful, configured, and technically permitted—a front-camera image.
Biometric hardware should remain inside its secure subsystem. The architecture must not assume access to raw fingerprint images or templates. A production implementation may record the secure subsystem’s permitted match/non-match/error result and associated event metadata without extracting biometric secrets.
Evidence should be encrypted, integrity-protected, unavailable to restricted sessions, and subject to owner-defined retention. Jurisdiction-specific rules governing covert imaging, biometrics, consent, retention, and disclosure require legal review before deployment.
11. Formal Threat Matrix
Attack Surface | Owner Mode | Handoff / Emergency Control | Primary Mitigation | Failure Behavior |
Notifications | Normal owner policy | Private content withheld | Notification firewall; action/deep-link filtering | Queue privately; do not reveal |
Clipboard / autofill | Owner state available | Separate/empty state | Mode-scoped clipboard and credential services | Return empty/denied |
Browser cookies | Owner profile | Fresh restricted profile | Separate storage namespace; no token inheritance | Unauthenticated session |
Gallery / files | Owner libraries | Session-only or explicit grants | Profile-scoped media/file providers | Deny access |
IPC / intents | Normal platform rules | Mode-aware mediation | System-service and component filtering | Block transition/action |
Accounts / passkeys | Owner accounts | Hidden unless explicitly granted | Credential/account namespace isolation | No account presented |
Share sheet / picker | Owner destinations | Restricted destinations | Mode-aware resolver and picker | No protected target |
Voice assistant | Owner policy | Disabled or restricted | Mode-scoped assistant capabilities | No owner-context action |
USB / debugging | Owner policy | No privilege expansion | Disable debugging/config changes; restrict data roles | Charge-only / deny |
Bluetooth / casting | Owner devices visible | Profile-defined visibility | Hide/manage paired-device surfaces | No new pairing/control |
Security settings | Owner authenticated | Unavailable | Privileged transition gate | Require owner authentication |
Restart / crash | Normal boot policy | Restricted state cannot broaden access | Persistent mode marker + locked boot boundary | Return locked/private |
Failed biometrics | Normal retry policy | Never promotes identity | Secure subsystem result only | Remain restricted |
Evidence records | Owner access | No access | Encrypted integrity-protected store | Preserve; deny modification |
Emergency call | Available | Always available | Dedicated emergency surface | Preserve assistance |
12. State-Transition Rules
The mode controller should implement explicit transition rules rather than infer broad authorization from continued possession.
LOCKED → OWNER requires valid owner authentication.
OWNER → HANDOFF requires deliberate owner activation and a selected or default Handoff profile.
HANDOFF → OWNER requires valid owner authentication; knowledge of the Handoff task or continued possession is insufficient.
LOCKED/HANDOFF → EMERGENCY may occur without owner authentication.
EMERGENCY → OWNER requires valid owner authentication.
EMERGENCY → HANDOFF should not occur unless the owner has previously defined a safe transition or authenticates.
HANDOFF/EMERGENCY timeout, restart, crash, or policy uncertainty must never widen access.
A restricted application requesting a protected capability triggers denial or owner reauthentication, not silent privilege escalation.
13. Fast Handoff as a Security Requirement
A secure feature that is too slow to invoke will be bypassed in ordinary life. Handoff activation should therefore be treated as part of the threat model rather than cosmetic user experience. The design target should be a routine transition achievable in approximately two seconds once configured: for example, a dedicated lock-screen gesture, quick-action control followed by owner biometric confirmation, or a secondary authenticated gesture that launches a default Handoff profile.
Speed must not weaken intentionality. The interface should make clear what the borrower can use, while avoiding a configuration ceremony every time the phone changes hands. Reusable profiles—Passenger, Family, Browser/Phone, Repair, and similar owner-defined contexts—reduce friction without converting Handoff into an unrestricted guest account.
14. AOSP-Class Prototype Architecture
A research prototype on an Android Open Source Project-class platform would likely require modifications or privileged integrations across multiple framework services. The following is an architectural map rather than a claim that each named component can be modified identically across all Android versions or vendor builds.
System UI / lock screen: mode selection, restricted status display, emergency surface, and owner reauthentication.
Activity/task management: prevent restricted tasks from launching owner-only activities and control cross-profile task transitions.
Package management / resolver: present only authorized applications, components, and share targets.
Notification service: apply the Notification Firewall before restricted rendering or action exposure.
Account, credential, keystore, and autofill services: prevent owner-secret inheritance and expose only profile-authorized credentials.
Content/media/file providers: enforce profile-scoped namespaces and explicit grants.
Clipboard and input-method services: prevent owner clipboard and learned/private text state from crossing into restricted sessions.
Connectivity services: restrict configuration visibility and modification of Wi-Fi, VPN, hotspot, Bluetooth, casting, and nearby-device state.
Sensor/privacy services: apply mode-specific camera, microphone, location, and background-sensor policy.
Biometric/KeyMint/TEE-facing services: preserve hardware-backed owner authentication while exposing only permitted result status to the mode controller.
Persistent policy store: retain mode configuration and fail-safe state without making evidence or owner secrets available to the restricted user.
15. Verification and Acceptance Tests
The architecture should be tested as a set of falsifiable guarantees. A prototype succeeds only when a temporary user can complete authorized tasks while repeated attempts to cross the identity boundary fail.
Activation test: configured Handoff Mode can be entered quickly and reliably without exposing owner content during transition.
Notification test: protected notifications arriving during restricted use reveal neither content nor actionable escape paths.
Credential test: permitted browsers and applications cannot obtain owner cookies, passkeys, autofill secrets, or account tokens unless explicitly granted.
IPC escape test: deep links, exported activities, intents, providers, accessibility services, overlays, and share targets cannot cross into owner-only resources.
Media test: a temporary camera can capture and use session media without enumerating the owner gallery.
Restart/crash test: forced process death, UI crash, reboot, and timeout never broaden privileges.
Emergency test: emergency calling and authorized emergency information remain available despite failed owner authentication.
Evidence-integrity test: a restricted user cannot view, alter, or delete protected security-event records.
Usability test: ordinary users can understand the active mode, complete permitted tasks, and return the device without accidental disclosure.
16. Residual Risks and Limits
No restricted-session architecture can guarantee privacy if the operating system, kernel, secure boot chain, or hardware root of trust is already compromised. Nor can it prevent a borrower from observing information the owner deliberately exposes for the permitted task. Network use necessarily reveals some information to external services, and legal requirements for emergency access, covert imaging, biometrics, and data retention differ by jurisdiction.
The objective is therefore not absolute secrecy. It is a defensible reduction of unnecessary disclosure by making possession, identity, authorization, and emergency capability separate enforceable relationships.
17. Research Program
Paper II turns the Secretary Suite concept into a prototype-ready research agenda. The next phase should combine a reference implementation with adversarial testing. Useful work packages include: a minimal AOSP mode controller; a restricted-session container; notification filtering; credential and clipboard isolation; mode-aware intent/IPC enforcement; emergency-surface hardening; protected event logging; and a usability study measuring activation time, task completion, accidental disclosure, and escape attempts.
The architecture should be evaluated against existing platform mechanisms not by asking whether they offer a guest mode or application pinning, but by testing whether they preserve the governing relationship: can another person use the physical device for a defined purpose without inheriting the owner’s digital identity?
18. Conclusion
Identity-aware device privacy requires more than hiding applications. It requires the operating system to treat identity as a security context that governs information flows across the entire device. Handoff Mode must therefore isolate sessions, credentials, notifications, storage, IPC, sensors, network configuration, and transitions. Emergency Mode must remain smaller still, preserving assistance without becoming an authentication bypass.
The resulting architecture retains the principle established in Paper I: possession can permit utility without conferring identity, and emergency need can permit assistance without conferring ownership. Paper II translates that principle into enforceable trust boundaries, threat controls, failure rules, and acceptance tests suitable for an operating-system prototype.
Possession permits utility. Identity determines access. Emergency permits assistance. None implies ownership.
No comments:
Post a Comment