TraceMind Logo
TraceMind
FeaturesPricingBlogFAQCompare
Add to Chrome
TraceMind Logo
TraceMind

Core history search stays on your device; optional Pro Chat uses your chosen AI provider.

Available in the Chrome Web Store

Product

  • Features
  • Pricing
  • Add to Chrome
Compare
  • vs Chrome History
  • vs Heyday
  • vs Microsoft Recall
  • vs Memex
  • vs Rewind
  • vs SurfMind
  • vs Recall.ai
  • vs MyMind

Resources

  • FAQ
  • Blog
  • Changelog
  • About
  • Contact Us
  • Email Support

Legal

  • Privacy Policy
  • Terms of Service
  • Manage Subscription

© 2026 TraceMind. All rights reserved.

Local-first core search · Optional provider-backed Chat · Privacy by design

We use privacy-friendly analytics

We'd like to load Google Analytics to understand which pages are useful. No ads, no cross-site tracking, and nothing loads until you agree. See our privacy policy.

  1. Blog
  2. Why We Avoided Cloud APIs for Our Browser History Tool
March 11, 2026•11 min read•By Fuat Shakjiri

Why We Avoided Cloud APIs for Our Browser History Tool

privacyoffline-aion-device-aibrowser-history
Why We Avoided Cloud APIs for Our Browser History Tool cover

Update (2026-08-01): This article records why TraceMind avoided cloud APIs for its core capture, indexing, storage, and search architecture. Optional Pro Chat was added later as a separate, user-triggered boundary: it sends the question, prior turns in the current chat, and selected excerpts, titles, and URLs directly to the AI provider configured by the user. TraceMind does not proxy or store those Chat requests.

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.

A local-first core removes TraceMind's hosted browsing index from those attack paths. The local device remains part of the threat model, licensing uses TraceMind's API, and optional Pro Chat sends selected context directly to the configured provider when invoked.

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's core capture, indexing, storage, and search run in-browser. For eligible pages it can access, readable content is extracted, compressed, deduplicated, and stored in IndexedDB. The all-MiniLM-L6-v2 model generates embeddings locally through WebGPU or WASM, and core search needs no hosted search service.

Supported SPA navigation is detected through pushState, replaceState, and popstate events. Capture still depends on the page being eligible, accessible, and readable.

TraceMind's core capture, indexing, storage, and search do not use a cloud API. Licensing uses TraceMind's API. Optional Pro Chat, added later, sends the question, prior turns in the current chat, and selected excerpts, titles, and URLs directly to the configured provider when invoked.

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

TraceMind Pro can optionally protect supported local content and create new encrypted backups with AES-256-GCM. New passphrases use PBKDF2 at 600,000 iterations, while legacy 200,000-iteration data remains readable. The passphrase stays on the device, and importing or decrypting an encrypted backup remains free.

This adds a protection layer for local content and portable backups without requiring TraceMind to host the browsing corpus.

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 cannot access your history from another device automatically. A passphrase-encrypted backup is the manual bridge: creating one requires Pro, while importing or decrypting one is free.

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 in a fraction of a second without a server-side index. But it was worth it.

The result is a core search system with no TraceMind-hosted browsing-history index. Optional Pro Chat is a disclosed, user-triggered provider boundary rather than part of indexing or search.

The free tier and what it includes

TraceMind Free includes the full semantic and keyword search engine, 320x240 screenshots, up to 10 excluded domains, no TraceMind page cap, and captured-history retention that defaults to keep forever subject to browser storage capacity. Core indexing and search make no provider API call; optional Pro Chat is separate.

Pro adds 1920x1080 screenshots, sandboxed Offline Page Viewer reading copies, notes, AI tag suggestions, pinning, creation of passphrase-encrypted backups, advanced analytics, and unlimited excluded domains. Reading copies are not guaranteed complete archives, and importing or decrypting encrypted backups remains free.

The core features in both plans keep the browsing corpus local. Optional Pro Chat is the disclosed exception and sends only the selected context for a user-triggered request.

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.

Share this article

TwitterLinkedIn

Related Posts

March 27, 2026·7 min read

How to Access Your Browser History Offline (On a Plane)

How TraceMind can search previously indexed, eligible pages offline after its local model is ready, plus the limits of snapshots, Chat, and licensing.

February 26, 2026·4 min read

Full-Text Search vs. Title Search in Browser History

Browser history searches titles and URLs, not the text you read. Learn when full-text, semantic, and hybrid search each recover a forgotten page best.

June 13, 2026·11 min read

Heyday Alternative: Why I Built a Local-First Web Assistant

Heyday uploads your browsing record to the cloud; a local-first alternative keeps it on your device. A privacy-focused Heyday comparison with semantic search.

Ready to try TraceMind?

Search your browser history by meaning, not just titles. Private, local-first core search.

Add to Chrome (Free)View Pricing
← PreviousRAG in the Browser: Grounding AI in Your HistoryNext →The 7 Best Rewind AI Alternatives for Windows and Mac Users