Hister 0.17: Search Your Browsing History, Protect the Index

Hister solves a familiar retrieval failure: you remember reading the answer, but not the title, site, or exact phrase needed to find it again. Its browser extension can capture rendered pages as you visit them, while the server indexes those pages together with selected local files, imports, and crawled sites. Search then runs against a corpus you control instead of asking the public web to rediscover it.

The value is real, but so is the privacy inversion. Hister can reduce what you disclose to external search engines by creating one unusually sensitive local database of browsing history, authenticated page content, files, previews, searches, and optional embeddings. Pilot it on one encrypted machine with loopback-only access, deliberate exclusions, and semantic search disabled. Do not expose the stock container port to an untrusted network or connect the MCP endpoint to a high-authority agent until authentication, retention, prompt-injection, and restore tests pass.

This is a researched technical analysis of Hister 0.17.0 and upstream state observed on August 23, 2026. OpenSourceChoice inspected the tagged release, current repository, official documentation, package metadata, issue activity, and public discussions. We did not import a real browser profile, benchmark search quality, penetration-test the server, or independently audit the source and dependency tree.

Executive verdict

Why this matters now

Version 0.17.0 became the latest stable release on July 28. It added resumable imports from local files and services such as Karakeep and Linkwarden, durable semantic-indexing jobs, DOCX support, more query filters, crawler proxies, and GitHub issue extraction. It also changed import commands, date semantics, favicon API responses, domain normalization, and vector defaults, making the release operationally meaningful rather than cosmetic.

Development did not stop at the release. GitHub recorded 197 commits in the 30 days ending August 23, with work continuing through August 22. During the same observed window, 35 pull requests were opened and 30 were merged. That is a strong maintenance signal for a project created in January 2026, but it also means stable users should expect rapid change and keep the rolling build out of important deployments.

Independent interest is current. A Hacker News discussion reached 249 points and 68 comments on August 23, including reports from existing users, setup questions, privacy concerns, and comparisons with Karakeep, Linkding, SingleFile, and Recoll. A separate Open Source/Lemmy discussion from July 31 drew more than 100 votes, while an active r/selfhosted thread from July 29 included Hister among frequently used services. Those signals describe a genuine recall problem across different communities, not one launch post in isolation.

Hister was not on GitHub's daily Trending list during this review, and current Product Hunt, XDA, Lobsters, and indexed X checks did not add a comparable project-specific signal. The editorial case rests on a current stable release, sustained repository work, and repeated user interest—not on claiming universal adoption.

What Hister does—and what it does not

Hister is a personal full-text search system. It can collect content from:

• rendered pages submitted by its Firefox or Chrome extension;
• browser-history imports that fetch the pages as they exist at import time;
• watched directories and explicit local-file imports;
• recursive website crawls and prepared documentation datasets;
• imports from Linkwarden, Karakeep, Readeck, Shaarli, Wallabag, and related services;
• direct API clients and command-line indexing.

The browser extension is the distinctive path. It reads the loaded tab and submits the URL, title, extracted text, rendered HTML, and favicon to the configured server. Because this happens after rendering, it can capture JavaScript applications and pages visible only inside a signed-in session. Stored previews let the user read captured material without loading the original site again.

Search is available through a web interface, terminal UI, command line, HTTP API, and a Streamable HTTP MCP endpoint. Keyword search is the local default. Optional semantic search divides content into chunks, sends them to a configured embedding endpoint, stores vectors in SQLite or PostgreSQL, and merges vector matches with keyword results.

Hister is not:

• a general web index for questions about pages you have never collected;
• a faithful WARC-style evidence archive of every browser interaction;
• an automatic cloud synchronization service;
• an encrypted knowledge vault;
• a records-management system with legal holds or complete erasure workflows;
• a replacement for backups;
• a guarantee that extracted content, dates, or previews match what you originally saw.

Browser-history import illustrates the boundary. It reads old URLs from the browser database, then fetches their current contents. Changed, deleted, moved, or authenticated pages may therefore produce a different record from the historical visit. If preserving the original page is the goal, evaluate ArchiveBox or a SingleFile-based capture workflow in parallel.

Architecture and the real data boundary

