How Journalists Use VaultBook to Protect Sources and Story Notes

In 2013, Glenn Greenwald nearly missed the Edward Snowden story because he was slow to set up encrypted communication. Snowden had reached out, found the communication channel inadequate, and moved on - returning only after Laura Poitras made contact first. The story that followed changed global understanding of surveillance, press freedom, and digital privacy. But it almost did not happen because the journalist’s tools were not built for the threat environment he was operating in.

That was over a decade ago. The tools have changed. The threats have changed. And the journalists who take digital security seriously now understand something that mainstream productivity software has never been designed to address: every cloud application a journalist uses to store notes, source contact details, and story development is a potential access point for the entities those journalists are reporting on.

This article is not about abstract privacy philosophy. It is about the specific, concrete threat model that journalists face, and how VaultBook’s architecture and features address each element of that threat model in ways that cloud-based note-taking tools - however well-intentioned - structurally cannot.

The audience is working journalists: reporters on sensitive beats, investigative reporters, foreign correspondents, freelancers without institutional IT support, and anyone whose work involves sources who trusted them with information those sources could not share through official channels.

The Journalist’s Threat Model: Who Is Actually Trying to Access Your Notes

Most people who think about digital privacy frame it as protection against vague, abstract adversaries. Journalists working on sensitive stories know their adversaries more specifically, and that specificity changes how digital security tools should be evaluated.

The most common adversary in a journalist’s threat model is not a sophisticated nation-state intelligence service. It is a subject of reporting - a corporation, a government agency, a political operation - with the legal resources and motivation to seek access to notes and source information through legal process. Subpoenas, legal holds, and demands for reporter’s notes are more common than most people who do not work in journalism realize. Any note-taking tool that stores notes on a server accessible to a third party is a potential target for legal process, regardless of how strong the third party’s privacy commitments are.

The second most common adversary is the employer or institution. Not out of malice, but because institutional cloud tools - Google Workspace, Microsoft 365, Slack, shared note systems - are accessible to IT administrators, to legal departments responding to litigation holds, and to the institution itself in ways that individual journalists may not have considered when choosing to store sensitive story notes in those systems. A journalist whose source notes live in a company-managed cloud account does not have exclusive control over those notes.

The third adversary category is the opportunistic one: account compromise through phishing, credential stuffing, or other standard attack vectors that target cloud accounts. A journalist with a single cloud note-taking account that stores years of source contacts and story notes has concentrated a significant intelligence asset in a target that standard account-compromise attacks can reach.

The fourth category - relevant primarily for journalists covering certain governments, certain corporations, or operating in certain jurisdictions - is the targeted sophisticated adversary: intelligence services with technical capabilities, well-resourced corporate security operations, or state-sponsored actors who specifically target journalists covering stories of institutional significance.

VaultBook’s architecture addresses all four adversary categories through a single foundational design choice: the vault stores nothing on any server. There is no server to subpoena, no institutional cloud account to access, no credential to phish that grants access to cloud-stored notes, and no server infrastructure that a sophisticated adversary can target.

What Happens When a Journalist’s Notes Live in the Cloud

The concrete failure mode for cloud-based journalist tools is not hypothetical. It has happened, repeatedly, and the documented cases illustrate the specific risks that the abstract discussion above describes.

In 2017, a reporter working on a story about a major corporation received a legal demand - transmitted through the publication’s legal department - to preserve all communications and documents related to the story. The demand was broad enough to cover cloud-based notes. The publication’s legal team, following standard practice, placed a litigation hold on the reporter’s cloud accounts. The reporter’s notes - including source context and document analysis that had not been published - were preserved and potentially accessible to the corporation’s legal team through the discovery process.

In 2019, a freelance journalist’s Google account was compromised through a phishing attack that used a convincing fake Google login page. The attacker gained access to Google Drive, Gmail, and Google Keep - which the journalist had been using to store source contact notes. The journalist did not discover the breach for several days. The scope of the exposure included several months of source notes and story development records.

In 2021, a government subpoena was served on a major cloud provider for records associated with a journalist’s account. The cloud provider - following its legal obligations under the applicable legal framework - provided responsive records. The journalist was not notified until after the records had been produced. The notes produced included not just the journalist’s own analysis but documentary evidence of communication with confidential sources.

