Privacy Policy

This notice covers the VeilPair service at veilpair.com. The service is operated by the VeilPair service team on Hostinger infrastructure. A separate legal-entity name and postal address are not published in this MVP.

Privacy questions, access/deletion requests, security disclosures, and complaints can be submitted through the feedback and safety form. Do not include passwords, bearer tokens, private-room URLs, or unnecessary message content.

• Guest use: a random guest identifier, last activity timestamp, and an HMAC-derived restore verifier.
• Optional pseudonymous account: username, bcrypt password hash, account identifier, and timestamps. Real name, email, and phone number are not required for account creation.
• Handoff records: endpoint slug, title, optional source context, owner identifier, expiry, request limits, and status.
• Pairing requests: requester/owner identifiers, human-readable code, timestamps, status, and resulting conversation identifier when accepted.
• Conversations: participant identifiers, messages (encrypted at rest), contact cards voluntarily shared by participants (encrypted at rest), labels, timestamps, save state, close state, and expiration.

• Feedback and safety reports: category, message (encrypted at rest), optional reply email (encrypted at rest), optional public session reference, timestamp, status, and a truncated salted IP-derived hash. Feedback is operator-readable by authorized administrators for safety review and support.
• First-party analytics: daily aggregate page views, unique-visitor counts, sanitized path buckets, languages, coarse acquisition categories (for example direct, search, AI assistant, social, or other referral), endpoint/pairing/message/contact counts, and contact types are persisted. Raw referrer URLs, URL queries, UTM campaign/content/term values, AI prompts, and private route identifiers are not persisted as analytics. A truncated daily IP-derived value is held in memory to count unique visitors and expires after approximately 2 days.
• Rate limiting: IP-based keys are processed in memory to control abuse and expire with their rate-limit windows.
• Infrastructure: Hostinger, reverse proxies, TLS termination, operating-system services, and security systems necessarily process IP addresses, timestamps, user agents, and connection metadata to operate the network.

Data is processed to create guest or optional pseudonymous accounts, operate handoff links and pairing requests, relay and securely store conversations, share participant-selected contact cards, prevent abuse, maintain security, provide support, measure aggregate service usage, and comply with applicable legal obligations.

Depending on applicable law and the specific activity, processing may be necessary to provide the service requested by the user, protect the service and its users, respond to consent-based optional submissions, or meet legal obligations. VeilPair does not claim a jurisdiction-specific legal basis beyond what can be supported for the relevant user and operator.

Record Type	Technical Retention Rule
Temporary endpoint link	Configured lifetime (default 24 hours); purged from storage after a 24-hour grace period upon expiry or revocation
Pending pairing request/code	15-minute pending window; expired or resolved records are cleaned automatically
Unsaved conversation / messages / contact cards	24-hour sliding inactivity expiration calculated from the most recent activity
Saved conversation (Vault)	Exempt from automatic inactivity expiration; retained until destroyed by a participant or deleted under account rules
Guest user identity	Removed after 7 days of inactivity when no retained data dependencies require the identity to remain
Product session (Authentication)	7 days for guest sessions, 14 days for registered accounts; immediately revocable upon logout
Feedback & safety reports	Encrypted at rest under a dedicated key; retained for 90 days
Aggregate analytics	Persisted daily aggregates retained for 365 days; in-memory unique visitor hashes expire after ~2 days

• Close: stops further messaging but retains the room in active storage until expired or destroyed.
• Destroy Room: removes the conversation record, encrypted messages, shared contact data, and wrapped conversation key from the active datastore for both participants.
• Automatic expiration: removes unsaved conversations after the sliding 24-hour window, and inactive guests after 7 days when no retained data dependencies require the identity to remain.
• Backups: operational backups follow separate access-control and retention procedures. Deletion from the active datastore does not imply immediate deletion from historical backups. Historical backups may remain recoverable while the corresponding historical encryption keys remain available.

The product stores its bearer authentication token and guest/user state in browser storage so sessions can resume. Product tokens are backed by server-side revocable sessions that expire after 7 days for guests and 14 days for registered accounts. Sessions are immediately invalidated on the server when a user logs out.

The separate Admin application uses a Secure, HttpOnly, SameSite cookie. Admin traffic is excluded from product analytics.

Hostinger supplies the VPS, network, backup, and related infrastructure used to operate VeilPair. Data may therefore be processed in infrastructure locations outside a user's country. VeilPair does not sell or rent private conversation content or contact cards.

We may disclose information when required by applicable law, valid legal process, or to protect the safety of users or the public. Contact details voluntarily shared with another participant leave VeilPair's control once that participant copies, exports, or screenshots them.

VeilPair does not embed Meta Pixel, Google Analytics, third-party advertising pixels, or cross-site advertising fingerprinting in private rooms. It operates first-party aggregate analytics only. Private conversation content is never used for advertising.

Production transport uses HTTPS/WSS (TLS). Message text and shared contact cards are encrypted at rest using server-managed envelope encryption (AES-256-GCM) with unique per-conversation keys. VeilPair is NOT end-to-end encrypted (E2EE) and NOT zero-knowledge: the server decrypts messages during authorized delivery and retains technical decryption capability. No service can guarantee complete anonymity, participant honesty, or protection against screenshots, compromised user devices, or voluntary copying after disclosure.

Depending on applicable law, users may have rights to request access, correction, deletion, restriction, portability, objection, or review of certain processing. Submit a request through the feedback form and include only the minimum information needed to identify the relevant record. VeilPair may need to verify control of an account or record before responding.

VeilPair's Terms set a minimum age of 18. The service is not intentionally directed to children.

Material changes should be reflected by updating this page's date and, where appropriate, by a notice in the service. This notice describes the implementation as updated on 1 September 2026 and should be revised whenever storage, analytics, authentication, providers, or retention behavior changes.