Cloud APIs are the obvious choice for browser extension developers. They are fast to integrate, easy to scale, and someone else handles the infrastructure. I get the appeal. But when your product is a browser history tool, the thing you are asking users to hand over is one of the most personal datasets that exists. I could not do it.
What bugs me most is that most users do not realize what they are agreeing to. They install an extension, click "Allow," and their entire browsing history starts flowing to a server they have no visibility into.
What actually happens when you use a cloud-based history tool
When an extension sends your browsing data to a cloud API, several things happen that are worth thinking through carefully.
First, your URLs travel over the network. Even with HTTPS, the destination server logs them. The company operating that server now has a timestamped record of every site you visited, every search you ran, every medical symptom you looked up, every job listing you clicked. That is not hypothetical. That is the architecture.
Second, that data persists on their servers under their retention policy, not yours. If that policy changes (and it can, usually buried in a terms-of-service update), you find out after the fact. If they get acquired, your data goes with them. If their servers get breached, your history is in the leak.
Third, many cloud-based tools use your browsing data to train models or improve their service. That is often buried in the terms too. You contributed your browsing history to their product without realizing it.
I am not trying to be alarmist. Plenty of cloud-based tools are built by people with good intentions. But good intentions do not protect against subpoenas, security incidents, or a change in business model.
The technical problems with cloud APIs (beyond privacy)
Even setting privacy aside, cloud APIs create real engineering headaches for an ambient browser history tool.
Rate limits. AI embedding APIs have usage limits. If you are indexing every page a user visits across a full browsing session, you hit those limits fast. You either cap the user's indexing (which defeats the purpose), throttle in ways that feel broken, or pay for higher tiers.
Latency. Every page visit requires a round trip to an external server for indexing. That round trip adds overhead. For a background extension that is supposed to be invisible, added latency is a real problem.
Internet dependency. A tool that requires an internet connection to search your own local browsing history is a strange product. If you are on a plane, in a hotel with spotty WiFi, or on a train, you are out of luck. The pages you visited are on your machine. The search index should be too.
Ongoing cost. API tokens for embeddings are not free. That cost either gets passed to users through subscription pricing, or it gets subsidized by monetizing user data in some form. Neither is great.
Vendor lock-in. When your history lives on an external service's servers, you are dependent on that service staying alive, staying affordable, and maintaining a compatible API. If they shut down, raise prices, or change their feature set, you have limited options. Your data may not be exportable in a useful format, or at all.
What "ambient" indexing means at scale
An ambient history tool is different from a deliberate bookmarking tool. It does not ask you to do anything. It indexes everything you visit, passively, in the background. That sounds simple, but the scale implications are significant.
A typical knowledge worker visits 50-150 unique pages per working day. Over a year, that is 12,000-37,000 pages. Each page needs its text extracted, deduplicated, compressed, and indexed. For a semantic search index, each page also needs a vector embedding generated.
With a cloud API, that means 12,000-37,000 API calls per year per user, just for indexing. At any reasonable usage-based pricing, that adds up. And that is before you consider search queries, which add another layer of API calls.
The only economically sustainable path for a cloud-based ambient history tool is either high subscription pricing (which limits the addressable market) or data monetization (which undermines the privacy promise). There is no third option where the cloud API costs are just absorbed indefinitely.
Local-first architecture does not have this problem. The compute runs on the user's machine. The marginal cost of an additional page indexed, or an additional search run, is zero for us and trivially small for the user. That economic alignment matters.
The specific risks of cloud storage for browsing data
Browsing data is not like other data. It is behavioral. It tells a story about who you are, what you are worried about, what you are interested in, and what decisions you are making.
Consider what a complete browsing history reveals:
- Health concerns (every symptom you searched, every condition you researched)
- Financial decisions (the investment strategies you read about, the loan rates you checked)
- Career moves (the job listings you visited, the company research you did before an interview)
- Relationship details (the advice articles, the relationship counseling resources)
- Political and religious views (the news sources, the forums, the advocacy organizations)
- Professional work (the documentation, the research, the competitor analysis)
This dataset is more revealing than most people's email. And yet people hand it to cloud services without thinking twice, because the service is useful and the risks feel abstract.
They are not abstract. A data breach at a cloud history service exposes this dataset. A subpoena served on the company reaches it. A policy change allows new uses. An acquisition puts it under different ownership with different values.
With a local-first tool, none of these attack vectors exist. The data never leaves your device. There is no server to breach, no company to subpoena, no policy to change.
How we handle the hard parts of local-first AI
Running AI search entirely in-browser required solving several non-trivial engineering problems. I want to be transparent about how we approached them, because "runs locally" can mean different things.
Model selection. We chose all-MiniLM-L6-v2 specifically because it is small enough to run efficiently in WebGPU (the model file is under 90MB) while producing high-quality 384-dimensional semantic embeddings. Larger models produce marginally better embeddings but are impractical for browser-based inference. The quality trade-off is worth the performance gain.
Inference acceleration. We run the model via WebGPU where available, which uses the device's GPU for matrix operations and delivers significantly faster inference than CPU-only WASM. On devices without WebGPU support, we fall back to WASM with SIMD acceleration. Most modern laptops and desktops have WebGPU available in Chrome.
Storage efficiency. Storing full page content for tens of thousands of pages could easily use gigabytes of browser storage. Mozilla Readability strips navigation, ads, and boilerplate, keeping only the readable content. lz-string compression then reduces that by 50-70%. SHA-256 deduplication means the same article published in multiple places only takes one storage slot. The result is a history index that grows slowly and stays manageable.
Search quality. Pure vector search sometimes returns semantically related results that are not what you actually want. Pure keyword search misses synonyms and concept similarity. Reciprocal Rank Fusion combines both: it ranks results from the vector search and the FlexSearch full-text search separately, then merges the ranked lists in a way that rewards pages appearing high in both. Results that score well on both meaning and keywords surface first.
What we built instead
TraceMind runs entirely in-browser. The indexing, the AI model, the search index, all of it lives on your device. When you visit a page, the content is extracted, compressed, deduplicated, and stored in IndexedDB. The all-MiniLM-L6-v2 model runs locally via WebGPU or WASM to generate embeddings. Search runs on your machine, returning results in under 100 milliseconds with no network dependency.
SPA navigation is handled by intercepting pushState and replaceState events, so dynamic apps like Twitter, Notion, and GitHub are captured correctly even without a full page reload.
The only external server call TraceMind makes is license validation for Pro users. That call contains no browsing data. Free users are completely air-gapped from our servers.
For the detailed technical write-up on how we designed the local IndexedDB schema, chose the model, and optimized inference for browser environments, see the building local-first AI post.
The encryption question
If you want an additional layer of protection, TraceMind Pro includes optional AES-256-GCM encryption with PBKDF2 key derivation at 200,000 iterations. The encryption key is derived from a passphrase you set. We never see it. This is designed for users who want to export and import their indexed history across devices while keeping the data protected in transit.
This is the kind of security you cannot offer with a cloud-based architecture, because the data is already on someone else's servers.
What you give up with local-first
I want to be honest about the trade-offs. Local processing means the compute happens on your machine. On lower-end hardware, the first embedding pass for a large history can take a few minutes. WebGPU acceleration helps significantly, but it is not a zero-cost operation.
You also cannot access your history from another device by default, the way a cloud-based tool might let you. TraceMind's encrypted export/import (Pro) is a workaround, but it requires you to manually move the file. That is a real friction point.
Sync across devices is the one genuine advantage cloud-based tools have. We are thinking about how to solve that without compromising the local-first model.
Why this still feels like the right call
If you have read about the actual risks of sharing browsing data with cloud services, you already understand the concern. Browser history is not just a list of URLs. It is a map of your interests, your health concerns, your financial decisions, your research process, your relationships. It is the kind of dataset that, in the wrong hands, could be used to build a detailed profile of exactly who you are and what you care about.
I did not want to build a product that requires users to hand that over. Full stop.
The alternative, building something that runs entirely in your browser, is harder. It took real engineering work to get the all-MiniLM-L6-v2 model running efficiently in WebGPU, to design an IndexedDB schema that scales to hundreds of thousands of pages, to keep search latency under 100ms without a server-side index. But it was worth it.
The result is a tool that genuinely cannot leak your data to anyone, including us, because we never receive it in the first place.
The free tier and what it includes
TraceMind's free tier gives you unlimited page indexing, 365-day retention, and 320x240 screenshots. There are no usage limits, no API costs to pass through, because there are no API calls. You can exclude up to 3 domains from indexing (banking sites, for example).
Pro adds 1920x1080 screenshots, the Offline Page Viewer (full HTML snapshots served locally in a sandboxed iframe), notes, AI tag suggestions, pinning, encrypted export/import, advanced analytics, and unlimited excluded domains.
None of it requires your browsing data to leave your machine.
If you want to see what a local-first ambient history tool actually feels like, TraceMind is free to install. You can also read more about how the local-first architecture was designed if you want the full technical breakdown.
The web does not need another tool that trades your privacy for convenience. There is already plenty of that.