Security through architecture,
not promises.
VaultBook doesn't ask you to trust our servers — there are none. Your data never leaves your device, and every security measure operates locally under your control.
1. Security Philosophy
Most applications ask you to trust that their servers are secure, that their employees won't access your data, and that their infrastructure won't be breached. VaultBook takes a fundamentally different approach: we eliminate the need for trust by eliminating the server.
VaultBook's security model is based on three principles:
This page documents, in detail, how these principles are implemented across every layer of VaultBook's design — from cryptographic primitives to file system permissions to session management.
2. Architecture & Attack Surface
2.1 Single-file application
VaultBook is distributed as a single, self-contained HTML file. All application code (JavaScript), styles (CSS), and bundled libraries are embedded directly within this file. There is no installer, no background service, no daemon, and no system-level process. The Application runs inside a standard browser tab.
2.2 No server-side component
VaultBook has no backend server, no API endpoints, no database server, and no cloud infrastructure. This architectural decision eliminates entire categories of security threats that affect traditional web applications:
| Threat category | Applies to VaultBook? |
|---|---|
| Server-side data breaches | ✕ No server |
| SQL injection / NoSQL injection | ✕ No database |
| API key leakage or abuse | ✕ No API |
| Man-in-the-middle attacks on user data | ✕ No transmission |
| Server-side request forgery (SSRF) | ✕ No server |
| Credential stuffing / brute-force login | ✕ No accounts |
| Privilege escalation via authentication bypass | ✕ No auth layer |
| Third-party analytics / tracking data harvesting | ✕ No analytics |
| Cloud provider infrastructure compromise | ✕ No cloud |
| DNS hijacking of application endpoints | ✕ No endpoints |
2.3 Minimal attack surface
VaultBook's attack surface is limited to the local runtime environment: the browser's JavaScript engine, the File System Access API, and the integrity of the HTML file itself. This is a dramatically smaller surface than any cloud-connected application, and all residual risks are addressed in the sections below.
3. Encryption
3.1 Algorithm
VaultBook Pro uses AES-256-GCM (Advanced Encryption Standard with 256-bit keys in Galois/Counter Mode) for per-entry encryption. AES-256-GCM is an authenticated encryption algorithm, meaning it provides both confidentiality (data cannot be read without the key) and integrity (any tampering with the ciphertext is detected upon decryption).
AES-256-GCM is the gold standard for symmetric data-at-rest encryption. It is used by governments, financial institutions, and security-critical applications worldwide. The 256-bit key length provides a security margin that is considered resistant to all known classical and quantum computing attacks for the foreseeable future. GCM mode adds authentication, ensuring that if even a single bit of ciphertext is altered, decryption will fail — preventing silent data corruption or manipulation.
3.2 Per-entry granularity
Encryption in VaultBook is applied at the individual entry level, not globally. This means you can choose exactly which entries to protect with encryption, leaving others unencrypted for faster access. Each encrypted entry can have its own unique password, allowing you to compartmentalize sensitive information with independent access controls.
3.3 Cryptographic parameters
Every encryption operation generates fresh cryptographic parameters to ensure that no two encrypted entries share key material, even if the same password is used:
| Parameter | Value | Purpose |
|---|---|---|
| Salt | 16 bytes, cryptographically random | Ensures identical passwords produce different derived keys across entries |
| Initialization vector (IV) | 12 bytes, cryptographically random | Ensures identical plaintext produces different ciphertext across encryptions |
| Key length | 256 bits | Maximum key strength for the AES family |
| Authentication tag | 128 bits (GCM default) | Detects any tampering or corruption of the ciphertext |
The salt and IV are generated using the browser's crypto.getRandomValues() API, which provides cryptographically secure pseudorandom numbers sourced from the operating system's entropy pool.
4. Key Derivation & Password Handling
4.1 PBKDF2 key derivation
VaultBook derives encryption keys from your passwords using PBKDF2 (Password-Based Key Derivation Function 2) with the following parameters:
| Parameter | Value |
|---|---|
| Hash function | SHA-256 |
| Iteration count | 100,000 |
| Output key length | 256 bits |
| Salt | 16 bytes, unique per entry |
The high iteration count (100,000) is deliberately chosen to make brute-force and dictionary attacks computationally expensive. Each guess an attacker makes requires running the full PBKDF2 derivation with 100,000 rounds of SHA-256, making large-scale password cracking impractical against reasonably strong passwords.
4.2 Password storage — there is none
VaultBook never stores your encryption passwords in any form — not in plaintext, not as a hash, not in an encrypted vault, and not in browser storage. Passwords exist only in memory during the active session and are discarded when the tab closes or you navigate away.
4.3 Session password cache
For usability, VaultBook caches decrypted passwords in JavaScript runtime memory during an active session, so you are not prompted to re-enter a password each time you revisit an encrypted entry within the same session. This cache is held exclusively in the browser's heap memory and is released when the tab is closed, the page is refreshed, or the lock screen is activated.
The session cache is a convenience feature, not a security bypass. If you step away from your computer, use VaultBook's lock screen to clear the visual display and block interactions. For maximum security, close the browser tab entirely to purge all in-memory data including cached passwords.
4.4 Password recovery — not possible
Because passwords are never transmitted to or stored by VaultBook Labs, we have absolutely no ability to recover, reset, or retrieve a lost encryption password. If you forget the password for an encrypted entry, the encrypted data is permanently inaccessible. We strongly recommend keeping secure, independent records of your encryption passwords.
5. Data at Rest
5.1 Storage location
All VaultBook data is stored in a local folder on your device that you explicitly select through the browser's File System Access API permission dialog. VaultBook does not use localStorage, sessionStorage, IndexedDB, or cookies for persistent data storage. This means your data resides in regular files on your file system, fully under your control and fully visible to your operating system's file management tools.
5.2 File formats
VaultBook stores data exclusively in standard, human-readable file formats:
| File | Format | Security note |
|---|---|---|
repository.json |
JSON | Contains page hierarchy, entry metadata, and vote data. Encrypted entry bodies are stored as ciphertext within this file or in sidecar files. |
details-*.md |
Markdown / HTML | Entry body content. Encrypted entries store ciphertext here; the plaintext is never written to disk. |
index.txt |
JSON | Attachment manifest mapping keys to file metadata. |
license.json |
JSON | License tier and activation status. Validated locally; never transmitted. |
/versions/* |
JSON / Markdown | Version snapshots. Automatically pruned after 60 days. |
/attachments/* |
Original formats | Files you attach retain their original format. Attachment content is indexed locally for search. |
5.3 Disk-level encryption recommendation
For users who want full-disk encryption beyond VaultBook's per-entry encryption, we recommend enabling your operating system's built-in disk encryption: BitLocker on Windows, FileVault on macOS, or LUKS on Linux. This provides an additional layer of protection for all files on your device, including your VaultBook Workspace, in the event of physical device theft or loss.
6. Data in Transit
6.1 Application: no transit
The VaultBook Application makes zero network requests during its entire lifecycle. From the moment you open the HTML file to the moment you close the browser tab, no data is sent or received over any network connection. There is no telemetry, no analytics ping, no license check, no update poll, and no background sync. This is verifiable using your browser's Network DevTools tab.
Open your browser's Developer Tools (F12 or Cmd+Shift+I), switch to the Network tab, and use VaultBook normally. You will observe zero network requests. This is the most transparent security guarantee we can offer — you can confirm it independently at any time.
6.2 Website & downloads
The VaultBook Website and download links are served over HTTPS via GitHub Pages, providing TLS encryption for all data in transit between your browser and GitHub's servers. Download integrity can be verified by comparing the file hash against published checksums.
7. Browser Sandbox & Isolation
7.1 Browser security model
VaultBook runs inside the browser's security sandbox, which provides robust isolation from your operating system and other browser tabs. The browser sandbox enforces memory isolation (each tab runs in its own process), prevents direct file system access (except through explicitly granted APIs), and blocks cross-origin data leakage.
7.2 Same-origin policy
Because VaultBook runs from a local file:// URI or a trusted origin, it is subject to the browser's same-origin policy. This prevents other websites or browser tabs from accessing VaultBook's in-memory state, DOM content, or File System Access API handles.
7.3 Content Security Policy
VaultBook operates as a self-contained file with no external resource loading. All JavaScript, CSS, fonts, and library code are embedded inline. This inherently prevents cross-site scripting (XSS) via external script injection, as there are no external scripts to inject or tamper with.
7.4 No eval or dynamic code execution
VaultBook does not use eval(), Function() constructors, or innerHTML with unsanitized user input for code execution. Rich text content is rendered through controlled DOM manipulation and sanitized rendering paths.
8. File System Access & Permissions
8.1 Explicit user consent
VaultBook accesses your file system exclusively through the browser's File System Access API, which requires explicit user consent via a native operating system dialog. You choose which folder VaultBook can read from and write to. The browser does not grant VaultBook access to any other folder, file, or directory on your system.
8.2 Scoped permissions
File System Access API permissions are scoped to the specific directory you select and its subdirectories. VaultBook cannot read, write, or enumerate files outside this scope. Permissions are also tab-scoped — they do not persist across browser tabs or sessions unless you explicitly re-grant access.
8.3 Permission revocation
You can revoke VaultBook's file system access at any time by closing the browser tab, clearing site permissions in your browser settings, or simply declining the permission prompt on your next visit. Revoking access does not affect your files — they remain on disk in their original formats.
9. Lock Screen & Session Protection
9.1 Visual lock
VaultBook includes a lock screen feature that instantly applies a full-page Gaussian blur overlay across the entire interface. When active, the lock screen blocks all pointer events (clicks, scrolls, drags), disables text selection, and prevents visual access to any displayed content.
9.2 Activation
The lock screen can be activated manually when you step away from your device. It provides immediate visual protection against casual observation — sometimes called "shoulder surfing" — without requiring you to close VaultBook or lose your session state.
9.3 Limitations
The lock screen is a visual protection measure, not a cryptographic barrier. It does not encrypt in-memory data, and a technically sophisticated user with access to your device could potentially inspect browser memory or use Developer Tools to view application state. For situations requiring stronger protection, close the browser tab entirely to purge all in-memory data, or use your operating system's native screen lock.
10. Version History & Recovery
10.1 Automatic snapshots
VaultBook automatically creates version snapshots of your entries as you work. These snapshots are stored in the /versions directory within your Workspace and provide a safety net against accidental edits, deletions, or data corruption.
10.2 Retention & pruning
Version snapshots are retained for 60 days by default. Versions older than 60 days are automatically pruned by the Application to manage disk space. You may manually delete version files at any time using your file manager.
10.3 Encrypted entry versions
Version snapshots for encrypted entries store the ciphertext, not the plaintext. This means version history does not create an unencrypted copy of your protected entries on disk.
11. Threat Model
The following table summarizes VaultBook's security posture against common threat vectors:
| Threat | Mitigation | Status |
|---|---|---|
| Remote data breach | No server, no remote data storage, no network transmission | ✓ Eliminated |
| Man-in-the-middle (MITM) interception | Application makes zero network requests; no data in transit to intercept | ✓ Eliminated |
| Credential theft / account takeover | No user accounts, no passwords stored remotely, no authentication server | ✓ Eliminated |
| Third-party analytics data harvesting | No analytics, no tracking, no third-party scripts in the Application | ✓ Eliminated |
| Physical device theft (unencrypted entries) | OS-level disk encryption recommended; per-entry encryption available | Mitigated |
| Physical device theft (encrypted entries) | AES-256-GCM with PBKDF2; ciphertext unreadable without password | ✓ Protected |
| Shoulder surfing / visual observation | Lock screen with full-page blur and event blocking | Mitigated |
| Malicious browser extension | User responsibility to audit extensions; browser sandbox limits cross-tab access | User scope |
| Tampered HTML file (supply chain) | Downloads served over HTTPS; file integrity verifiable via checksums | Mitigated |
| Accidental data loss | Version history (60-day retention); user-managed backups recommended | Mitigated |
12. Supply Chain & Dependencies
12.1 Bundled libraries
All third-party libraries used by VaultBook are bundled inline within the HTML file at build time. There are no runtime CDN fetches, no dynamic imports from external servers, and no package manager downloads at execution time. The libraries bundled in VaultBook include:
| Library | Purpose | Loaded from |
|---|---|---|
| marked.js | Markdown rendering | Embedded inline |
| Tesseract.js | Optical character recognition (OCR) | Embedded inline |
Because these libraries are embedded at build time, their code is fixed and auditable within the HTML file. A supply chain attack against a CDN or npm registry would not affect already-distributed copies of VaultBook.
12.2 Web Crypto API
All cryptographic operations (AES-256-GCM encryption, PBKDF2 key derivation, random value generation) are performed using the browser's built-in Web Crypto API, not a third-party JavaScript cryptography library. The Web Crypto API is implemented natively in the browser engine (C++ in Chromium, Rust in Firefox) and undergoes rigorous security auditing as part of the browser's own development process.
13. What We Cannot Do
VaultBook's architecture means that there are certain things VaultBook Labs is structurally unable to do, regardless of intent, legal order, or request:
Access your data — We have no server, no database, and no mechanism to receive, store, or view your Content.
Decrypt your entries — Encryption keys are derived from passwords you set and are never transmitted to us. We cannot decrypt your entries, and we cannot help you recover a forgotten password.
Remotely disable VaultBook — The Application runs locally from a file on your device. We have no remote kill switch, no license server, and no ability to modify or revoke your installed copy.
Monitor your usage — There is no telemetry, no analytics, and no usage tracking. We do not know how many entries you have, how often you use VaultBook, or what you write about.
Comply with data requests about you — If a government or third party were to request your VaultBook data from us, we would have nothing to produce. We do not have your data.
Push updates without your consent — There is no auto-update mechanism. You choose whether to download a new version.
14. User Best Practices
While VaultBook's architecture provides strong baseline security, the following practices will help you maximize the protection of your data:
| Practice | Why it matters |
|---|---|
| Use strong, unique encryption passwords | PBKDF2 slows brute-force attacks, but a weak password (e.g., "password123") can still be guessed. Use passphrases with 4+ random words or 16+ character mixed strings. |
| Store passwords in a dedicated password manager | VaultBook cannot recover lost encryption passwords. A password manager (1Password, Bitwarden, KeePass, etc.) ensures you never lose access to encrypted entries. |
| Enable OS-level disk encryption | BitLocker (Windows), FileVault (macOS), or LUKS (Linux) encrypts your entire disk, protecting all files — including unencrypted VaultBook entries — if your device is stolen. |
| Maintain regular backups | Your Workspace is a regular folder. Copy it to an external drive, cloud storage, or version control repository on a regular schedule. VaultBook's version history covers 60 days, but backups protect against hardware failure. |
| Keep your browser updated | VaultBook relies on the browser's security sandbox, Web Crypto API, and File System Access API. Browser updates include security patches that protect these foundations. |
| Audit your browser extensions | Malicious or overly permissive browser extensions could theoretically read page content. Periodically review installed extensions and remove any you don't actively trust and use. |
| Use the lock screen when stepping away | Even in a trusted environment, the lock screen prevents casual visual access to your workspace. For maximum protection, close the browser tab entirely. |
| Verify download integrity | Download VaultBook only from the official Website (reportmedic.github.io) or the published GitHub repository. Compare file hashes against published checksums when available. |
15. Vulnerability Disclosure
15.1 Reporting a vulnerability
If you discover a security vulnerability in VaultBook, we encourage responsible disclosure. Please report vulnerabilities through our Telegram channel:
Telegram: t.me/VaultBook
When reporting, please include as much detail as possible: the affected version of VaultBook, the browser and operating system you are using, a description of the vulnerability, step-by-step reproduction instructions, and an assessment of the potential impact.
15.2 Our commitment
Acknowledgment — We will acknowledge receipt of your report within 72 hours.
Assessment — We will assess the reported vulnerability and determine its severity, scope, and remediation path.
Remediation — We will develop and release a patched version of VaultBook as promptly as the severity warrants.
Disclosure — Once a fix is available, we will publicly disclose the vulnerability along with remediation guidance on our Website and Telegram channel.
Credit — With your permission, we will credit you as the discoverer of the vulnerability in our public disclosure.
15.3 Scope
We consider the following in scope for vulnerability reports: the VaultBook Application (all editions), the VaultBook Website (reportmedic.github.io), cryptographic implementation issues, File System Access API misuse, and any mechanism that could compromise the confidentiality, integrity, or availability of user data.
We consider the following out of scope: vulnerabilities in the underlying browser engine (report these to the browser vendor), vulnerabilities in your operating system, social engineering attacks, and physical access attacks on unlocked, unencrypted workspaces (these are addressed by user best practices).
16. Incident Response
16.1 No server breach scenario
Because VaultBook Labs does not operate servers that store, process, or transmit user data, a traditional server-side data breach is not possible. There is no database to exfiltrate, no user credentials to leak, and no backup tapes to compromise.
16.2 Application-level vulnerability
If a security vulnerability is discovered in the Application's code that could affect the confidentiality, integrity, or availability of locally stored data, we will take the following steps:
Immediate assessment — Determine severity, affected versions, and exploitation requirements.
Rapid patching — Develop and test a remediated version of the Application.
Public disclosure — Publish a security advisory on our Website and Telegram channel describing the vulnerability, affected versions, potential impact, and remediation steps.
Updated download — Make the patched version available for download with a clear version indicator.
Guidance — Provide specific instructions for users to determine whether they are affected and what actions to take.
16.3 Website compromise
If the VaultBook Website or download infrastructure (hosted on GitHub Pages) were compromised, we would immediately notify users via our Telegram channel, work with GitHub to remediate the compromise, verify the integrity of all hosted files, and publish verified checksums for clean downloads.
17. Compliance & Standards
VaultBook's offline-first, zero-collection architecture naturally aligns with the data protection principles of major regulatory frameworks:
| Framework | Alignment |
|---|---|
| GDPR (EU) | No personal data is collected, processed, or transmitted to any server. There is no data controller/processor relationship for Application data. Data minimization and purpose limitation are satisfied by design — zero collection. |
| CCPA (California) | No personal information is collected or sold. California residents' rights to know, delete, and opt-out are structurally satisfied — there is no data to know about, delete, or opt out of. |
| PIPEDA (Canada) | No personal information is collected from Canadian users through the Application. |
| HIPAA (US healthcare) | While VaultBook is not specifically designed as a HIPAA-compliant tool, its zero-transmission, local-only architecture means that Protected Health Information (PHI) stored in VaultBook is never transmitted to or accessible by VaultBook Labs. Organizations subject to HIPAA should evaluate VaultBook's suitability within their own compliance framework. |
| Data residency laws | Your data physically resides wherever your device is located. There is no cross-border data transfer because there is no data transfer of any kind. |
For complete details on our data handling practices, please see our Privacy Policy. For license and usage terms, see our Terms of Service.
18. Contact
If you have questions about VaultBook's security architecture, wish to report a vulnerability, or need guidance on securing your Workspace, you can reach us through Telegram:
Telegram: t.me/VaultBook
Entity: VaultBook Labs, San Francisco, California, United States.
We aim to respond to all security-related inquiries within 72 hours.