Privoo Desktop: Privoo AI

From the Privoo reference. This article covers version 5.0.5.

Main article: Privoo Desktop. For the separate AI coding IDE, see Privoo Coder.

Privoo AI is the assistant built into Privoo Desktop. It is enabled by default and reachable from a toolbar button, a side panel, or its own window at privoo://ai. It is not a hosted service: Privoo operates no model and no inference infrastructure. The assistant runs against an API key the user supplies, or entirely locally through Ollama, in which case no data leaves the machine at all.

This design follows from the same constraint as the rest of the browser. A browser with no accounts and no servers cannot offer a hosted assistant without contradicting itself, so it offers the plumbing and lets the user choose who, if anyone, sees their conversations.

Interface

Privoo AI is presented in three places, backed by the same conversation store:

Chat history

Conversations are saved and listed as Recent chats in a sidebar, which can be shown or hidden. History is stored in the browser's own local storage under the key privoo-ai-chats-v1, and is shared between the AI window and the full-page view, so a conversation started in one is available in the other.

As with everything else in Privoo Desktop, that store is on the local disk. There is no account holding conversations and no synchronisation between devices.

Providers and models

Five backends are supported. Four are hosted services requiring the user's own API key; one runs locally and requires none.

Anthropic is the default provider. The model is configurable per provider rather than fixed to the defaults above. Privoo maintains a small mapping of retired model identifiers to their replacements, so a model name saved in settings that a provider has since withdrawn is silently migrated instead of failing.

If a hosted provider is selected but no key has been saved for it, the assistant reports that the key is missing rather than failing opaquely. Ollama is always treated as available, because there is no key to check.

API keys and storage

Keys are entered in the assistant's configuration and stored encrypted, using the same approach as the browser's password vault:

• Primary: the operating system's keychain, via Electron's safeStorage. On Windows this is DPAPI, on macOS the Keychain, on Linux the platform's secret service.
• Fallback: where the OS keychain is unavailable, AES-256-GCM using a key derived for the machine.

A key is transmitted only to the provider it belongs to, on requests the user initiates. Keys are never sent to Privoo, because there is no Privoo endpoint to send them to.

Running locally with Ollama

Ollama runs a language model on the user's own machine. Selecting it as the provider means the assistant works with no API key, no account, no per-token cost, and no network transmission of the conversation.

Privoo detects a running Ollama instance and the models installed in it. The default is llama3.2, and any model pulled locally can be selected.

Ollama is used elsewhere in the browser for the same reason. The identity autofill feature calls a local model to interpret unusual form-field labels that direct matching does not recognise, so that the user's saved personal details are never sent to a remote service to be understood.

Network path

Requests to Ollama go directly to 127.0.0.1:11434 using Node's own HTTP client, deliberately bypassing Electron's networking stack. This is a considered decision rather than an oversight, and it has a visible consequence:

How requests are made

Hosted providers are called at their standard public endpoints, with the user's key, from the main process:

Each conversation is sent with a system prompt, which defaults to a short instruction identifying the assistant as running inside the Privoo web browser and asking it to be concise and accurate. Responses can be streamed, so output appears as it is produced rather than after the full reply is complete.

Privacy model

The position is narrower and more honest than "private AI", a phrase this reference avoids because it is usually meaningless:

• Privoo sees nothing. There is no proxy, no relay and no server operated by the project. Conversations are not routed through Privoo infrastructure, because none exists.
• With Ollama, nothing leaves the machine. This is the only configuration in which the conversation is genuinely private in the strong sense.
• With a hosted provider, that provider sees the conversation. This is inherent to using a hosted model and is not altered by the browser around it. What the provider may do with the data is governed by the user's agreement with them.
• Keys stay local, encrypted at rest through the OS keychain.
• History stays local, in the browser's own storage, with no synchronisation.

Relationship to Privoo Coder

Privoo AI and Privoo Coder are distinct products that share a design principle. Both decline to host a model and both operate against a user-supplied key or a local Ollama instance, keeping keys on the machine.

Limitations

• The hosted options need an account elsewhere. Privoo supplies no key and no free tier. Without a provider account, Ollama is the only option.
• Ollama needs local resources. Running a model on the user's own hardware is bounded by that hardware.
• Replies are bounded in length by a response token limit.
• The assistant is not the browser's privacy layer. Sending a page's contents to a hosted model discloses them to that provider, whatever the shield reports about the page itself.
• No synchronisation. Chat history stays on the device that produced it.

See also

• Privoo Desktop: Built-in tools
• Privoo Coder
• Privoo Desktop: Privacy and security
• Privoo Desktop: Built-in tools overview

References

1. ai.js, provider configuration, key encryption and request handling. Project repository, version 5.0.5.
2. renderer/internal/ai.html, assistant interface and chat history store. Project repository, version 5.0.5.