--- id: "privacy-architecture" date: "2026-02-04" title: "Privacy in Daneel: how your data stays yours across every feature" summary: "From on-device inference to encrypted API keys, from MCP credential isolation to opt-in analytics — a complete look at how Daneel protects your data at every layer." image: "/medias/privacy.png" header: "How It Works" tags: ["privacy", "security", "how-it-works", "analytics"] --- ## Privacy isn't a feature. It's the architecture. Daneel is built on a simple premise: your browsing, your documents, and your conversations belong to you. That sounds obvious, but making it real across five AI backends, dozens of MCP integrations, document vaults, and analytics requires deliberate engineering at every layer. This article explains exactly how privacy works in Daneel. Not marketing claims. The actual mechanisms. ## The privacy gradient Not all AI inference is equal when it comes to data residency. Daneel defines four levels, and every model in the registry carries an explicit label so you always know where your data goes. **On-device** is the most private tier. WebGPU models and Gemini Nano run entirely inside your browser. Your prompts never leave the JavaScript process. No network calls, no external observers. The model weights are open-source and auditable. This is the default. **Local network** is the next step. Ollama models run on a server you control, typically localhost. Prompts leave the browser process but stay on your machine or your local network. You control the infrastructure, you audit the logs. **Your cloud** covers Azure OpenAI deployments. Data leaves your machine but lands in your organization's Azure subscription. Your tenant admin controls access, Azure RBAC governs permissions, and your organization's data governance policies apply. The model weights are proprietary, but the infrastructure is yours. **Third-party cloud** is the least private tier. Claude sends prompts to Anthropic's servers. You rely on their privacy policy and terms of service. The trade-off is access to frontier-class reasoning that no local model can match today. Every model in the registry exposes three boolean flags alongside its residency level: whether data leaves the browser process, whether it leaves your machine, and whether it leaves your control. The model browser in Settings shows these visually, and the recommendation engine can filter by privacy floor. An enterprise user can restrict results to "Your cloud or better" and never see third-party options. ## Encrypted credentials API keys for Claude and Azure are encrypted with AES-256-GCM before they touch storage. The encryption key is derived from the extension's unique ID combined with a provider-specific salt, hashed through SHA-256. A fresh 12-byte initialization vector is generated for each encryption operation, prepended to the ciphertext, and the whole blob is base64-encoded before writing to Chrome's local storage. Decryption only happens in the background service worker when a request needs the key. The plaintext lives in memory for the duration of the API call, then is discarded. Keys are re-derived on each use rather than cached. This follows the browser extension threat model: the extension context is trusted, but web pages are not. If Chrome's storage is compromised at the OS level, AES-256-GCM still protects the contents. And critically, encrypted keys are excluded from data exports, so they never end up in a backup ZIP. ## MCP credential isolation Each MCP server's credentials (OAuth tokens, API keys, bearer tokens) are stored under a separate key in Chrome storage, namespaced by the server's canonical URL. There's no shared credential pool. Revoking access to one server has zero impact on others. OAuth2 tokens include expiry tracking with a 60-second safety margin. When a token is close to expiring, the transport layer refreshes it transparently. If the refresh fails, the server is flagged as needing re-authorization rather than silently failing. MCP credentials are permanently excluded from data exports. Both the exact keys and the prefix-matched patterns are stripped during the export assembly. After importing a backup on a new machine, you re-authorize each MCP server individually. This is intentional: portable credentials are a security liability. ## What gets exported, and what doesn't The data export system applies strict exclusion rules: **Never exported:** Claude API key, Azure API key, all MCP credentials, OAuth client registrations, telemetry client ID, cloud backup credentials (Azure SAS URL, S3 config), and registry caches. **Always exported:** Settings, conversations, vault metadata, document embeddings (as efficient binary), MCP server registrations (URLs, not credentials), and agent definitions. The exclusion list covers both exact key matches and prefix patterns, so dynamically-created credential keys (one per MCP server) are caught automatically. The export manifest documents what's included, giving you full transparency on the contents of every backup. ## Origin header management Chrome's service worker automatically attaches an `Origin: chrome-extension://...` header to every outbound request. Some MCP servers reject this with a 403, treating it as an unexpected origin. Daneel solves this with declarativeNetRequest rules that dynamically strip the Origin header for registered MCP server domains. Rules are regenerated whenever the server list changes, scoped to specific hostnames, and use a reserved ID range (100,000+) to avoid conflicts with other extensions. This prevents origin leakage while keeping MCP communication functional. ## Analytics: what we collect and what we don't Daneel uses Google Analytics 4 via the Measurement Protocol. This means no gtag.js script is loaded, no tracking pixels are injected, and no cookies are set on web pages. Analytics are plain HTTP POST requests sent from the background service worker to GA4's collection endpoint. **What we collect:** Feature usage counters. When you start a chat, run a search, import a document, or switch providers, an event fires with the action name, the provider used, and aggregate counts (number of results, number of chunks). We also collect device metadata: OS, browser version, screen size, language, and timezone. Geolocation is derived from your browser's IANA timezone by default. A hardcoded lookup table maps "Europe/Paris" to France, "America/New_York" to the US, and so on. No network call, no IP lookup, no external service. **What we never collect:** Your prompts. Your AI responses. The content of your pages or documents. The URLs you visit. Your search queries. Your API keys. Any personally identifiable information. These exclusions are enforced in code: the telemetry service filters out non-primitive values to prevent accidental leakage of complex objects. **Opt-out:** Open Settings, go to Privacy, and toggle telemetry off. That's it. The gate is checked before every event. When telemetry is off, nothing is sent. No degraded experience, no nag banners, no "are you sure" prompts. **Enhanced geolocation (opt-in):** If you want more accurate location data in analytics (useful for us to understand regional usage), you can enable IP-based geolocation. This makes a single request per session to ip-api.com, returning your approximate country, region, and city. It's off by default and clearly labeled in the Privacy settings. The timezone-derived fallback works fine for most purposes. ## Content Security Policy The extension runs under a strict CSP: only scripts from the extension itself are allowed (`script-src 'self'`), with `wasm-unsafe-eval` permitted for ONNX Runtime's WebAssembly needs. No remote scripts, no inline scripts, no eval. The Cross-Origin Embedder Policy uses `credentialless` mode, which enables SharedArrayBuffer for multi-threaded inference without sending credentials on cross-origin model downloads. ## The design principle Every privacy decision in Daneel follows one rule: the user should be able to understand where their data goes by looking at a single label. On-device means on-device. Local network means local network. Third-party cloud means third-party cloud. We don't hide privacy trade-offs behind marketing language. If you choose Claude for its capability, the Settings panel tells you plainly that your data reaches Anthropic's servers. If you stay on WebGPU, nothing leaves your browser. The gradient exists because real users have real needs that span from maximum privacy to maximum capability. Your data, your choice. That's the whole idea. --- [Read on site](https://daneel.injen.io/news/privacy-architecture.html?utm_source=extension_news_reader&utm_medium=extension_settings&utm_campaign=extension)