Hister Turns Browser History Into a Search Engine—and a High-Value Database

That solves a problem I recognize. I often remember the idea I read, a sentence fragment, or roughly when I found it—not the site or title. Bookmarks are almost useless in that situation because I first have to remember that I bookmarked the page.

Hister searches the content itself. It can run on one machine, accepts pages from a browser extension, watches directories, imports existing history, and exposes the same index through a web UI, terminal, API, and MCP. It has no telemetry and requires no Hister cloud service.

I like the design. I would also treat the resulting database as more sensitive than browser history.

The extension does not save a list of visits

At the reviewed revision, Hister’s extension manifest requests access to all URLs plus tabs, storage, and cookies. Browser restrictions and capture settings still determine which pages it can collect. As a page loads, it captures the title, full text, HTML, and favicon, then submits that material to the Hister server. It keeps watching single-page applications and resubmits changed content on a backing-off interval.

That is why the search can work so well. It is also the boundary to understand before installation.

A URL may reveal that I visited a payroll system. Captured page text may contain the employee, amount, navigation state, and whatever else was rendered at the time. The same distinction applies to webmail, internal dashboards, support systems, medical portals, private Git repositories, and admin panels. “Browsing history” undersells the data; this is a partial content archive of authenticated sessions.

Hister provides skip rules, controls for disabling a page or domain, a pause switch, and a configurable sensitive-content check. Those are useful defenses. They depend on the operator knowing what should be excluded and expressing that boundary before the page is collected. A regular expression will catch patterns it knows about, not the full category of information I later wish I had never retained.

My starting policy would be denylisting entire classes of authenticated applications before enabling automatic capture. I would then use manual indexing for the occasional useful page inside an excluded domain. Hister supports exactly that override, although a manually indexed document remains an intentional exception that should survive review.

“Local” is a topology, not a security property

The default server listens on 127.0.0.1:4433 and does not require authentication. Loopback keeps direct network clients out; it does not isolate the service from other processes or users able to connect within the same network namespace. A shared workstation still needs authentication. A proxy or port forward can also expose that listener elsewhere.

The deployment changes as soon as several browsers send data to one server. Binding to 0.0.0.0, publishing Docker’s port, or adding a reverse proxy turns a local application into a network service. At that point I would require HTTPS and authentication before the first remote client connects, restrict the network path, and include the index in access reviews and backups.

Hister supports a static access token, multiple users, OAuth/OIDC, and personal tokens. The reviewed source applies user IDs to retrieval, including previews and history. Its documented search scope also includes global documents owned by user ID 0; enabling multiple users does not make those documents private to one account. I would verify ownership before importing sensitive material.

It does not encrypt the indexed data. The documentation says so directly and recommends disk encryption where needed. Documents also have no automatic expiry or total storage quota. Neither choice is unreasonable for a self-hosted application, but both choices transfer policy to the operator.

Disk encryption protects a lost drive or offline copy. It does not protect the data from a compromised Hister process, a valid API token, an overprivileged backup system, or an assistant allowed to retrieve it. Backups need the same classification and retention policy as the live index. Deleting a page from search while leaving months of snapshots elsewhere is not deletion in the sense most people expect. The reviewed lifecycle documentation also says document deletion leaves stored version differences in SQL. Pause or exclude the collector first, or it can submit the document again. Then account for versions, exports, logs, and backups separately; disappearing from search is not evidence of complete erasure.

Embeddings can send the archive somewhere else

Normal full-text search stays on the Hister server. Optional semantic search chunks document text and sends it to an OpenAI-compatible embeddings endpoint selected by the operator.

That endpoint can also be local. If it is remote, “self-hosted search” no longer means all document content remains on infrastructure I control. The material sent for embedding can include text captured from authenticated pages and local files. The question is not whether the model returns prose; embedding services still receive the input.

Hister makes semantic search opt-in and documents the transfer. I would leave it off until the embedding endpoint, logging, data retention, account agreement, and network path had been reviewed. A local embedding service avoids sending text to a remote embedding provider, but I would still inspect its logging, network access, credentials, and backups. The MCP client is another possible exit: a cloud-hosted assistant can receive retrieved text even when both the index and embeddings stay local.

MCP turns an archive into agent memory

The MCP integration is the feature most likely to make Hister genuinely useful to me. An assistant can search the index, retrieve complete stored text or HTML, open previews, and inspect recently indexed or opened history. That turns “I know I read something about this” into a tool call.

It also connects a high-value archive to a system designed to act on natural-language content.

At the reviewed revision, the MCP response builder labels source fields as untrusted, removes invisible control characters, and wraps records in an explicit untrusted_content structure. The repository includes tests for that formatting; this is a source review, not an end-to-end prompt-injection test. HTML is returned only when requested or used for a preview. The documentation warns clients not to let indexed instructions trigger file, shell, browser, email, or network actions.

Those controls describe the problem; they cannot eliminate it. A malicious page can place a prompt injection in ordinary visible text. Months later an assistant may retrieve it because it matches an unrelated question. Whether the warning is honored depends partly on the MCP client and model, not only the Hister server.

I would connect the index to a read-only assistant context first. Retrieval should not share an unrestricted execution loop with email, shell access, secrets, or production APIs. If a workflow needs both, any transition from retrieved content to an external action should be visible and confirmed.

I would run it, but I would not casually expose it

Hister is not pretending privacy comes from a logo. The defaults are loopback-only, semantic search is optional, the source is public under AGPLv3, multi-user ownership reaches into the index, and the MCP implementation acknowledges prompt injection. The documentation also says plainly that storage is unencrypted and retention is the operator’s job.

Before importing a real browsing profile, I would use a disposable index and a synthetic page containing a unique marker. Confirm capture with it enabled, repeat with the domain excluded, and check what remains after deletion with versioning enabled. Repeat retrieval as a second user and through MCP. Those are proposed acceptance checks, not tests I have run against a personal archive.

My deployment would be boring: a dedicated host or tightly isolated container, encrypted storage, no public mode, authentication enabled, TLS at the first network hop, restricted ingress, local embeddings if I enabled them, excluded sensitive domains, and tested deletion and restore procedures. I would monitor storage growth because full HTML, files, versions, vectors, and backups can turn “small personal service” into a durable record surprisingly quickly.

The trade is straightforward. Hister becomes useful by remembering more than a browser normally remembers. That memory deserves to be operated like the personal knowledge system it is, not installed like another bookmark extension.

Sources

• Hister, project overview and privacy model.
• Hister, browser extension documentation.
• Hister, MCP integration and prompt-injection guidance.
• Hister source repository, reviewed at commit 2f7d70a. Source claims refer to this revision, not every later release. Privacy and retention details rechecked October 10, 2026.