ViewBurn
Project Overview
ViewBurn is developed and maintained by the 345tool Engineering Collective, an independent group of privacy-focused software engineers building lean, client-side utilities for the open web. Our development philosophy rejects feature bloat, account-based authentication, and server-side data persistence. Every feature in ViewBurn must satisfy one inviolable constraint: the server must hold zero recoverable plaintext and must destroy its encrypted payloads absolutely.
This development diary documents the major architectural milestones, security upgrades, and operational improvements that define each release. We maintain full transparency in our build process because trust in ephemeral communication tools must be verifiable, not assumed.
The project core was conceived in May 2026 as a response to the growing need for truly disposable, one-time communication channels that require no accounts, no logins, and leave no digital exhaust. Since then, the tool has evolved from a basic text-and-image burner into a multi-layered encryption vault with enterprise-grade security parameters.
v2.0 — Encryption & Enterprise Controls
Released: June 07, 2026
AES-256-CBC Payload Encryption
The most significant architectural upgrade in ViewBurn’s history. In v1.x, payload data existed as plaintext JSON files on the server filesystem during the brief window between link generation and recipient access. While the window was small (60 minutes maximum, with instant deletion on first read), the plaintext storage represented an unacceptable theoretical vulnerability.
v2.0 introduces full AES-256-CBC symmetric encryption with cryptographically secure random initialization vectors (IVs) and distinct key derivation strategies based on operational mode:
- Standard Mode (No Password): A 256-bit random key is generated server-side, used to encrypt the payload, then embedded in the shareable URL as a base64-encoded query parameter. The key never touches persistent storage — it exists only in the generated URL string and the recipient’s browser memory during the brief decryption window.
- Password-Protected Mode: The encryption key is derived from the user-supplied passphrase using PBKDF2 with SHA-256 at 100,000 iterations plus a 128-bit random salt. The salt is stored alongside the ciphertext. The key itself is never stored, derived, or transmitted — only the recipient who knows the password can reconstruct it.
All ciphertext, salts, and IVs are stored as base64 blobs with no structural metadata exposing the original content type. An attacker with full server access would see only opaque binary strings.
Custom Password Vaulting (Secondary Encryption)
Building on the AES infrastructure, we added an optional secondary encryption layer controlled entirely by the sender. When enabled, the recipient encounters a password gate before the decryption engine initializes. Incorrect password attempts return a generic “Incorrect password” response with no diagnostic information, eliminating oracle-based brute-force vectors.
The password unlock endpoint uses an AJAX-based challenge flow. The PBKDF2 key derivation runs server-side, and only on success does the browser redirect with the decryption key appended to the URL for the remaining session. This ensures the key is never exposed in the DOM or network tab until the moment of successful authentication.
Multi-View Counters & Time-Limit Self-Destruct
v1.x was strictly single-use: one view, then destruction. v2.0 introduces configurable multi-view persistence and time-bound access windows:
- Max View Counters: Senders can set a precise integer (1–9,999) defining the exact number of permitted views before the encrypted payload is permanently deleted. A separate metadata counter file tracks each access, and the file system wipe triggers only when the counter equals the limit.
- Countdown Time Limits: An independent time-to-live (TTL) parameter (1–1,440 minutes) enforces an absolute expiration. The recipient’s browser initiates a client-side countdown on page load. When the timer reaches zero, the page force-reloads — at which point the server checks the metadata counter and either re-renders the content (if views remain) or displays the permanent destruction page (if the limit is reached or the payload has been independently purged by the cron cleanup daemon).
- Read Receipts: The sender’s dashboard polls a lightweight status endpoint every 3 seconds, updating a live view counter and automatically hiding the link display when the view limit is exhausted.
v1.0 — Core Burn After Reading Engine
Released: May 25, 2026
Dual-Container Isolation Architecture
The foundational architecture separates text and images into completely independent transmission and rendering pipelines. This design decision was driven by two security principles:
- No Cross-Data Pollution: Text content never enters the image processing pipeline, and image binary data never touches the text DOM container. Each data type has its own storage subdirectory (
burn/data/for encrypted JSON payloads,burn/images/<id>/for raw binary image files), and they are independently deleted on burn. - Per-Container Permission Controls: The Read Mode and Share Mode permission gates are applied granularly: the text container and image container each respect their mode independently, allowing future expansion to mixed-mode scenarios without architectural refactoring.
Read Mode & Share Mode Permission System
The permission firewall was designed from day one to enforce hardware-level content protection:
- Read Mode (Default): Text renders with
user-select: none, right-click context menu suppression, and Ctrl+C / Cmd+C keyboard interception. Images bypass the HTML<img>tag entirely, rendering on isolated Canvas elements withpointer-events: noneand blocked context menus. No standard browser mechanism can extract the visual content. - Share Mode: Text container appends a “Copy All Text” button at its base. Each image receives a dedicated “Download Image” button beneath its preview, saving metadata-free PNG files via blob URL download triggering.
Self-Destruct & Cron Auto-Purge
Three independent destruction pathways ensure zero persistent data:
- Recipient-Side Instant Wipe: On the first successful page render, the PHP backend executes
unlink()on the encrypted payload JSON and recursively deletes the image subdirectory before any HTML is sent to the browser. The recipient receives content that no longer exists on disk. - Sender-Side Manual Burn: A “Burn Now” button sends an AJAX request to the
?burn=<id>endpoint, triggering immediate file deletion regardless of view count. - Cron Daemon Stale Cleanup: A PHP CLI script (
cron.php) runs every 3 minutes via system scheduler, scanning payload, image, and metadata directories for files with modification timestamps older than 60 minutes. Orphaned files from interrupted uploads are also swept.
Upcoming Roadmap
Client-Side Image Compression: Optional Canvas-based image resizing and compression before upload, reducing transmission times for large assets while preserving visual quality.
Burn Confirmation Dialog: A secondary confirmation modal before executing manual burn operations, preventing accidental irreversible deletions.
Precise View Timestamps: Per-view UTC timestamp recording in metadata, enabling senders to see exactly when each access occurred, not just the count.
Multi-Language i18n Support: Interface localization for non-English-speaking users, starting with Chinese, Spanish, and Japanese.
Contact the Engineering Team
ViewBurn is actively maintained and we welcome security disclosures, feature proposals, and integration inquiries from developers, security researchers, and enterprise architects.
Email: [email protected] — We prioritize responses to cryptographic vulnerability reports and data integrity concerns.
We are the 345tool Team
345tool is an independent developer collective engineering elite, pure client-side, and privacy-first web utilities to replace bloated internet tools.