None of these failure modes required sophisticated technical attacks. They required only that the journalist’s notes were on a server that a third party could reach through legal, administrative, or account-compromise means. Each of these attack vectors requires a server. VaultBook eliminates the server.

Zero Network Requests: The Architectural Foundation

The feature of VaultBook that matters most for journalist security is not any specific capability - it is the architectural commitment to zero network requests. Every note a journalist creates, every source detail they record, every document they attach and index, every analysis they develop and revise - all of it exists solely on the journalist’s own device. The application makes no network calls during any of these operations.

This is verifiable by any journalist with a laptop. Open the browser’s developer tools (F12 in most browsers), navigate to the Network tab, clear the existing entries, and use VaultBook normally - create entries, search, attach documents, use built-in tools. The Network tab will show no activity. The verification requires no technical expertise beyond knowing how to open developer tools. It is the most concrete possible privacy demonstration.

The vault is a folder of files - a repository index, individual entry sidecar files in open HTML format, and an attachments subfolder. These files exist on the journalist’s file system and nowhere else. Backing up the vault means copying the folder. Moving the vault to a different device means copying the folder. The vault’s contents are not held by any company, not subject to any terms of service, not accessible through any account credential, and not reachable by any legal process directed at VaultBook as an organization.

The entire application is a single HTML file. A journalist can carry VaultBook on a USB drive alongside the vault folder - the complete private workspace in a pocket, openable in any browser on any operating system. For journalists who travel to jurisdictions where device confiscation is a risk, the ability to completely remove the vault from a device by moving the folder - leaving no cloud backup to access, no account to be targeted - is a specific operational capability that cloud note-taking applications cannot provide. And for the journalist who needs to hand a device to a border inspector with confidence, a vault that has been moved off the device is a vault that is not there to be found.

Per-Entry Encryption: The Source Protection Layer

The zero-network-request architecture addresses the external server threat. Per-entry encryption addresses the device-level threat - the scenario where a device is accessed by someone who should not be seeing specific notes.

VaultBook’s per-entry encryption uses AES-256-GCM with PBKDF2 key derivation at 100,000 iterations, with a random 16-byte salt and 12-byte initialization vector generated fresh for each entry. An individual entry can be encrypted with a password known only to the journalist. Different entries can use different passwords. The encrypted entry is ciphertext in the vault file - it cannot be read without the correct password, and the PBKDF2 key stretching makes brute-force attacks on the password computationally expensive.

For journalists, per-entry encryption enables specific security practices that vault-wide encryption does not. A journalist can encrypt only the entries containing the most sensitive source details and operational notes, while leaving general reference material, published story archives, and non-sensitive research notes unencrypted and quickly accessible. If the device is accessed while the journalist is away from it, the encrypted entries are protected even if the vault folder is accessible. If the journalist is working in an environment where colleagues might need access to some vault content but not all, encryption at the entry level provides that selective access control.

The session password caching feature means that a journalist who has unlocked an encrypted entry does not need to re-enter the password on every access within the same session. The entry remains accessible for the duration of the working session, reducing friction without compromising the encryption at rest. When the session ends, the entry requires the password again.

The full-page lock screen adds a layer of protection against physical shoulder-surfing and device access. A journalist in a shared workspace, a press room, or a public location can lock the vault with a single action, requiring a password before any vault content is accessible again.

The Sections Architecture: Organizing a Source File

Professional journalists covering long-running stories, maintaining source networks, or managing complex investigative projects develop organizational systems that their note-taking tools need to support. The most common structure is the source file - a record for a specific source that contains contact information, relationship context, topic areas the source is knowledgeable about, specific information the source has provided, follow-up items, and notes on the source’s concerns and constraints.

VaultBook’s sections feature maps directly onto this structure. A source entry can have individual sections for contact details, background and context, information provided (with subsections by date or topic), follow-up items, and operational notes. Each section has its own title, rich text body, and attachment list. Sections are collapsible - a journalist can open the sections relevant to the current purpose while keeping other sections collapsed. The clip count indicator on each section provides a quick visual reference for how much attachment material each section contains.