The released application is a Go 1.26 server with an embedded web interface. Bleve stores full-text indexes, while SQLite is the default SQL backend for users, sessions, history, crawl jobs, version differences, and job state. PostgreSQL is optional. Saved HTML previews and favicons remain as files under the application data directory even when PostgreSQL is selected.

Semantic search adds another store. A default SQLite setup creates vectors.sqlite3 through sqlite-vec; PostgreSQL deployments use pgvector. The embedding model is external to Hister. It can be a local service such as Ollama or a hosted compatible endpoint, but the privacy result depends on that choice: document chunks and search queries go to the configured endpoint.

Upstream says the default server has no telemetry and needs no Hister cloud. The inspected release and documentation support that boundary, with two qualifications. Browser clients may retrieve favicons, and crawlers necessarily contact the sites being indexed. Optional embeddings are an additional outbound path. “Self-hosted” therefore means the primary index is operator-controlled, not that every enabled feature is offline.

The default local binary listens on 127.0.0.1:4433, which is a sensible personal starting point. The official 0.17 Compose file is different: it sets the container to 0.0.0.0:4433 and publishes 4433:4433, while authentication remains opt-in. Docker normally publishes that port on every host interface. On a laptop, NAS, or homelab attached to an untrusted network, the stock Compose topology can therefore widen access beyond the operator's browser.

Start with one of these boundaries:

1. run the binary on loopback only;
2. bind the container to 127.0.0.1:4433:4433 and reach it through an authenticated private tunnel;
3. place it behind an HTTPS reverse proxy and enable an access token or user handling before accepting traffic from another device.

Hister does not terminate HTTPS itself. Its access tokens and sessions require TLS whenever traffic crosses an untrusted network. Public mode is for an intentionally shared corpus; it makes global search results, previews, files, API documentation, and MCP search available anonymously. Never enable it on a personal index.

The privacy paradox: useful capture is sensitive capture

The browser extension can see exactly why Hister is useful: the final page visible to the signed-in user. It can also see account dashboards, private discussions, invoices, internal documentation, recovery information, and secrets rendered into a page. The documentation warns that private account pages can be submitted and recommends skip rules plus sensitive-content patterns.

Those filters are defense in depth, not a complete data-loss-prevention system. Pattern matching happens after the extension has read the page and is only as complete as the rules. A novel token, personal message, or one-time code may not match. The safe pilot starts with automatic capture disabled or restricted to an allowlist of low-risk domains, then expands only after reviewing stored results.

Hister does not encrypt indexed data at the application layer. Search indexes, stored previews, SQL data, vectors, and backups should be assumed readable to the host administrator and to a process that compromises the running host. Use full-disk encryption for powered-off storage, encrypted off-device backups, restrictive filesystem permissions, and a host dedicated to trusted workloads. Disk encryption does not protect an unlocked running server.

Retention needs equal attention. Upstream estimates about 100 KB of storage per page on average, with no automatic expiry, document-count ceiling, or total disk quota. A simple planning extrapolation is roughly 10 GB per 100,000 pages before filesystem overhead, semantic vectors, version differences, logs, and backup copies. Measure the real corpus rather than treating that estimate as a capacity promise.

Deleting browser history, removing a bookmark, or uninstalling the extension does not delete the Hister copy. Deleting a Hister document removes its current index record and current assets, but related version records, crawl state, logs, exports, snapshots, and backups may remain. Upstream explicitly says there is no single complete-erasure command. A regulated retention promise therefore requires external inventory and deletion procedures.

MCP adds retrieval value and prompt-injection risk

Hister's MCP endpoint can search documents, return stored previews, and inspect history. That makes a private research corpus available to compatible assistants without first moving it into a proprietary knowledge base.

It also converts every indexed page into potential prompt-injection input. The official MCP documentation correctly marks titles, URLs, metadata, document bodies, and history fields as untrusted. Responses place source-controlled values in an untrusted_content structure and strip invisible control characters. Those are useful signals, but the maintainers do not claim they eliminate attacks.

Treat the Hister server as a read-only research tool. The consuming agent should not follow instructions found in indexed content, disclose secrets, or invoke shell, file, email, browser, or network actions without separate authorization and confirmation. Do not give one agent both unrestricted Hister retrieval and high-impact write tools during the pilot. Optional semantic search also means that the query and document chunks may cross a second trust boundary at the embeddings provider.

