# garlic.ai field notes > Engineering notes on private AI chat, browser-side encryption, and what privacy promises should actually mean. - Blog index: https://garlic.ai/blog - RSS feed: https://garlic.ai/rss.xml - JSON Feed: https://garlic.ai/blog.json - Negotiated feed: https://garlic.ai/blog/feed - Full text bundle: https://garlic.ai/llms-full.txt ## Posts - [What private AI chat should hide](https://garlic.ai/blog/what-private-ai-chat-should-hide): A practical engineer's view of what AI chat privacy should protect: plaintext, saved history, and the trust boundary between the browser and the server. Markdown: https://garlic.ai/blog/what-private-ai-chat-should-hide.md - [Saved on device is a product decision](https://garlic.ai/blog/saved-on-device-is-a-product-decision): Why garlic.ai keeps chat history local by default and treats sync as a privacy tradeoff, not a missing feature. Markdown: https://garlic.ai/blog/saved-on-device-is-a-product-decision.md - [Private search needs a smaller promise](https://garlic.ai/blog/private-search-needs-a-smaller-promise): How garlic.ai thinks about AI chat with web search: useful context, narrow claims, and no pretending metadata does not exist. Markdown: https://garlic.ai/blog/private-search-needs-a-smaller-promise.md --- # What private AI chat should hide Most AI privacy claims ask you to trust a policy. I care more about where the plaintext exists. - Canonical: https://garlic.ai/blog/what-private-ai-chat-should-hide - Markdown: https://garlic.ai/blog/what-private-ai-chat-should-hide.md - Published: 2026-07-03 - Updated: 2026-07-03 - Author: Michael Ryaboy - Category: Privacy engineering - Reading time: 3 min read - Keywords: private AI chat, encrypted AI chat, browser-side encryption, confidential AI, AI privacy When people ask whether an AI chat app is private, they usually get a policy answer. The company says it will not train on your prompts, or it will retain data for fewer days, or enterprise administrators can configure a setting. Those promises matter, but they are not the boundary I want to depend on. The boundary I care about is simpler: where does the readable prompt exist? If the server receives plaintext, the server has to be trusted. If logs, retries, queues, analytics, or support tooling touch plaintext, the operating surface gets larger. Good people can still build systems that accidentally preserve too much. ## A private chat should move the boundary into the browser garlic.ai uses PrivateMode in the browser so the message is sealed before it crosses the app server. The app server still has a job: it forwards protocol traffic and injects the server-side PrivateMode credential. But the goal is that the chat plaintext is not available to that server path in normal operation. The useful privacy question Do not stop at retention. Ask whether the product has to receive your readable prompt to work. That distinction changes how I think about product design. A private chat app should not need accounts before you can try it. It should not create server-side history as a convenience. It should not make the easiest path the least private path. The default should be a clean, boring session: type, encrypt in the tab, receive an answer, and leave no server-side transcript behind. ## What other tools often mean by private Many tools use privacy to mean policy-level restraint: they will not train on a prompt, they will delete it eventually, or they will isolate it inside a vendor account. That can be a reasonable enterprise control, but it is not the same as avoiding plaintext on the service path. If a product needs plaintext on its backend, privacy depends on every backend system that can see or copy it. If history sync is server-backed, privacy depends on the storage path, access controls, backups, and deletion semantics. If AI search or tool use is bolted on without care, the search query can become a second copy of the sensitive prompt. I am not arguing that every product must make the same tradeoff. Collaboration, admin controls, and cross-device sync all have value. But users should be able to tell when they are choosing those tradeoffs. The private default should not be hidden behind an enterprise procurement checkbox. ## What garlic.ai tries to make obvious The product language stays narrow on purpose. We say the chat content is encrypted in the browser before it crosses the server boundary. We also say saved chats, when enabled, are saved only in this browser. Those are implementation claims, not vibes. There are still things the app can observe: route, timing, model choice, protocol headers, ciphertext sizes, and whether a request is in flight. Metadata is real. The privacy claim is not that the internet disappears. It is that the readable chat content is pushed out of the normal server path. The line I want to hold A private AI chat should be useful before it asks you to trust the company with a transcript. That is the product I want to use. No ceremony, no account wall, no server-side chat archive pretending to be a privacy feature. Just an AI chat where the most sensitive data is handled as if it is sensitive by default. --- # Saved on device is a product decision History is convenient. It is also one of the easiest ways to accidentally turn private chat into an account database. - Canonical: https://garlic.ai/blog/saved-on-device-is-a-product-decision - Markdown: https://garlic.ai/blog/saved-on-device-is-a-product-decision.md - Published: 2026-07-03 - Updated: 2026-07-03 - Author: Michael Ryaboy - Category: Product privacy - Reading time: 1 min read - Keywords: local chat history, private chatbot history, AI chat local storage, vanish chat The cleanest private chat history is the one that never becomes a server feature. garlic.ai has two modes for that reason. Saved chat keeps completed turns in this browser's storage. Vanish chat keeps the transcript in the tab and drops it when the tab closes. That sounds less magical than cross-device sync, but the constraint is the feature. If history does not leave the device, there is no server history table to search, subpoena, leak, migrate, or forget to delete. ## Privacy should be visible in the workflow The interface labels the current retention mode because retention is not a footnote. If a chat is saved, it says this device only. If vanish is on, it says nothing is kept once the tab closes. The user should not need to read a policy to understand the local behavior. Saved mode is useful for everyday work because the browser can keep recent threads. Vanish mode is useful when the safest history is no history. Switching modes acts on the whole current transcript so the label matches reality. This is not a claim that local storage is encrypted vault storage. It is a product boundary: garlic.ai is not building a server-side transcript system as the default path. If the user's device is compromised, the device is still the device. The point is to avoid making the company another holder of readable history. ## The product test A user should be able to reload the app and know exactly which chats can come back, and why. --- # Private search needs a smaller promise Search makes AI more useful, but it can also become a second place where sensitive intent leaks. - Canonical: https://garlic.ai/blog/private-search-needs-a-smaller-promise - Markdown: https://garlic.ai/blog/private-search-needs-a-smaller-promise.md - Published: 2026-07-03 - Updated: 2026-07-03 - Author: Michael Ryaboy - Category: Search - Reading time: 1 min read - Keywords: private AI search, encrypted web search, AI chat sources, privacy metadata Web search is one of the most useful tools an AI chat can have. It is also where privacy copy often gets too broad. A search query is intent. If the prompt is sensitive, the query derived from it can be sensitive too. garlic.ai treats search as an explicit per-message tool. It is on by default because current information matters, but it is visible and can be turned off before sending. The goal is not to pretend search has no metadata. The goal is to avoid making it invisible. ## Useful privacy copy should be narrow When a product says private search, I want to know what part is private. Is the AI prompt encrypted before the app server sees it? Is the web query proxied? Are search results stored? Are source URLs shown to the user? Each answer matters more than the adjective. Show when search is active instead of hiding it behind the model response. Show sources so users can inspect what outside context influenced the answer. Keep the privacy claim scoped to the implemented transport and storage boundary. The better promise is smaller: garlic.ai keeps chat plaintext out of the normal Sealie server path, keeps saved history on this device, and names the parts that are still metadata. Smaller promises are easier to test. They are also harder to abuse.