What Happens When You Open VaultBook: A Packet-by-Packet Privacy Audit

Privacy claims are easy to make. Every note-taking application with any commercial interest in the privacy-conscious market describes itself as private, secure, and respectful of your data. What separates a claim from a guarantee is verifiability - the ability to inspect exactly what an application does and confirm that its behavior matches its stated intentions.

VaultBook claims to make zero network requests during normal operation. This article verifies that claim the only way it can be verified: by going through the source code and auditing every network-relevant operation in the entire application, from startup to active use. We will trace what happens when you open VaultBook.html in a browser, what fires during the connection to your vault folder, what runs during a typical working session of searching, editing, encrypting, and file management, and what the only three situations are in which VaultBook makes a network request at all - and what those requests contain when they do occur.

This is not marketing. It is a technical audit. Everything documented here is directly verifiable in VaultBook’s source code.

The Methodology: What a Privacy Audit Actually Checks

A complete privacy audit of a browser application needs to check more than just whether the application sends note content to a server. There are several channels through which an application can transmit user data without the user being aware:

Explicit HTTP/HTTPS fetch calls - the most obvious channel. The application calls fetch() or XMLHttpRequest to send or receive data from a URL.
External script loading - loading JavaScript from a CDN or third-party server. The server receives a request log entry that includes your IP address, browser fingerprint, and timestamp. The loaded script may contain tracking code.
External resource loading - fonts from Google Fonts, images from CDN URLs, stylesheets from external servers. Each generates a request with identifying information.
WebSocket connections - persistent bidirectional connections to a server, typically used for real-time sync.
WebRTC peer connections - direct peer-to-peer connections that can be used to transmit data outside normal browser security boundaries.
Service worker network intercepts - a service worker can intercept and log all network requests the application makes, including encrypted requests.
Beacon requests - navigator.sendBeacon(), used to send analytics data even when a page is being unloaded, resistant to ad blockers because it fires after the page closes.
Telemetry libraries - third-party analytics scripts (Google Analytics, Mixpanel, Amplitude, Segment, Heap, Hotjar, FullStory) that embed tracking code in the application.
localStorage and sessionStorage - browser storage that is origin-scoped and persists across sessions. While not a network channel, understanding what is written here reveals what behavioral data the application retains.

This audit checks all of these channels systematically. The findings are documented below with line-number references to the source for each finding.

What Happens in the First Second: Opening the File

When you open VaultBook.html in your browser, the browser parses the HTML document. The <head> section contains two types of references: a favicon link (<link rel="icon" type="image/png" href="favicon.png">) pointing to a local file, and a series of <script src="./libs/..."> tags loading JavaScript libraries.

Every script tag in VaultBook.html points to a path inside ./libs/. This is not a CDN path. It is a relative path to the libs/ folder that ships alongside VaultBook.html on your local device. The browser resolves ./libs/turndown.js, ./libs/marked.min.js, ./libs/jszip.min.js, ./libs/xlsx.full.min.js, ./libs/mammoth.browser.min.js, ./libs/pdf.min.js, ./libs/pdf.worker.min.js, ./libs/DataStream.js, ./libs/msgreader.js, and ./libs/tesseract.min.js as local file paths and loads them from your device.

Network requests generated by opening VaultBook.html: zero.

No CDN receives a request. No external server logs your IP address, browser version, or the timestamp of your session. No library is fetched from cdnjs.cloudflare.com, unpkg.com, cdn.jsdelivr.net, or any other external source. The only resource loading that occurs when you open VaultBook is local file loading - the browser reading files from your device.

The HTML document also contains no references to external fonts (no Google Fonts, no Adobe Fonts), no external stylesheets, no tracking pixels, no image tags pointing to external servers. The inline SVG used as a UI element in one CSS rule is a data: URI - it is embedded inline in the stylesheet and generates no network request.

The DOMContentLoaded Phase: What Runs at Startup

Once the HTML is parsed and scripts are loaded, the browser fires the DOMContentLoaded event. VaultBook has multiple listeners registered for this event, handling different initialization concerns. Reading through each one:

UI initialization - the first DOMContentLoaded listener calls updateCollapserHeight() and wireSubAccReflow(), which measure DOM elements and set CSS custom properties for accordion animations. These are pure DOM operations with no network component.

Sort and filter controls - the second listener initializes the sort field dropdown, sort order toggle, and label match mode radio buttons from their default values. It then wires click handlers for all built-in tool links. These are DOM wiring operations with no network component.

