IDENTITY-AWARE DEVICE PRIVACY
AND EMERGENCY ACCESS
A Secretary Suite Project
John Swygert
Ivory Tower Publishing
October 1, 2026
Abstract
Personal smartphones increasingly function as extensions of identity: they contain private communications, photographs, files, financial access, health information, authentication tokens, location histories, cloud accounts, and records of daily life. Yet the physical device is also an extraordinarily useful object that an owner may reasonably need to hand to another person, and in an emergency it may be the nearest available communications instrument. Conventional lock-screen design treats these situations too coarsely: either the device is locked, or a person who has authenticated may enter a much larger private environment.
This paper proposes an identity-aware device architecture for Secretary Suite that separates physical possession, temporary utility, emergency assistance, and owner identity. The architecture is organized around three operating states—Owner Mode, Handoff Mode, and Emergency Mode—and a policy principle: possession may permit narrowly defined utility without conferring access to the owner's digital identity. The proposal further introduces privacy-preserving notification controls, temporary-session isolation, automatic re-locking, emergency communications, and an optional security-event evidence layer for documenting suspicious or unauthorized interaction. The goal is not merely to lock individual applications, but to make the device itself change what it is permitted to reveal according to the identity and authorization state of the current user.
1. Problem Definition
A modern smartphone is simultaneously a telephone, camera, wallet, key ring, correspondence archive, identity token, medical-information carrier, navigation device, cloud terminal, and personal computer. Handing the device to another person can therefore expose information wholly unrelated to the reason it was handed over. A person borrowing a phone to place a call should not thereby gain access to photographs. A friend using navigation should not see incoming private-message previews. A repair technician testing a speaker should not inherit access to email. A stranger using a found or borrowed phone during an emergency should not need the owner's passcode merely to contact emergency services.
The architectural mistake is to treat device possession and owner authorization as nearly synonymous. They are different relationships. A device can be physically useful to a non-owner while remaining informationally private.
2. Governing Principle
Possession permits utility. Identity determines access.
Emergency permits assistance. None implies ownership.
The proposed system treats authorization as a continuously enforced boundary rather than a single unlock event. The relevant question is not simply whether the screen is unlocked, but which identity context is active and which information flows are permitted within that context.
3. Three-State Architecture
3.1 Owner Mode
Owner Mode is the normal authenticated environment. Successful owner authentication—using the device's configured credentials and secure biometric mechanisms—restores the owner's authorized applications, files, accounts, notifications, settings, cloud connections, credentials, and personalized services. Existing operating-system security remains foundational; Secretary Suite adds a higher-level identity and disclosure policy rather than replacing secure hardware, encryption, or platform authentication.
3.2 Handoff Mode
Handoff Mode is intentionally activated when the owner wants another person to use the device without entering the owner's private environment. The owner selects or predefines the capabilities that remain available. Examples can include a telephone dialer, a particular browser session, maps, a calculator, a camera with a temporary gallery, a music player, or one specifically authorized application.
Private content remains inaccessible even while permitted functions operate. Owner photographs, messages, email, files, browser history, saved passwords, financial applications, cloud drives, private contacts, account-switching controls, notification contents, authentication tokens, and other designated resources remain sealed. The temporary user receives a session, not the owner's identity.
3.3 Emergency Mode
Emergency Mode is available without the owner's passcode or fingerprint, but exposes only a deliberately minimal emergency environment. Its core purpose is to allow a person with physical possession of the device to request help without gaining access to private data.
Permitted functions can include emergency voice calls, emergency text or equivalent emergency messaging where supported, access to owner-designated emergency contacts, and explicitly authorized emergency medical information. The interface must prevent lateral movement into ordinary messaging histories, contact databases, photographs, files, account settings, cloud services, or other owner resources.
4. Handoff Session Isolation
Handoff Mode should behave as a temporary, isolated identity context. Applications opened within it receive only the data and permissions assigned to that session. A temporary browser should not inherit the owner's authenticated cookies. A camera session should not expose the owner's existing gallery. A telephone interface may allow dialing without exposing an unrestricted contact history. Clipboard contents, autofill data, password managers, recent-document lists, notification histories, and cross-application sharing should be filtered or replaced with temporary-session equivalents.
When Handoff Mode ends, temporary state can be discarded according to owner policy. The system should automatically return to a locked owner boundary after a configurable timeout, device restart, explicit return command, or security event.
5. Notification Firewall
One of the easiest ways to violate privacy after a phone is handed to someone is through information that arrives rather than information the borrower actively seeks. Handoff and Emergency Modes therefore require a notification firewall. Private message text, sender names, email subjects, calendar details, financial alerts, authentication codes, health notifications, and similar content should not appear unless the owner has explicitly authorized that category.
The device may indicate that private activity occurred without revealing its substance—for example, by recording notifications for later presentation when Owner Mode is restored.
6. Emergency Utility Without Identity Disclosure
Emergency accessibility should be designed as a capability boundary rather than an authentication bypass. A non-owner may be able to initiate an emergency call or compose a new emergency message while remaining unable to inspect prior communications. Emergency contacts can be exposed selectively, with the owner deciding which names, relationships, medical facts, or instructions are appropriate to reveal.
The emergency environment should be visually unmistakable and technically constrained. No action performed within it should silently convert the session into Owner Mode. Authentication remains necessary for owner data even after emergency communication succeeds.
7. Security-Event Evidence Layer
Secretary Suite can optionally treat entry into designated non-owner or suspicious-access states as a security event. With the owner's prior configuration and subject to applicable law, the device may create a protected event record containing a timestamp, mode entered, failed authentication attempts, relevant device state, and other security telemetry.
One proposed feature is an unannounced front-camera capture when a defined suspicious-access condition is triggered. The purpose is evidentiary: to document who was interacting with a lost, stolen, or protected device without advertising the evidence-collection event to that person. Because laws governing image capture, biometrics, consent, retention, and disclosure vary by jurisdiction, this feature must be configurable, legally reviewed, and designed with strict retention and access controls.
7.1 Biometric Prompt as Evidence Event
A non-owner may also be prompted to present a fingerprint or other biometric while still being allowed to use the narrow functions that do not require owner authentication. The crucial distinction is that the prompt does not falsely authenticate the person and does not unlock owner information. A failed or non-owner biometric interaction can instead be recorded as a security event.
The architecture should not assume that ordinary mobile biometric hardware exposes a raw fingerprint image. In a production implementation, Secretary Suite should use only evidence and status information legitimately available from the platform's secure biometric subsystem. Raw biometric templates should not be copied out of secure hardware merely to create an evidentiary record. The design goal is documentation of the interaction, not creation of an insecure biometric database.
8. Covert Evidence and User Safety
Covert evidence collection creates a tension between device-owner security and the privacy rights of the temporary user. The architecture therefore separates ordinary Handoff Mode from suspicious-access evidence collection. A person whom the owner intentionally hands the phone to should not automatically be treated as an intruder. The owner can define which transitions or failed-authentication patterns constitute a security event.
Evidence records should be encrypted, integrity-protected, inaccessible from Handoff and Emergency Modes, and subject to configurable retention. Remote synchronization, if used, should occur only through an authenticated owner-controlled service. The system should clearly document its evidence policy to the owner during setup even when a triggered capture itself is intentionally not announced to the person handling the device.
9. Continuous and Event-Triggered Identity Assurance
The three modes need not depend on a single authentication event forever. Secretary Suite can support continuous or event-triggered identity assurance. Sensitive actions can require renewed owner authentication even when Owner Mode is active. Conversely, a device intentionally placed into Handoff Mode should not attempt to infer that the borrower has become the owner merely because the device remains in use.
Useful triggers include attempts to open protected resources, access account settings, reveal notifications, export data, change security configuration, disable Handoff Mode, or cross from an allowed application into an owner-only application. The security model should favor explicit authorization over speculative identity inference.
10. Permission Model
The owner should be able to construct reusable Handoff profiles. One profile might permit maps and music for a passenger. Another might permit a browser and telephone for a family member. A service profile could expose diagnostics needed by a repair technician while withholding personal data. An emergency profile would remain system-defined at its core but allow owner-approved emergency information.
Permissions should be expressed in terms understandable to ordinary users while mapping internally to application, file, sensor, account, notification, network, clipboard, credential, and inter-process communication controls.
11. Threat Model
The architecture addresses several distinct threats: casual privacy exposure when a device is voluntarily handed over; opportunistic exploration by a borrower; access attempts after loss or theft; disclosure through incoming notifications; credential leakage through browsers and autofill; unauthorized movement from an emergency interface into private applications; and attempts to disable the privacy boundary itself.
It does not make a compromised operating system, malicious firmware, or defeated hardware root of trust magically secure. Its strongest implementation therefore requires cooperation from the operating system and secure hardware rather than functioning only as a conventional application layered above them.
12. Fail-Safe Rules
Emergency communication must remain available even when owner authentication fails.
Emergency access must never imply access to owner data.
Handoff permissions must default to the minimum capabilities explicitly granted.
A failed biometric attempt must never be treated as owner authentication.
Security evidence must not be stored where the temporary user can delete or alter it.
Returning from Handoff or Emergency Mode to Owner Mode requires genuine owner authentication.
Restart, timeout, or abnormal state should fail toward privacy rather than toward broader disclosure.
The owner must be able to disable optional evidence-collection features independently of emergency access.
13. Example Use Cases
13.1 Borrowed Phone
An owner lends the phone to a stranger who needs to call for transportation. Handoff Mode exposes the dialer while messages, photographs, notifications, contacts, files, and accounts remain inaccessible. When the call ends, the session can automatically expire.
13.2 Navigation
A driver hands the phone to a passenger for navigation. Maps remains available, but private notifications are suppressed and the passenger cannot move from the navigation session into the owner's personal applications.
13.3 Emergency
An unconscious person's locked phone is found at an accident scene. Emergency Mode allows a bystander to contact emergency services and, if the owner has authorized it, view a limited emergency contact or medical card. No passcode is required for those emergency functions, and no private application becomes available.
13.4 Suspicious Access
A lost device enters a configured suspicious-access state. The device preserves a protected event record and, where lawful and enabled, captures available security evidence. A biometric prompt may be presented, but non-owner interaction cannot unlock private data. Emergency assistance remains available regardless.
14. Research and Prototype Questions
A prototype should determine which protections can be implemented at application level and which require operating-system privileges. Particular research questions include secure isolation of app data, suppression and deferred delivery of notifications, temporary identities for browsers and applications, emergency messaging interfaces, hardware-backed event logs, lawful camera capture, biometric subsystem limitations, owner-configurable disclosure policies, and resistance to mode escape.
Usability testing is equally important. A privacy architecture that is too difficult to activate will not be used; an emergency interface that is confusing can fail at the moment it matters most. Testing should therefore measure activation time, accidental disclosure, successful completion of permitted tasks, attempts to escape the restricted environment, and successful emergency communication under stress.
15. Distinction from Conventional Guest and Lock Modes
The proposal is broader than an application lock and more purpose-specific than a generic guest account. Its central object is the relationship among possession, identity, authorization, disclosure, and emergency need. Rather than asking only whether a user may enter the device, Secretary Suite asks what the device is permitted to reveal and do for this particular interaction.
That distinction allows the same physical phone to become a private owner environment, a deliberately constrained borrowed tool, or a minimal emergency instrument without treating those three situations as equivalent.
16. Conclusion
A smartphone should be shareable without requiring its owner to share a life. It should also remain useful in an emergency without converting emergency access into a privacy vulnerability. Identity-Aware Device Privacy and Emergency Access separates those requirements by treating physical possession, authorized identity, temporary utility, and emergency assistance as distinct states.
Secretary Suite's proposed Owner, Handoff, and Emergency Modes create a device-wide privacy boundary rather than a collection of unrelated application locks. Temporary-session isolation and notification filtering protect information during legitimate handoff. Minimal emergency capabilities preserve access to help. Optional, protected security-event records can document suspicious interaction without granting broader access.
The resulting principle is simple: a person may be allowed to use a device without being allowed to become its owner. Designing explicitly around that distinction can make personal devices simultaneously more private, more shareable, and more useful when they are needed most.
No comments:
Post a Comment