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

Browser history is usually a list of titles and URLs. Hister turns it into something much more useful: a full-text search engine containing the rendered pages you visited, local files you chose to index, stored previews, and optionally earlier versions of those documents.

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

Hister’s browser extension runs on every normal website. Its manifest requests access to all URLs plus tabs, storage, and cookies. 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. On a single workstation, that is a reasonable quick start: the service is reachable only from that host unless something else proxies it.

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. Its source and tests show user IDs applied to documents, full-text results, semantic vectors, previews, and history. That is materially better than putting one global index behind a login page and calling it multi-user.

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.

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. If semantic retrieval is valuable enough, a local embedding service is the cleanest way to preserve the original boundary.

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.

Hister handles this more carefully than many early MCP servers. Tool output marks every source-controlled value as untrusted, strips invisible control characters, and places returned records under an explicit untrusted_content structure. 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.

That is the right kind of honesty for self-hosted software.

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.