Item rendering - the third listener calls renderItems(), which reads from state.items - the in-memory application state - and renders the entry list. On first startup before a vault folder has been connected, state.items is an empty array and renderItems() produces an empty list. No data is fetched from anywhere.

Feature and tier initialization - a later listener calls toggleFeatures() and updates the license tier display. These operations read from variables already set in memory from the parsed script content. No network call.

Storage tutorial - the final startup listener calls showStorageTutorial() if storageConnected is false, displaying the onboarding prompt. It also installs a click interceptor that prevents other buttons from functioning until storage is connected. This is a purely local UI guard with no network component.

Network requests generated during DOMContentLoaded: zero.

The application is fully initialized, the UI is rendered, and the entry list is displayed (empty, pending vault connection) without contacting any server.

Connecting to the Vault Folder: The File System Access API Flow

When you click the folder icon to connect your vault, VaultBook calls window.showDirectoryPicker({ id: 'vaultbook-root' }). This API call opens the browser’s native OS folder picker dialog. The browser presents a folder selection UI that is part of the browser itself - not a web page, not a remote resource. You select your vault folder on your local device. The browser asks for read and write permission to that folder.

Once you grant permission, VaultBook:

Calls root.getDirectoryHandle('attachments', { create: true }) - creates or opens the local attachments/ subdirectory
Calls root.getDirectoryHandle('index', { create: true }) - creates or opens the local index/ subdirectory
Calls root.getDirectoryHandle('versions', { create: true }) - creates or opens the local versions/ subdirectory
Calls root.getFileHandle('repository.json', { create: true }) - opens or creates the local vault state file
Calls root.getFileHandle('license.json') - reads the license file from the local vault folder

The license verification step deserves particular attention because license verification is a common place where applications phone home. VaultBook’s license verification is fully local. The license file is read from your vault folder. The verification uses crypto.subtle.importKey() to import a public key that is embedded directly in the VaultBook.html source code, then calls crypto.subtle.verify() using RSA-PSS with SHA-256 to verify the signature on the license data. The entire verification operation executes inside the browser’s Web Crypto API using local data. No license server is contacted. No activation request is sent. No usage data is reported.

After license verification, VaultBook reads repository.json, parses the vault state, and for each note loads its body text from the corresponding details-{id}.md sidecar file in the attachments/ directory. The DOMContentLoaded handler for renderItems() then re-renders the entry list with the loaded content.

Network requests generated by connecting to the vault folder: zero.

Every operation in the connection flow reads from and writes to local files through the File System Access API. The license verification uses cryptographic operations that execute locally against data in the vault folder. Nothing leaves the device.

A Normal Working Session: Editing, Searching, Encrypting

Once the vault is connected, a typical working session involves creating and editing notes, searching the vault, encrypting sensitive entries, managing attachments, and using the organizational features. This is where most applications with privacy issues reveal themselves - in the ongoing background activity of a working session.

Creating and editing a note - when you create a new note, type content, and save, VaultBook writes the note metadata to repository.json via the File System Access API, and writes the note body to attachments/details-{id}.md. These are local file writes. No server receives the content of what you wrote. No sync operation fires. The save system uses a dirty flag, a debounced autosave timer, and a __saving guard to prevent concurrent writes - all entirely local operations.

Searching the vault - when you type in the search bar, VaultBook runs the relevanceScore() function against state.items - the in-memory vault state - and re-renders the entry list. The QA panel runs qaAnswer() against the same in-memory state. Neither operation makes a network request. When background OCR warm-up fires for top search candidates, it runs Tesseract.recognize() using the locally loaded tesseract.min.js library - an entirely local operation. When attachment text is loaded for search candidates, it reads from local index files in the index/ directory. No query text, no result data, no vault content of any kind is transmitted to any server.

Encrypting a note - the entire encryption pipeline uses crypto.subtle.importKey(), crypto.subtle.deriveKey(), and crypto.subtle.encrypt() - all Web Crypto API operations that execute inside the browser’s cryptographic subsystem. The password you enter never leaves the browser. The plaintext never touches a server. The ciphertext is written to a local sidecar file. Zero network activity.

