ViewBurn

Privacy Policy

1. Privacy Architecture Overview

ViewBurn is a burn-after-reading ephemeral message sharing tool that generates encrypted, single-use links for securely transmitting text and images. Our privacy model is built on a foundational architectural guarantee: all payload data is encrypted with AES-256-CBC before it touches persistent storage, and all encrypted files are destroyed immediately after the first successful recipient access or after 60 minutes of inactivity, whichever comes first. The encryption key is either embedded in the shareable URL (standard mode) or derived from a user-supplied password via PBKDF2 (password-protected mode). In neither case is the encryption key stored on our servers in any persistent form.

This privacy policy explains exactly what data ViewBurn processes, how that data is protected, how long it persists, and under what conditions it is destroyed. We believe privacy policies should be technically precise and verifiable, not legal abstractions.

2. Data Collection & Processing

ViewBurn processes data in two distinct categories:

2.1 User-Submitted Payload Data

When you generate a one-time link, the following content is transmitted to our server over HTTPS and stored temporarily in encrypted form:

  • Text content: The message body you type into the Text Container (up to 20,000 characters). Stored encrypted.
  • Image files: The visual assets you upload (up to 5 files, 5MB each; PNG, JPG, WebP, or AVIF). Stored as raw encrypted binary.
  • Configuration metadata: The permission mode (Read or Share), view count limits, password protection flag, and time-limit setting. Stored encrypted.

We do not collect, request, or retain: your name, email address, IP address (beyond what our web server temporarily logs, see Section 7), browser fingerprint, device identifiers, or any form of personally identifiable information.

2.2 Operational Metadata

For each generated link, our server maintains a lightweight metadata counter file containing only the following non-identifying fields: a view counter (integer), a maximum view limit (integer), a password-protection flag (boolean), and a creation timestamp (Unix epoch). This file contains no content, no user identifiers, and no IP addresses. It is destroyed alongside the encrypted payload.

3. Encryption Architecture

All payload data is encrypted before being written to disk. Our encryption pipeline uses industry-standard cryptographic primitives:

  • Cipher: AES-256 in Cipher Block Chaining (CBC) mode, as provided by the OpenSSL library via PHP’s openssl_encrypt() and openssl_decrypt() functions.
  • Initialization Vector: 128-bit (16-byte) cryptographically secure random IV generated via random_bytes() for each encryption operation. The IV is prepended to the ciphertext and stored as a single base64 blob.
  • Key Management (Standard Mode): A 256-bit (32-byte) random key is generated server-side. The plaintext payload is encrypted with this key. The key is embedded in the shareable URL as a base64-encoded query parameter and is never written to persistent storage. It exists only in the generated URL string and the recipient’s browser memory during the brief decryption window.
  • Key Management (Password-Protected Mode): The encryption key is derived from the user-supplied passphrase using PBKDF2 with SHA-256 at 100,000 iterations and a 128-bit random salt. The salt is stored alongside the ciphertext. The derived key itself is never stored or logged; it is recomputed on demand when the recipient enters the correct password.

What this means for server-side visibility: An attacker or administrator with full access to our server filesystem would see only opaque base64 strings — random-looking ciphertext, salts, and encrypted payloads with no structural metadata revealing their original content type. The encryption keys exist either in URLs (which are not server-logged beyond standard web server access logs) or solely in the minds of users who set passwords. Even in the unlikely event of a complete server compromise, encrypted payloads cannot be decrypted without the corresponding keys.

4. Data Storage & Retention Windows

Encrypted payload data is stored temporarily in three directories on our server filesystem:

  • burn/data/<id>.json — Encrypted message payload (ciphertext + IV + optional salt).
  • burn/images/<id>/<n> — Raw encrypted image binary files.
  • burn/meta/<id>.json — View counter and configuration metadata.

4.1 Maximum Retention: 60 Minutes

Every encrypted payload file is guaranteed to exist on our server for no longer than 60 minutes from its creation timestamp, regardless of whether the recipient ever opens the link. A system-level cron daemon executes every 3 minutes, scanning all storage directories and unconditionally deleting any file whose modification time exceeds 3,600 seconds (60 minutes) from the current server time. This is a hard, automated, non-overridable limit enforced at the operating system level.

4.2 Minimum Retention: Variable (Read-Dependent)

Encrypted files may be destroyed significantly sooner than the 60-minute maximum, depending on access patterns:

  • First successful recipient access: The millisecond the recipient’s browser successfully fetches and decrypts the linked payload, the server executes unlink() on the encrypted JSON file and recursively deletes the associated image subdirectory and metadata counter. The link becomes a permanently dead URL.
  • Sender-initiated manual burn: The sender may click “Burn Now” at any time after link generation, sending an AJAX request that triggers the same immediate file deletion sequence regardless of whether any recipient has viewed the content.
  • View limit exhaustion: If the sender configured a maximum view count greater than 1, the files are deleted only when the view counter reaches the configured limit. Until that point, the encrypted data persists (subject to the 60-minute absolute cap).
  • Time-limit expiration: If a time limit was set, the recipient’s browser enforces a client-side countdown. When it reaches zero, the page force-reloads; the server checks the metadata counter and deletes the files if the limit has been reached.

5. Destruction Logic & Irreversibility