Installation, maintenance, and current limitations

Hister 0.17.0 publishes checksum-listed binaries for Linux AMD64/ARM64, macOS Intel/Apple silicon, and Windows AMD64. Official GHCR images cover AMD64 and ARM64, and the documented latest image runs as a non-root user. Nix modules and packages are also documented. Building from source requires Go 1.26, npm, and a C compiler because the application uses CGO dependencies.

Pin the exact binary release or container digest. The repository maintains a rolling prerelease that tracks master; it is useful for testing fixes, not as a production update channel. Release assets provide SHA checksums, but the inspected v0.17.0 page did not expose a signed SBOM or provenance attestation, so operators with supply-chain requirements need their own source-build or artifact-verification policy.

The project is active but young. GitHub attributed 1,487 of 1,906 contributions in its contributor view to the lead maintainer when checked, about 78%. Other contributors are active, yet design and release knowledge remains concentrated enough to matter for a long-lived service.

Current issues also show the edge of 0.17. One report says a few failing large files can repeatedly occupy the semantic-indexing queue. Another reports frequent Firefox re-indexing of open tabs on version 0.17.0. Safari support remains an open proof-of-concept pull request, and the maintainer said current mobile automatic capture depends on Firefox because mobile Chrome does not support extensions. These are reasons to pilot the exact client mix, not evidence that the core keyword index is unusable.

Hister has a short security policy with a private reporting email, and GitHub's repository advisory API returned no published advisories on August 23. That is not evidence of an independent security audit or proof that no vulnerabilities exist. The high-value data held by the service warrants a narrow network boundary even when no advisory is public.

License, commercial use, and portability

Hister is licensed under AGPLv3 or any later version. Commercial and internal use are allowed. Organizations that modify the software and let users interact with that modified version over a network should review the AGPL source-offer obligations; distributing modified copies carries the usual corresponding-source and notice duties. This is an operational summary, not legal advice.

There is no hosted-service subscription or mandatory vendor API. Infrastructure can be one existing machine and local SQLite, so direct cost can be zero beyond storage, electricity, backups, and operator time. Hosted embeddings, a VPS, managed PostgreSQL, or off-site storage create optional charges and new data processors; none are required for keyword search.

Portability is mixed but workable. hister export writes current documents and available current previews to JSON for migration to another Hister instance. It is not a complete backup: users, search history, crawl jobs, version differences, rules, sessions, and configuration are excluded. A full recovery requires the entire application directory, external configuration, PostgreSQL backup when used, and separate copies of watched source files.

The safest exit plan is to keep source URLs and original files authoritative, use JSON export for current indexed content, and test a complete restore into an isolated server. Do not make a proprietary embedding format or one Hister search workflow the only path to irreplaceable knowledge.

Alternatives to evaluate in parallel

Karakeep is the most useful direct comparison for many people. Choose it when capture should be an explicit act of curation. Choose Hister when the recurring failure is forgetting to save a page in the first place. They can coexist because Hister 0.17 imports Karakeep content.

A measurable seven-day pilot

1. Define the corpus and exclusions

Use a fresh browser profile and copied, non-sensitive files. Start with automatic capture disabled. Create an allowlist of two documentation domains and explicit deny rules for email, banking, identity, health, password, billing, admin, and internal-work URLs.

2. Establish the private boundary

Run stable 0.17.0 on an encrypted host. Bind to loopback only. If a second device is required, use a private tunnel or HTTPS reverse proxy, enable authentication first, and verify from an unauthenticated device that the index, previews, history, API, and MCP endpoint are unreachable.

3. Measure capture and retrieval

Index 500 representative pages and 100 copied files. Prepare 30 recall questions whose answers are known. Record top-five retrieval success, false matches, time to first useful result, indexing failures, and disk growth. Keep semantic search off to establish the keyword baseline.

4. Test sensitive-data controls

Visit synthetic pages containing mock tokens, account numbers, personal text, and one-time-code patterns. Confirm excluded domains never appear. Search every synthetic secret. Treat one unintended stored secret as a failed gate, then improve the rule or shrink the capture scope.

