This document defines the explicit scope of ASH version 1.
Its purpose is to:
- prevent scope creep
- preserve security guarantees
- align contributors (human or AI)
- act as a reference during reviews and decisions
If something is not listed here, it is out of scope.
This document must be read together with:
architecture.mdthreat-model.md
ASH is a secure, ephemeral messaging application designed for high-security, low-frequency communication.
ASH prioritizes:
- correctness over convenience
- human-verifiable security
- minimal trust in infrastructure
- deliberate user actions
- clarity over speed
ASH is not designed for everyday chat.
- One-Time Pad (OTP) only
- No key escrow
- No key recovery
- No crypto agility
- No silent background behavior
- No hidden persistence
- No reliance on backend trust
If any feature weakens these principles, it is out of scope.
The shared Rust core is the single source of truth for ASH’s security model.
It is used by:
- the iOS application
- the backend (where applicable)
- tests and verification tools
The shared core is responsible for:
- One-Time Pad generation and consumption
- Strict enforcement of pad non-reuse
- OTP encryption and decryption
- Ceremony rules (chunking, ordering, invariants)
- Frame encoding and decoding with integrity checks
- Human-verifiable mnemonic checksum generation
- Deterministic, testable behavior across platforms
- Best-effort memory wipe utilities
The shared core must never:
- access the network
- access OS randomness directly
- store data on disk
- contain UI logic
- contain platform-specific code
- make policy decisions
- include analytics or logging
The shared core must remain:
- small
- auditable
- deterministic
- stable once reviewed
- Offline device-to-device ceremony
- QR code–based transfer of random pad bytes
- Chunked frame transfer with integrity validation
- Human-verifiable mnemonic checksum
- Restart-only failure handling (no partial recovery)
The ceremony must:
- be explicit
- be visible to the user
- require deliberate participation
- One-to-one conversations only
- Text messages
- One-shot location messages
- Lat/long with 6 decimal places (~10cm precision)
- No altitude, speed, or heading
- Ephemeral message lifecycle
- Automatic message disappearance after read / time
- Manual "burn" action that irreversibly wipes conversation state
- SwiftUI-based iOS application
- Thin orchestration layer around shared Rust core
- Clear, minimal UI
- Limited visible message history
- Dynamic Type and accessibility support
- Reduced motion support
- Explicit user actions (no background automation)
The iOS app must never:
- reimplement cryptography
- modify security logic
- bypass the shared core
- invent alternative checksums or encryption
- silently persist decrypted data
The backend is a dumb relay with a clock.
It exists only to:
- relay encrypted message blobs
- relay burn signals
- notify devices via silent push notifications
The backend:
- does not decrypt data
- does not understand message contents
- does not identify users
- does not authenticate identities
- does not store data long-term
Backend characteristics:
- implemented in Rust
- stateless or ephemeral storage only
- strict TTL-based cleanup
- HTTPS only
- minimal API surface
The backend must never:
- store plaintext
- perform cryptographic operations on messages
- enforce business logic
- track users or behavior
- provide guarantees beyond best-effort delivery
- Static website only
- Educational and explanatory content
- Explanation of ceremony and security model
- Ethical use statement
- Privacy posture
- No analytics
- No tracking
- No user accounts
- No interactivity beyond simple demos
- Group chats
- Channels
- Threads
- Reactions
- Media messages (images, video, audio)
- Stickers, emojis beyond system defaults
- User accounts
- Phone number registration
- Email login
- Contacts integration
- Identity recovery
- Username systems
- End-to-end encryption other than OTP
- Key exchange protocols
- Key derivation functions
- Cloud key storage
- Bluetooth-based pairing
- Wi-Fi Direct pairing
- Background syncing
- Android application (planned for future)
- Web application
- Desktop application
- VisionOS / watchOS support
- External plugins
- SDKs for third parties
- Multi-region backend
- High availability guarantees
- Load balancing
- Analytics pipelines
- Crash reporting SDKs
- User metrics or tracking
- Monetization
- Subscriptions
- Ads
- Growth features
- Marketing campaigns
- Virality mechanics
ASH does not aim to:
- be convenient
- be fast
- be social
- be anonymous at the network level
- defeat a compromised operating system
- defeat a physically compromised device
- provide plausible deniability against a determined forensic adversary
ASH aims to:
reduce attack surface, reduce mistakes, and make security properties understandable to humans.
- This document may only be changed deliberately.
- Any change requires:
- a written rationale
- explicit acknowledgment of tradeoffs
- review of security impact
Silent scope expansion is not allowed.
If a future feature conflicts with this document,
this document wins.
ASH succeeds by doing less, not more.