All three destruction pathways execute the same irreversible sequence:

  1. The encrypted JSON payload file is deleted via PHP’s unlink(), which removes the file from the filesystem index and marks its disk blocks as free space. No backup, snapshot, recycle bin, or recovery mechanism exists at any layer of our infrastructure.
  2. The image subdirectory (if any images were uploaded) is recursively deleted — each image file is individually unlinked, then the parent directory is removed via rmdir().
  3. The metadata counter file is deleted via unlink().
  4. The URL becomes permanently inert. Any subsequent request to the same link ID triggers a server-side check: if the encrypted payload file no longer exists, the server responds with the burned page (“this note has been permanently destroyed”).

Deletion is irreversible. We maintain no database tables, no replication streams, no point-in-time snapshots, no write-ahead logs retaining deleted data, and no off-site backup copies of burn directory contents. Once a file is unlinked, its content is irrecoverable by us or by any third party.

6. Data We Explicitly Do Not Collect

To eliminate ambiguity, we affirmatively state that ViewBurn does not:

  • Collect, log, or store your IP address in association with any generated link or payload.
  • Collect your browser’s User-Agent string, screen resolution, installed fonts, or any other fingerprintable attribute in connection with payload data.
  • Store plaintext (unencrypted) message content or image data at rest at any point. The plaintext exists only ephemerally: on the sender’s side, in the sender’s browser memory during the FormData POST construction; on the server side, only for the duration of the openssl_encrypt() call (microseconds); on the recipient’s side, in the recipient’s browser memory during and immediately after page rendering.
  • Require, create, or maintain user accounts, authentication credentials, or session tokens.
  • Send email notifications, SMS alerts, or any form of outbound communication about link access.
  • Embed tracking pixels, web beacons, or third-party analytics in the encrypted content rendering pages (recipient-side views).
  • Retain any data after the destruction pathways described in Section 5 have executed.

7. Web Server Access Logs

Our web server (nginx) maintains standard HTTP access logs for operational purposes, including request path, HTTP status code, response size, and client IP address. These logs are not correlated with generated link IDs, encrypted payload files, or any user-submitted content. Access logs are automatically rotated and purged on a standard retention schedule. They are used exclusively for aggregate traffic analysis, abuse detection (e.g., volumetric DDoS patterns), and server diagnostics.

Importantly: the encryption key parameters (?key=... in standard mode URLs) appear in server access logs as part of the requested URL path. This is a known trade-off of URL-based key transmission. Users requiring stronger confidentiality should use the password-protected mode, in which the encryption key is never transmitted in any URL and therefore never appears in server logs.

8. Google Analytics 4 (GA4)

ViewBurn uses Google Analytics 4 (GA4) for lightweight aggregate traffic measurement on our public-facing informational pages (homepage, about/development diary, team page, and privacy policy). The GA4 script collects: page view counts, approximate session duration, country-level geographic distribution (from anonymized IP prefixes), browser type, and device category.

GA4 is explicitly excluded from: the recipient content rendering pages (the pages that display your encrypted messages), the password entry page, the “burned” page, and any endpoint that handles payload generation or decryption. No user-submitted content, link IDs, encryption keys, or view counter data is transmitted to Google Analytics under any circumstances.

You may block GA4 entirely through your browser’s privacy settings, an ad-blocking extension, or Google’s official Analytics Opt-out Browser Add-on. Blocking GA4 has zero impact on any ViewBurn functionality.

9. External Dependencies

The ViewBurn application loads the following external resources during initial page load on informational pages only (not on encrypted content rendering pages):

  • Google Fonts (fonts.googleapis.com) — Inter, JetBrains Mono, and Sora typeface files.
  • Google Material Symbols (fonts.googleapis.com) — Interface iconography.
  • GA4 measurement script (googletagmanager.com) — Anonymous traffic analytics (informational pages only).

None of these services receive any user-submitted content, encryption keys, link identifiers, or payload data. All core tool functionality — payload encryption, link generation, content rendering, image processing, and file destruction — operates exclusively with our server-side PHP code and client-side JavaScript with no third-party API dependencies.

10. Transport Layer Security

ViewBurn is served exclusively over HTTPS (HTTP over TLS). All data transmitted between your browser and our server — including encrypted payloads during POST upload and GET retrieval — is encrypted in transit under the negotiated TLS cipher suite. We enforce HTTP Strict Transport Security (HSTS) headers, instructing compatible browsers to refuse any plaintext HTTP connection to the domain.

11. Children’s Privacy

ViewBurn does not collect personal information from any user of any age. We maintain no user accounts, request no identifying information, and process all payload data in encrypted form with automatic destruction. Our service is inherently compliant with COPPA (15 U.S.C. §§ 6501–6506) and analogous international child privacy frameworks.

12. International Data Protection Compliance

Because ViewBurn encrypts all payload data at rest with keys that are never persistently stored, automatically destroys all data within 60 minutes, and collects no personal user information, we operate outside the substantive scope of GDPR (EU 2016/679), CCPA/CPRA (Cal. Civ. Code §§ 1798.100–1798.199.100), LGPD (Brazil Law No. 13,709/2018), and PIPEDA (Canada S.C. 2000, c. 5). The encrypted payloads we temporarily store are not “personal data” as defined by these regulations because they are cryptographically unintelligible without keys that we do not possess.

13. Policy Changes

We may update this privacy policy to reflect changes in our technical architecture, encryption methods, data retention windows, or external dependencies. Material changes that reduce privacy protections or introduce new forms of data collection will be prominently announced on our homepage with a minimum 30-day notice period before taking effect.

14. Contact & Security Disclosures

For privacy inquiries, technical clarifications about our encryption pipeline, or reports of potential security vulnerabilities:

Email: [email protected]

We prioritize cryptographic vulnerability reports. Expect acknowledgment within 5 business days.

Last updated: June 07, 2026