5. Exercise deletion and retention

Delete ten items, clear the test browser history, remove one watched file, and inspect the index, previews, version data, crawl jobs, exports, logs, and backups. Configure delete_on_remove where appropriate and document every retained copy that still needs an external lifecycle action.

6. Restore and upgrade

Back up the full application directory and configuration, create a JSON export, then restore to an isolated machine with the same pinned version. Require the 30 saved queries and representative previews to work. Rehearse a version upgrade only on that restored copy.

7. Add integrations last

Connect the MCP endpoint to an assistant with no write tools and test pages containing hostile instructions. Require the assistant to treat them as quoted source material. Enable local embeddings only if keyword recall misses the target; measure whether the improvement justifies the extra CPU, vector storage, queue behavior, and model lifecycle.

Adopt only if at least 27 of 30 recall questions return a useful top-five result, no synthetic secret escapes the exclusions, unauthenticated network access is zero, disk growth fits a documented budget, all pilot data can be deleted under the retention procedure, and the full restore succeeds within the recovery target.

Final assessment

Hister 0.17 is a credible answer to a real problem that bookmarks and public search only partially solve. Its automatic rendered-page capture, local full-text index, offline previews, imports, query language, and MCP surface form a coherent product rather than a README demo. Current maintenance and community interest justify evaluation.

The difficult part is not search. It is operating the index as sensitive infrastructure. Hister deliberately remembers material that browsers, websites, and users normally forget. That makes disk encryption, network isolation, authentication, exclusions, retention, backups, and agent boundaries part of the product's real cost.

Pilot Hister as a loopback-only keyword search service for a low-risk corpus. Expand capture, multi-device access, semantic search, and MCP one boundary at a time. If the team cannot name who owns those boundaries, choose intentional capture with Karakeep or local file search with Recoll instead.

Sources and verification notes

Project, release, repository, package, documentation, issue, and community state were checked on August 23, 2026. Dynamic counts are dated discovery or maintenance signals, not quality guarantees. Technical conclusions are OpenSourceChoice editorial analysis, not claims of hands-on validation.

Primary and official sources

• Hister v0.17.0 release notes — Hister maintainers; released July 28, 2026; current stable features, fixes, assets, and compatibility notes.
• Hister repository and current commit history — upstream source; maintenance and architecture state observed August 23, 2026.
• Hister introduction and privacy model — official current documentation; scope, client/server model, plaintext storage, retention, and HTTPS guidance.
• Browser ingestion and browser extension guide — official current documentation; rendered-page capture, history-import limits, controls, and client compatibility.
• Installation guide — official current documentation; stable binaries, checksums, Docker, Nix, supported platforms, and build requirements.
• Docker guide and v0.17.0 Compose file — official package and deployment defaults.
• Server setup — official current documentation; listen topology, internet exposure, TLS, reverse proxies, and public mode.
• User handling — official current documentation; tokens, password and OAuth/OIDC login, sessions, multi-user isolation, and security considerations.
• Data storage and lifecycle — official current documentation; files, databases, storage estimate, retention, deletion limits, backups, and exports.
• Configuration reference — official current documentation; SQLite/PostgreSQL, semantic search, sensitive-content patterns, access tokens, and public mode.
• MCP integration and untrusted-content guidance — official current documentation; tools, authentication, prompt-injection controls, and residual client obligations.
• AGPLv3-or-later license — Hister contributors; license at the evaluated tag.
• Security policy and repository advisories — private reporting route and published-advisory state observed August 23, 2026.
• Official Hister container package — GHCR package state observed August 23, 2026.
• Issue #601: failing files can occupy semantic processing, issue #602: repeated Firefox indexing, and Safari pull request #46 — current limitations observed August 23, 2026.
• Karakeep repository, ArchiveBox documentation, Recoll manual, and SearXNG project description — official alternative scope checked August 23, 2026.

Trend and community context

• Hacker News discussion — August 23, 2026; 249 points and 68 comments at observation time; independent interest and operational questions.
• Open Source/Lemmy discussion — July 31, 2026; independent interest, early-user feedback, and storage questions.
• r/selfhosted services discussion — July 29, 2026; community adoption signal.