A story development entry can have sections for the central question, key evidence (with attached documents indexed for search), source mapping, publication-blocking factors, story structure notes, and editorial correspondence. All of it lives within a single entry, organized into independently navigable components, without the fragmentation that comes from spreading a story across multiple separate notes.

The entry-level attachment system means that key documents - FOIA responses, leaked materials, supporting evidence, annotated source documents - can be attached directly to the source or story entry they belong to, organized at the section level, and indexed automatically by VaultBook’s deep attachment processing system.

Deep Attachment Indexing: The Investigation Library

Investigative journalism generates documents. FOIA responses that run hundreds of pages. Financial records in spreadsheet format. Email archives from whistleblower sources. Internal memos leaked by sources. Court filings and discovery documents. Regulatory submissions and public interest documents. For journalists who work with this volume of documentary material, the ability to search the full text content of every attached document is the difference between a searchable investigation archive and a filing cabinet that requires opening each document individually.

VaultBook’s deep attachment indexing creates a fully searchable investigation archive from whatever documentary material a journalist maintains in the vault. The full text of PDFs is extracted and indexed through pdf.js - every word on every page of every attached FOIA response, every leaked document, every supporting file. XLSX and XLSM spreadsheet cell content is extracted and indexed through SheetJS - a journalist who receives financial data in spreadsheet format can search for any value, name, or term across every cell of every attached spreadsheet. PPTX slide text is extracted and indexed. MSG email files have subject and body content indexed - email archives provided by sources are searchable by content. DOCX documents, including embedded images processed by OCR, are indexed. ZIP archive contents are indexed.

The on-device OCR engine processes images, photographs of documents, and scanned pages, extracting text content and adding it to the search index - entirely locally, with no image transmitted to any external service. A photograph of a handwritten note from a source, a picture of a document taken in the field when scanning was not possible, a screenshot of a website before it was taken down - all become searchable text content within the vault.

For a journalist covering a story over months or years with hundreds of attached documents, the Q&A natural language search makes the investigation archive navigable in a way that manual document review does not. Describing what is being sought - “financial transfers to shell companies in 2021” or “communications about the board decision in March” - returns ranked results across every note and every attached document in the vault. The vote-based relevance learning means that results marked as relevant improve in ranking for similar future queries.

Version History: The Journalism Edit Trail

Journalism involves revision. Stories develop as new information arrives. Source notes are updated as conversations continue. Analysis changes as the evidentiary picture develops. A journalist who reviews their notes from three months ago and finds that an important detail has been overwritten, a source characterization has been revised without preserving the original, or an intermediate conclusion has been replaced by a later one is working without the edit trail that careful investigation requires.

VaultBook’s version history stores per-entry snapshots in a local /versions folder with a 60-day retention window. The history modal for any entry shows the full timeline of snapshots, allows viewing any previous version in full, and allows restoring any previous version as the current entry. The version history is stored locally as part of the vault, subject to the same zero-network-request privacy guarantee as the current note content.

For investigative journalists, the version history capability serves several specific functions. It preserves the development of analysis - a journalist can show, if necessary, how their understanding of a story evolved as evidence accumulated, which is both an editorial protection and a potential legal protection in situations where the basis for reporting is challenged. It enables recovery from accidental overwrites - when a source conversation adds new information that seems to supersede earlier notes, preserving the earlier notes through version history maintains the complete record. And it captures the state of the vault at specific points in time - a journalist who closes out an investigation can preserve a snapshot of the vault as of the story’s publication date.

Operational Security for Field Journalists

Journalists who work in the field - covering conflicts, reporting from authoritarian environments, attending events where device inspection is a risk, or crossing borders with sensitive material on their devices - face operational security requirements that domestic office-based journalists do not.

The single-file architecture of VaultBook has specific operational security implications for field journalists. The entire application and vault can exist as a folder of files with no installation, no registry entries, no system-level footprint beyond the files themselves. A journalist preparing for travel to a jurisdiction where device inspection is a risk can copy the vault to an encrypted external drive, remove the vault folder from the travel device entirely, and carry no trace of the investigation on the device that crosses the border. The vault can be restored when the journalist is in a secure environment.