Attaching a file - when you attach a file to a note, VaultBook writes the file to the attachments/ directory and updates the index.txt manifest. The file indexing pipeline - PDF text extraction, XLSX cell reading, PPTX slide parsing, DOCX content extraction, MSG email parsing, OCR of embedded images - runs using locally loaded libraries. No file content is uploaded. No cloud OCR service is contacted. Zero network activity.

Browsing the AI Suggestions panel - the sparkle suggestions panel computes its recommendations from in-memory state: upcoming due dates read from note metadata, weekday reading patterns computed from the read log in localStorage, recently viewed entry IDs from localStorage. No recommendation API is called. The suggestions are generated by local computation over local behavioral data.

Using the built-in tools (File Explorer, Folder Analyzer, Password Generator, PDF Merge, PDF Compress, Kanban Board, Threads, Import from Obsidian) - all of these tools operate on local files through the File System Access API. PDF merging and compression use pdf-lib.min.js loaded from the local libs/ directory via a dynamically injected script tag pointing to the local path. The Password Generator uses crypto.getRandomValues() - the browser’s local random number generator. The Kanban Board reads and writes to localStorage for board state. The Threads tool reads from and writes to localStorage and to a local file in attachments/. The Import from Obsidian tool reads .md files you drop into it and converts them to VaultBook entries using marked.js - locally. None of these tools make network requests.

Network requests generated during a normal working session: zero.

The localStorage Picture: What VaultBook Retains Locally

VaultBook uses localStorage for several purposes. Because localStorage is not a network channel, data written there stays on your device and is never transmitted. But understanding what is written there is part of a complete privacy audit.

The localStorage keys VaultBook uses, and exactly what each contains:

vb_vote_no_confirm_v1 - a single boolean preference: whether you have dismissed the voting confirmation dialog. Contains no note content, no identifiers, no behavioral data beyond this one UI preference.
vb-kanban-{repoKey} - the Kanban board state for each vault, including board configuration and card data. This is behavioral data (how you have organized your Kanban boards) that stays on-device. The repoKey is a local identifier derived from your vault, not a server-side user ID.
vb-reader-{repoKey} and vb-reader-{repoKey}-saved - the RSS Reader feed configuration (which feeds you have added and how they are organized into folders) and the list of articles you have marked as saved. Contains the URLs of RSS feeds you have configured. No article content is stored here - article content comes from the feeds directly when you open the Reader tool.
vbThreadsStore_v1 - Threads tool message data, used as a fallback if the primary disk storage (a file in attachments/) is not available. Contains thread content you have written in the Threads tool. Primary persistence is to the local vault folder; localStorage is a fallback mirror.
vb_search_history_v1 - a list of up to 200 past search queries you have typed in the search bar. Query strings only - no results, no note content, no timestamps beyond what is needed for the deduplication logic.
vb_tool_use_log_v1 - a log of recently used built-in tools, used to populate the “Recently Used Tools” page of the AI Suggestions carousel. Contains tool identifiers and timestamps. No note content.
vb_recent_ids - a list of recently viewed entry IDs, used to populate the “Recently Read” page of the AI Suggestions carousel. Contains entry ID numbers only - not titles, not content, not any other note data.
vb_read_log_v1 - a timestamped log of entry ID reads, used to compute weekday reading patterns for the AI Suggestions engine. Contains entry ID numbers and read timestamps. No note content.

Every localStorage key contains either UI preferences, tool configuration, or behavioral metadata (IDs and timestamps). Note content never appears in localStorage. Encrypted note content never appears in localStorage. The localStorage data is entirely local - it is stored in the browser’s origin-scoped storage for the local file path of VaultBook.html and is never transmitted anywhere.

A developer who opens the browser’s Application panel in DevTools while using VaultBook can inspect every localStorage entry and verify this directly. The contents match exactly what is described above.

The Three Network Situations: When VaultBook Does Contact External Servers

VaultBook is not a network-free application in an absolute sense. There are three situations in which it makes external network requests. Being precise about these situations is important because they are the only gaps in the zero-network guarantee, and understanding them allows you to make an informed decision about when and whether to use the features involved.

Situation 1: The Save URL to Entry tool. This is a Pro tool that creates a VaultBook note from a web page URL. When you provide a URL, VaultBook calls fetch(url, { method: 'GET' }) to retrieve the page HTML and extract readable text from it. This request goes to the URL you provide - not to VaultBook’s servers or any third-party analytics service. The request is user-initiated: you opened the tool and provided a URL specifically to create a note from it. The network request is the explicit purpose of the tool. If CORS prevents the fetch from succeeding (many sites send CORS headers that block cross-origin reads), VaultBook falls back gracefully. There is no automatic URL fetching - the fetch fires only when you invoke the tool with a URL.

