Security Architecture & Data Lifecycle
A factual disclosure of VeilPair transport security, server-readable storage, retention behavior, IP handling boundaries, and current limitations.
Data Collection & Storage
VeilPair is not a zero-knowledge or end-to-end encrypted system. HTTPS and WSS protect data in transit, while the application server processes and stores the data needed to operate the service. The table below describes the current implementation:
| Data Category | Collected? | Storage Mechanism | Retention Period |
|---|---|---|---|
| Guest and Pseudonymous Accounts | Yes | Guest identifier; optional username and bcrypt password hash in the application datastore | No automatic account-deletion schedule is currently implemented |
| Temporary Room Messages | Yes (ephemeral) | Server memory and the persisted application datastore | Unsaved rooms: 24-hour sliding expiration; saved rooms: retained until manual destroy or future retention enforcement |
| Contact Cards (Exchanged in Room) | Yes (in room) | Attached to temporary room state | Same lifecycle as the containing conversation |
| IP Addresses | Processed | In-memory rate limiters and in-memory daily truncated IP-derived visitor hashes; infrastructure may process request logs | IP-derived keys are not attached to room records; infrastructure retention has not been independently audited here |
| Product Analytics | Yes (first-party aggregate) | Persisted daily aggregate counts for paths, languages, referrers, events, and unique visitors; the per-visitor hashes remain in memory | Persisted in the application datastore; no automatic retention limit is currently implemented |
| Ad Trackers / Third-party Pixels | No | None | None |
Data Lifecycle & Destruction
The current application enforces the following lifecycle:
- 24-Hour Sliding TTL: Unsaved rooms automatically expire 24 hours after the most recent message.
- Saved Conversations: If a registered participant saves a room, automatic expiration is skipped. No general retention period is currently enforced for saved rooms.
- Manual Destroy: Either participant can remove the conversation from active application storage. Restricted infrastructure backups may retain an older copy until normal backup rotation.
- Close: Closing stops further messaging but is not the same operation as immediate destruction.
- Rate Limit Cleanup: Rate-limiting entries in memory automatically expire and are purged periodically.
IP Logging Policy
VeilPair does not attach raw IP addresses to application-level room or message records.
IP addresses are processed for rate limiting and are used with the date and an application salt to create a truncated daily visitor hash for aggregate analytics. Reverse proxies, hosting infrastructure, and security systems may also process IP addresses and request metadata. Their exact retention behavior is an operational dependency and is not claimed as zero logging.
Encryption and Trust Boundary
- In transit: Production traffic uses HTTPS and WSS.
- At the application layer: Messages and contact cards are readable by the server so they can be relayed and persisted.
- At rest: The JSON datastore is not application-level end-to-end encrypted. Host/VPS controls and restricted file permissions are part of the operational security boundary.
- Client sessions: Product bearer tokens are stored client-side and currently expire after 7 days for guests or 30 days for registered accounts.
Users should not treat VeilPair as protection against a compromised server, compromised endpoint, malicious participant, screenshots, or copying after voluntary disclosure.