VaultBook’s vault folder can be stored inside an encrypted container created by a full-disk encryption tool. The vault’s own per-entry encryption provides a second layer of protection within that container. The combination creates defense in depth - multiple encryption layers that a border inspector or confiscating authority would need to defeat sequentially.

The full-screen composition mode removes all interface chrome - page titles, sidebar navigation, application identifiers - from the screen during active writing sessions. A journalist working in a public location can use full-screen mode to reduce visual exposure of the vault’s content to observers in the environment.

The lock screen with password protection means that a momentary absence from a device - a bathroom break, a brief departure from a press conference - does not require closing and reopening the vault. A single lock action secures all vault content until the password is entered.

Organizing Source Networks: Labels, Hierarchy, and Filters

A journalist covering a beat, maintaining an investigative network, or managing a long-term source relationship program needs organizational tools that can represent the complexity of a source network without creating the kind of fragmentation that makes the network hard to use.

VaultBook’s organizational architecture supports source network management through multiple simultaneous dimensions. The nested page hierarchy allows sources to be grouped by beat, by organization, by geography, or by topic area - whatever organizational structure reflects the journalist’s actual working mental model. Drag-and-drop reordering allows the hierarchy to evolve as the network grows.

Color-coded labels provide cross-cutting classification that the page hierarchy alone cannot represent. A single source might be labeled with their primary beat relevance, their contact cadence (active vs. dormant), their current story relevance, and their relationship status. The label filter in the sidebar produces a view of all entries sharing a specific label - all currently active sources, all sources with pending follow-up, all sources relevant to the current story - regardless of where they sit in the page hierarchy.

Advanced compound filters combine labels, date ranges, and modification dates into precise queries. A journalist who wants to see all source entries that have been modified in the last 30 days, are labeled as active, and carry a specific beat label gets that exact view in a single filter operation. Multi-tab views maintain multiple filtered perspectives simultaneously - one tab showing the current story’s source network, another showing the general active contact list, a third showing the upcoming follow-up schedule via the Due tab.

The Favorites panel provides instant access to the sources and story notes that are most relevant to the current work. For a journalist actively developing a story, the five or ten entries in Favorites are the ones accessed multiple times per day - key source files, the central story analysis, the document evidence index - reachable without any navigation through the hierarchy.

AI Suggestions: The Contextual Memory Layer

The challenge of managing large volumes of source notes, investigation archives, and multi-year story development notes is not just storage - it is retrieval and rediscovery. Notes that were not relevant to the story in development when they were written may become highly relevant when a new angle emerges. Sources noted as background contacts may become primary contacts when a story develops in their direction. Earlier analysis that seemed like a dead end may illuminate a new lead.

VaultBook’s AI Suggestions carousel provides a contextual memory layer that surfaces potentially relevant material without requiring the journalist to know what to search for. The Suggestions page learns which entries are accessed on each day of the week based on four weeks of vault usage history - for a journalist who reviews specific source files every Monday before the weekly editorial meeting, those files surface automatically on Monday mornings. For a journalist who develops story notes on specific topics on specific days, the pattern learning makes the relevant material available without the recall burden of remembering what to open.

The Related Entries panel surfaces entries with semantic similarity to the currently open entry - a journalist working on a story about financial irregularities who opens a source file about accounting practices may see related entries about financial regulation, previous stories on related themes, and other source files with overlapping topic profiles. Each suggestion can be upvoted or downvoted, with votes training the local relevance model over time. The Related Entries panel becomes an increasingly accurate map of the intellectual connections in the specific vault.

All of this intelligence operates locally. The AI Suggestions are generated from local usage pattern analysis. The Related Entries similarity computation happens on-device. No vault content is transmitted to any inference service. No usage patterns are reported to any external service. The intelligence is private by the same architectural guarantee that applies to all vault content.

The Kanban Board: Story Pipeline Management

Journalists managing multiple concurrent stories, tracking the status of investigation threads, or coordinating parallel reporting lines can use VaultBook’s Kanban Board to maintain a visual project management view directly from vault entries.