A secondary function, fetchPageTitle(), also makes a network request to retrieve a page title from a URL. This fires in specific contexts where a URL has been provided for title enrichment, with a 2-second timeout and a fallback to the hostname if the request fails or is blocked by CORS. Again, this request goes to the URL the user has provided - not to any VaultBook infrastructure.

Situation 2: The RSS and Atom feed Reader. The RSS Reader is a Pro tool for following web feeds. When you add an RSS or Atom feed URL to the Reader and click to view its content, VaultBook calls fetch() to retrieve the feed XML from the feed’s URL. This request goes to the RSS feed publisher’s server - not to VaultBook’s servers. The fetch uses a cache-first approach: if the feed has already been loaded in the current session (if (!forceNetwork && feedCache[feedId])), the cached version is returned without making a network request. New requests are only made when you explicitly refresh or when a feed has not been loaded in the current session. The Reader does not auto-refresh feeds in the background. No feed content is sent to VaultBook servers - the fetched XML is parsed locally using a bundled XML parser and displayed in the Reader UI.

Situation 3: Wikipedia lookup. The vbFetchWiki() function retrieves article summaries from the Wikipedia REST API (https://en.wikipedia.org/api/rest_v1/page/summary/). This function is invoked in a specific context within the application where the user has triggered a lookup. The request goes to Wikipedia’s public API, which is operated by the Wikimedia Foundation under a privacy policy that covers public API use. The request contains only the search term - no vault content, no identifiers, no session tokens.

All three network situations share the same structural property: the request is user-initiated for an explicit purpose, the request goes to a content server (the URL the user provided, the RSS feed publisher, Wikipedia) rather than to VaultBook’s servers, and no vault data is included in the request. None of these three situations involves VaultBook receiving any information about your notes, your vault structure, your search activity, or your usage patterns.

The complete network map of VaultBook is: zero requests on startup, zero requests during normal operation (note editing, search, encryption, file management, analytics, AI suggestions, version history, all local tools), and three user-initiated content retrieval situations that contact the specific content servers the user has directed the application to.

What This Means Compared to Cloud Note-Taking Apps

The contrast with cloud-based note-taking applications is not subtle. To make it concrete, consider what happens when you open a mainstream cloud note-taking application and start a working session.

On startup: the application authenticates your session with an auth server, receives a session token, loads your note list from a cloud API, and typically fires telemetry events that record that you opened the application, what device you are on, what OS version, and what app version. This happens before you type a single character.

During a working session: every note you open generates an API request that fetches the note content from the cloud. Every note you edit generates an API request that saves the content to the cloud - often with real-time sync that fires multiple requests during typing. Every search you perform sends the query text to a cloud search index. Attachment uploads send file content to cloud storage. Telemetry events track which features you use, how long you spend on each note, what labels you apply, and potentially what you type if the application uses client-side analytics that capture user interactions.

The cloud application developer typically sees, in aggregate across their user base, anonymized versions of: what queries users search for, which features are used and how often, which notes are accessed and when, what file types are attached, and what the content of those files is (since the cloud processes them for indexing). Even with strong privacy policies, this data exists on the vendor’s servers, is subject to legal process in the vendor’s jurisdiction, and is at risk from any security incident that affects the vendor’s infrastructure.

Against this baseline, VaultBook’s network profile is not a marginal improvement - it is a categorical difference. The absence of telemetry is not the result of choosing not to collect data that is technically available; it is the result of an architecture in which the technical mechanism for data collection (network communication from the client to a server) does not exist for core functionality.

The Network Tab Test: Verifying This Yourself

The claims in this article are not assertions you need to take on trust. Every modern browser includes a Network tab in its developer tools that shows every network request the page makes in real time. You can verify VaultBook’s network behavior in about two minutes.

Open VaultBook.html in Chrome, Edge, or any Chromium-based browser. Before doing anything else, open DevTools (F12 or Cmd+Option+I on Mac) and click the Network tab. Clear any existing entries. Now connect your vault folder, open some notes, run a few searches, open an encrypted note and enter the password, attach a file, and browse the AI Suggestions panel.

Look at the Network tab. The only entries you will see are requests for the local files that make up the application - VaultBook.html itself, the library scripts in libs/, and the favicon. You will see no requests to analytics endpoints, no auth server pings, no sync API calls, no telemetry beacons. The entry list in the Network tab will not grow as you work.

This test is what security researchers and privacy advocates refer to when they talk about “verifiable” privacy. It is not enough to claim that an application is private - the claim should be checkable by any user who wants to check it. VaultBook’s zero-network behavior for core functionality is directly observable by anyone who opens DevTools, and it will be the same every time.

If you run the Network tab test and then open the Save URL to Entry tool, provide a URL, and create a note from it, you will see a fetch request to that URL appear in the Network tab. This is the expected behavior - you explicitly requested that VaultBook retrieve a web page. The same applies if you open the RSS Reader and load a feed, or if a Wikipedia lookup is triggered. These are the only network entries you will ever see for user-initiated content retrieval.

The Absence of a Service Worker: Why It Matters

Many browser applications that describe themselves as offline-capable use a service worker - a background script that intercepts all network requests the page makes and can cache responses for offline use. Service workers are a legitimate and useful web technology, but they have a privacy implication: a service worker can log every network request the application makes, including requests to encrypted endpoints, without that logging being visible in the page’s own code.

VaultBook does not register a service worker. There is no navigator.serviceWorker.register() call anywhere in the source. There is no manifest.json file that would trigger automatic service worker behavior. VaultBook is not a Progressive Web App (PWA) in the technical sense. It is a local HTML file that runs in a browser tab.

The absence of a service worker means there is no interceptor between the application code and the network. What you see in the Network tab is the complete and unfiltered record of every network communication the application initiates. There is no background layer where additional requests could be made invisibly.

This also means that VaultBook’s offline capability does not depend on service worker caching. The application is offline-capable because all its dependencies are local files - not because a service worker has cached resources from a server. The offline behavior is a property of the file architecture rather than a runtime caching mechanism.

WebRTC and WebSocket: Also Absent

WebRTC peer connections (RTCPeerConnection) are sometimes used in applications to establish direct data channels between clients that bypass normal HTTP request logging. WebSockets provide persistent bidirectional connections to servers. Neither is present in VaultBook’s source code. A search for RTCPeerConnection, RTCDataChannel, WebSocket, and EventSource in the complete source returns no results. There is no covert communication channel in the application.

What the Application Knows About You

Given the complete network audit, the question becomes: what does VaultBook retain about your behavior, and where does it live?

VaultBook’s knowledge of your behavior is entirely in two local locations: the vault folder (through repository.json, sidecar files, and version snapshots) and the browser’s localStorage for that file’s origin.

The vault folder contains: the content and metadata of your notes, your file attachments, version history snapshots with 60-day retention, and the search index for attached documents. This is the data you deliberately put into VaultBook. It lives on your device in a folder you chose, in open formats you can read with any text editor.

The browser’s localStorage contains: one UI preference (vote dialog), Kanban board configuration, RSS feed configuration (URLs, not article content), Threads messages (as a fallback), up to 200 past search query strings, tool usage log (tool names and timestamps), recently viewed entry IDs, and the read log for weekday suggestion computation (entry IDs and timestamps).

VaultBook does not know: your name, your email address, your IP address, your device identifier, how many notes you have, what your notes contain, what files you have attached, what you search for, or any other information about you or your vault. This is not a privacy policy commitment - it is a technical reality. The architectural absence of a network channel from the application to VaultBook’s servers means this information cannot reach VaultBook even if the privacy policy were different.

Trust Through Architecture, Not Policy

The strongest form of privacy protection is not a promise - it is an architecture that makes the violation of that promise technically impossible for the declared threat model. VaultBook’s zero-network architecture makes it technically impossible for the core application to transmit your note content, search queries, or usage patterns to any server during normal operation, because the mechanism for that transmission - a network request from the application to a server - does not exist in the code.

This is meaningfully different from an application that has the technical capability to transmit your data and promises not to. A privacy policy can change. A company can be acquired. A new feature can be added that introduces telemetry. Legal pressure can compel disclosure of data that was never supposed to be collected. All of these scenarios require that the application had some network channel through which data could flow. VaultBook’s core application removes that channel.

The three user-initiated network situations described earlier (Save URL, RSS feeds, Wikipedia) do not violate this principle because they are content retrieval operations explicitly invoked by the user for a specific purpose, going to content servers the user has directed, with no VaultBook server in the loop. The requests contain the retrieval query, not vault content.

The audit result is not “VaultBook promises to protect your privacy.” It is “VaultBook’s source code, read line by line, shows no mechanism by which your note content, search activity, or usage patterns could reach any server during normal operation.” That is the difference between a claim and a guarantee.

The Encryption Layer Under Audit: No Key Material Leaves the Browser

Because VaultBook includes per-entry AES-256-GCM encryption, a thorough privacy audit needs to address not just network communication but also whether any key material or plaintext could reach a server even indirectly. The answer, confirmed by the source code, is no - and the mechanism that ensures this is the Web Crypto API’s non-extractable key design.

When you encrypt a note, VaultBook calls crypto.subtle.importKey() on your password bytes with the parameter extractable: false. This creates a CryptoKey object inside the browser’s cryptographic subsystem that cannot be read back out as raw bytes by any JavaScript code, including VaultBook’s own code. Even if VaultBook tried to JSON.stringify the key and send it somewhere, it could not - the key is not accessible as a JavaScript value. It exists as an opaque handle inside the browser’s native cryptographic layer.

The derived AES-256 key produced by crypto.subtle.deriveKey() inherits the same non-extractability. It is created and used inside the Web Crypto API and never exists as accessible bytes in JavaScript memory. The only outputs of the encryption operation that are accessible to JavaScript - and therefore the only things that could theoretically be transmitted - are the base64-encoded salt, IV, and ciphertext, all of which are what VaultBook writes to the local sidecar file.

The plaintext of encrypted notes exists in JavaScript memory in the _plain field of the note object only during an active session after you have entered the password. At that point it is in the browser’s JavaScript heap - accessible to VaultBook’s own code (which needs it to display the note in the editor) but not accessible to any external party because there is no network channel through which it could be transmitted. When you close the note or end the session, the _plain field is cleared or goes out of scope.

The session password cache - an in-memory Map that stores passwords during your active session - follows the same profile: it exists in JavaScript memory, is cleared when you close or refresh the browser, and cannot be transmitted because no network channel connects VaultBook’s runtime to any external server.

The encryption audit finding is: key material is non-extractable by design, plaintext exists only in browser memory during active sessions, and no mechanism exists for either to reach an external server.

The Analytics Panel: Intelligence From Local Data Alone

VaultBook’s analytics subsystem - which renders four canvas charts and a set of numerical summaries in the sidebar - is worth examining under the privacy audit lens because “analytics” is a word that, in many applications, implies external data collection. In VaultBook, the analytics are computed entirely from state.items, the in-memory representation of your vault loaded from your local repository.json.

The label utilization pie chart, the 14-day activity line chart, the pages utilization pie chart, and the month activity chart are all rendered by the renderAnalytics() function, which reads from state.items and computes summaries locally. The computeAnalytics() function iterates through your items, counts labels, groups activity by date, and measures page utilization - all in-memory operations on local data.

The read log used by the AI Suggestions weekday engine is stored in localStorage under vb_read_log_v1. It contains entry ID numbers and read timestamps. The computation that converts this log into weekday suggestions - identifying which entry IDs you most frequently read on each day of the week - runs locally in the vbSmart_weekdayName() and related functions. No usage data, no reading patterns, no behavioral profile is transmitted anywhere. The “personalized” aspect of the suggestions is achieved by analyzing your own behavioral data on your own device.

This matters because behavioral analytics - understanding how users use a product - is the primary commercial justification that most applications give for their data collection. The argument is typically “we need usage data to improve the product.” VaultBook’s local analytics architecture demonstrates that behavioral insight can be provided to the user themselves without requiring the product to collect that behavior on a server.

Comparing the Audit Result to Competitor Architectures

The zero-network-to-VaultBook-servers finding stands in sharper relief when considered against the privacy architectures of the applications VaultBook is most often compared to.

Applications in the cloud-sync category - Notion, Evernote, Microsoft OneNote, Google Keep - are fundamentally incompatible with a zero-network model because their core value proposition is cloud sync. Every note is stored on their servers by design. Every edit is transmitted to their servers in real time. Their telemetry and analytics operate on server-side data. They cannot make the claim VaultBook makes because their architecture requires the network connection to function.

Applications in the “privacy-focused” category take different approaches. Standard Notes encrypts content end-to-end before storing it on Standard Notes servers - so the vendor cannot read your notes, but the server still receives ciphertext, connection metadata, and the timing and frequency of your sync operations. Notesnook takes a similar approach: open-source, end-to-end encrypted, but with a sync server that receives ciphertext. Both are meaningfully more private than mainstream cloud notes apps. Neither can claim zero transmission to their own servers, because their sync architecture requires that transmission.

Obsidian, in its local vault configuration (without the optional Sync plugin), is the closest architectural peer to VaultBook: a local-first application where your notes are files on your device. Obsidian’s desktop app does not make network requests for note content in local vault mode. However, Obsidian is a desktop application that requires installation, and its optional Sync service does involve server-side infrastructure for users who enable it.

VaultBook’s position in this landscape is distinct: a browser-native application with zero installation, zero server transmission for core functionality, a positive privacy audit result that can be verified by any user with DevTools open, and the full search, encryption, and tooling capabilities described throughout this blog series.

What “Zero Network Requests” Means for Your Threat Model

Different users have different threat models - different adversaries they are concerned about and different harms they are protecting against. VaultBook’s zero-network architecture addresses several of these threat models simultaneously.

The corporate surveillance threat model - concern that note-taking applications are data businesses that monetize behavioral signals and content metadata. VaultBook’s architecture makes this impossible for core functionality: no content reaches VaultBook’s servers, no behavioral data is collected server-side, and there is no ad-targeting or content-analysis infrastructure that could be applied to your notes.

The breach and compromise threat model - concern that a cloud vendor will suffer a data breach that exposes your notes. VaultBook’s architecture eliminates this vector for content: since your notes are not on VaultBook’s servers, a breach of VaultBook’s infrastructure cannot expose your note content. The attack surface for your notes is your device, not a cloud database shared with thousands of other users.

The legal process threat model - concern that a government or litigant could serve legal process on a cloud vendor and compel disclosure of your notes. VaultBook’s architecture makes this category of request ineffective: since note content is not on VaultBook’s servers, there is nothing for legal process against VaultBook to compel disclosure of. The only path to your notes through this threat model is legal process against you directly, which is a meaningfully higher bar.

The insider threat model - concern that a cloud vendor’s employee could access your notes. Zero notes on the server means zero insider access to note content.

The metadata surveillance threat model - concern that even without access to note content, an adversary who can observe the timing and frequency of your sync operations could infer sensitive information (when you are working on a sensitive project, whether you are meeting with specific parties on specific dates). VaultBook’s local-only architecture eliminates sync operation metadata because there are no sync operations.

No single privacy measure addresses every possible threat. VaultBook’s zero-network architecture does not protect against an adversary who has physical access to your device, against malware on your device, or against the browser itself. These are different threat vectors that require different mitigations (device encryption, OS security, browser security updates). What VaultBook’s architecture does uniquely well is eliminate the entire category of network-layer threats - the threats that arise from data being transmitted to and stored on third-party servers.

The Full Network Map: A Summary

For users who want a single reference point, here is the complete network map of VaultBook:

On startup (opening VaultBook.html): Local file loads only - the HTML file and local libraries. No external requests.

On vault connect: Local File System Access API operations. License verification using local RSA-PSS cryptography against a local file. No external requests.

During note editing: Local file writes via File System Access API. No external requests.

During search: In-memory computation. Local index file reads. Local OCR via Tesseract. No external requests.

During encryption/decryption: Web Crypto API operations in the browser. No external requests.

During attachment management: Local file reads and writes. Local text extraction (PDF, XLSX, PPTX, DOCX, MSG, ZIP) using local libraries. No external requests.

During AI Suggestions / analytics / version history: Local computation from in-memory state and local files. No external requests.

During local tools (File Explorer, Kanban, Threads, PDF tools, Password Generator, MP3 tools, File Analyzer, Folder Analyzer, Import from Obsidian): Local file operations and local library processing. No external requests.

When using Save URL to Entry tool (user-initiated): One fetch to the URL provided by the user. No vault content transmitted.

When using RSS Reader (user-initiated): Fetches to feed URLs configured by the user. No vault content transmitted.

When Wikipedia lookup is triggered (user-initiated): One fetch to the Wikipedia public API with the lookup term. No vault content transmitted.

Total external requests to VaultBook servers: zero. Ever.

Open the Network tab. Watch it yourself. The tab will be quiet.

VaultBook - your personal digital vault. Private, encrypted, and always under your control.