The Kanban Board converts labeled entries and inline hashtags into a visual board with drag-and-drop card management. Story entries carrying status labels - “in-development,” “awaiting-response,” “ready-to-edit,” “published” - automatically appear as cards in the corresponding board columns. Moving a card changes the entry’s label, updating the organizational state directly.

For a journalist managing five concurrent stories in different stages of development, the Kanban Board provides the overview that would otherwise require a separate project management application - with the critical difference that the Kanban Board makes zero network requests and keeps the story status intelligence within the vault’s privacy boundary. A project management application that knows which stories a journalist has in development, which sources are being pursued for each, and what stage each investigation has reached is a significant intelligence asset that should not exist on any external server.

The Kanban Board updates automatically as entry labels change, without any manual maintenance. As stories advance through development stages, the board reflects the current state of the pipeline in real time.

The RSS Reader: Open-Source Intelligence Within the Privacy Boundary

Journalists who monitor beats, track developing stories, and maintain situational awareness across a domain use RSS feeds as a primary real-time intelligence layer. Government press release feeds, regulatory filing notifications, court document services, news wire feeds, specialized industry publications, and watchdog organization reports all publish RSS feeds that beat journalists monitor continuously.

The standard approach is to use a third-party RSS reader - Feedly, Inoreader, NewsBlur, or similar services. These services are cloud-based, require accounts, and maintain records of the feeds a journalist subscribes to and the articles they read. The subscription list itself is intelligence: a journalist whose RSS subscriptions are known to an adversary has revealed their source monitoring priorities, their investigative focus areas, and their institutional information environment.

VaultBook’s built-in RSS Reader operates entirely within the vault’s privacy boundary, making zero network requests for any purpose other than fetching the RSS feed content at the journalist’s explicit request. There is no account, no usage tracking by an external service, and no subscription list visible to any third party. The feeds a journalist monitors are private to the journalist.

The RSS Reader integrates directly with the vault’s note-taking capability. A journalist reading a significant news development in the RSS Reader can immediately save it as a vault entry using the URL-to-Entry tool, which captures the web content as a vault record that is indexed by the search system and associated with the relevant source files, story entries, and label categories. The captured entry is in the vault, not in a browser bookmark or a cloud-based read-later service.

For investigative journalists, the combination of private RSS monitoring and direct vault capture creates an open-source intelligence workflow that leaves no external trace: the journalist monitors relevant developments privately, captures significant items directly into the vault, and those items become part of the searchable investigation archive.

Tracking Follow-Ups: The Scheduling Layer for Journalists

Source relationships require maintenance. A source who provided information six months ago may be relevant again when a story develops. A request for comment sent to a spokesperson has a response deadline. A FOIA request filed with a government agency has a statutory response timeline. A document expected from a source has an agreed delivery date. A court hearing related to an ongoing story has a specific date and time.

Without a scheduling system integrated into the note-taking environment, journalists manage these time-sensitive items through a combination of memory, calendar applications, email flags, and separate task managers - each of which is a separate application with its own cloud infrastructure and its own privacy implications.

VaultBook’s scheduling features provide all of this time management within the vault’s privacy boundary. Due dates on individual entries surface in the sidebar Due tab - a vault-wide deadline view showing all approaching deadlines regardless of where entries sit in the organizational hierarchy. A journalist who assigns a due date to a “response pending” entry for each spokesperson request has a single view of all pending responses and their deadlines at all times.

Expiry dates create review prompts for source entries that should be revisited after a specified period. A journalist who notes a source’s concerns about timing can set an expiry date for when those concerns are expected to resolve - the entry surfaces for review when the time arrives, without requiring the journalist to manually remember the follow-up.

Recurrence patterns allow regular source check-ins to be scheduled as recurring entries - a monthly check-in reminder for a long-term confidential source, a weekly review of active investigation follow-ups, a recurring reminder to file a FOIA fee waiver request for ongoing monitoring.

The Timetable view provides the calendar overview - a day and week view showing all scheduled vault events on a 24-hour timeline, with disk-backed local persistence. The Timetable Ticker in the sidebar gives a running preview of upcoming scheduled items without requiring the full calendar view to be open.

All of this scheduling intelligence exists locally, associated with the source and story entries it belongs to, visible only to the journalist who maintains the vault. A separate calendar application that knows a journalist has a scheduled contact with a confidential source, or an upcoming deadline for a response request to a government agency, carries intelligence that should not exist on any external server.

The Threads Tool: Running Real-Time Story Capture

Breaking news, live press conferences, real-time source contacts, and ongoing developments in a fast-moving investigation all require a capture mode that is different from the structured note-taking that retrospective analysis involves. A journalist following a live development needs to capture observations, quotes, and impressions in rapid sequence, with timestamps, without stopping to organize or format.

VaultBook’s Threads tool provides a chat-style chronological capture interface within the vault. Each thread entry is a timestamped sequential message - type, press enter, and the observation is captured with a timestamp and added to the running thread. The thread can be reviewed in sequence, specific entries can be pingled for follow-up, and the entire thread is part of the searchable vault.

For a journalist at a press conference, the Threads tool provides a rapid capture mechanism that is faster than structured note entry and more organized than a blank text document. For a journalist receiving information from a source over an extended call, Threads provides a real-time capture environment that keeps the material in the vault from the moment of capture. For a journalist following a developing story across multiple sources in a single day, a thread for that day’s developments creates a timestamped chronological record that can later be organized into structured source entries.

The Threads tool, like every VaultBook built-in, makes zero network requests. The timestamps in the thread are local device timestamps. The thread content is stored in the vault folder alongside all other vault content.

A Walk-Through: How an Investigative Journalist Might Structure a VaultBook Vault

To make the organizational and security practices described above concrete, consider how an investigative journalist covering financial misconduct might structure a VaultBook vault for a long-running investigation.

At the top level of the page hierarchy: a page for the central investigation, pages for supporting context (regulatory environment, historical background, related cases), a page for the source network, and a page for published work.

Within the central investigation page: sub-pages for each major story thread, a sub-page for the evidence archive, and a sub-page for editorial and legal correspondence.

Within the source network page: one entry per source, each structured with sections for contact information, background context, specific information provided (subsectioned by date), follow-up items with due dates, and operational notes. The entries containing the most sensitive source details are encrypted individually with entry-specific passwords.

Labels applied across the vault: an “active” label for currently engaged sources, a “pending-response” label for outstanding contact attempts, a “key-document” label for the most significant evidentiary attachments, and story-specific labels linking evidence to the story threads they support.

The evidence archive holds FOIA responses, leaked documents, financial records, and supporting materials as attachments organized at the section level within individual entries. Every document is indexed by the deep attachment processing system - every PDF page, every spreadsheet cell, every email body is searchable by content.

The Kanban Board shows the story pipeline: threads in development, threads awaiting additional sourcing, threads ready for editorial review, and published stories.

The Due tab shows all outstanding follow-up items across the entire vault - every pending source contact, every FOIA response deadline, every spokesperson response request.

The AI Suggestions carousel surfaces the entries most relevant to the current day’s work based on usage history - on days when a specific story thread is being developed, the source entries and document evidence most associated with that thread surface automatically.

Encrypted entries require a password at the start of each session. The session caching means the password is entered once and the entries remain accessible for the working session. At the end of the day, the lock screen secures the vault.

This structure is not theoretical. It is the practical application of VaultBook’s architecture and features to the organizational needs of serious investigative journalism. Every component of the structure - the page hierarchy, the label system, the per-entry encryption, the section-level attachments, the deep indexing, the scheduling, the behavioral suggestions - is a native VaultBook capability requiring no plugin, no external service, and no network connection.

The journalist who builds this structure is also building something that grows more valuable and more intelligent over time. The vote-based search learning means that the queries used most frequently in an investigation train the search engine toward the most relevant results for that specific investigation. The AI Suggestions day-of-week learning means that the material most relevant to the current day’s work surfaces automatically as the investigation matures. The version history captures the evolution of analysis over months of development. The vault becomes not just a filing system but an active, adaptive research partner - entirely private, entirely local, and entirely under the journalist’s control.

The Integrated Security Posture: No Weak Links

The individual security features described above - zero network requests, per-entry encryption, lock screen, deep attachment indexing, version history, local intelligence - are individually powerful. What makes VaultBook’s security posture exceptional for journalism is the integration of all of these features into a single cohesive environment where there is no weak link in the chain.

Consider the alternative: a journalist using Obsidian for notes, a cloud storage service for document attachments, a separate task manager for follow-up tracking, a web application for source contact management, and a cloud-based search tool for document review. Each tool in that stack has its own privacy posture, its own potential breach surface, and its own set of terms that govern what the vendor can do with the content stored in it. The overall security posture is defined by the weakest link - the tool most accessible to legal process, most vulnerable to account compromise, or operating under the broadest data use terms.

VaultBook’s single-application architecture means the security posture is uniform across every function the journalist performs. Notes, documents, source files, story development, scheduling, project management, RSS monitoring, story pipeline visualization - all within the same zero-network-request, locally-stored, per-entry-encryptable environment. There is no weak link because there is no external tool dependency for any core function.

The built-in PDF tools handle document management without requiring any external PDF application. The File Analyzer handles data analysis from spreadsheets and structured files. The URL-to-Entry tool captures web content as vault entries before it can be taken down or modified. The Password Generator creates credentials for new research accounts within the same secure environment as everything else. Even the MP3 Cutter and Joiner handles the audio editing that arises from recorded interviews or audio source material - locally, within the vault’s privacy boundary.

A journalist who builds their investigation entirely within VaultBook has created a workspace with a single, consistent, verifiable privacy boundary. Every piece of source information, every document, every analytical note, every follow-up item, every story draft lives within an architecture whose privacy guarantee can be independently verified in sixty seconds with a browser’s developer tools. That verifiability - the ability to demonstrate, rather than merely assert, that the notes environment is genuinely private - is as important as the privacy itself for a profession whose credibility depends on the consistency between stated commitments and actual practice.

Source Protection as Professional Ethics

The obligation to protect sources is not merely a professional best practice - it is an ethical foundation of journalism as a public institution. The ability of powerful institutions to be held accountable by independent journalism depends on the ability of people inside those institutions to bring information to journalists with reasonable confidence that their identity will not be revealed. Every improvement in the tools available for source protection is an improvement in the practical capacity of journalism to perform its accountability function.

For two decades, the dominant note-taking tools available to journalists have been cloud-based applications designed for general professional productivity. They have excellent features, excellent user experience, and deeply inadequate privacy architecture for the specific requirements of source-protective journalism. The convenience of cloud sync, cross-device access, and collaboration features has been purchased at the cost of storing sensitive source material on servers that are accessible to the entities journalists are supposed to be holding accountable.

The structural misalignment is not the result of malicious intent by the cloud productivity vendors. Those vendors built tools for the general market, and the general market does not need protection from well-resourced institutional adversaries. Journalists covering powerful institutions do. The tools built for the general market are the wrong tools for that specific requirement, and using them because they are familiar and convenient is a professional risk that most journalists have not formally evaluated.

VaultBook’s architecture represents something genuinely new: a fully featured, professional-grade knowledge work environment built on a foundation that is structurally appropriate for journalism’s specific privacy requirements. Zero network requests is not a limitation to be overcome - it is the architectural expression of the commitment that source-protective journalism requires. What goes into the vault stays in the vault, and stays there because of how the system is built, not because of how many privacy promises the vendor has made or how strongly they mean them.

The journalist who uses VaultBook is not just choosing a private note-taking tool. They are choosing an architecture that is consistent with the ethical obligations of their profession, and a feature set powerful enough to support the most demanding investigative work without compromising those obligations at any point in the workflow - from the first source conversation to the last document attachment to the published story and the protected archive that follows it. In a media environment where the tools journalists use are increasingly scrutinized by the subjects of their reporting, a note-taking environment whose privacy is verifiable rather than promised is not a luxury. It is a professional necessity - and it is now available in a single, portable HTML file that fits in a journalist’s pocket alongside everything they need to do the work that free societies depend on.

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