Privoo reference
Download Source Discord

Privoo Desktop: Privacy and security

From the Privoo reference. This article covers version 5.0.5.

Main article: Privoo Desktop. For anonymous publishing, see .mariana hosting.

This article documents every privacy and security protection in Privoo: what it does, where it acts in the request pipeline, and which setting controls it. All protections described here are included in the browser; none are on a paid tier.

The Privacy Shield

The shield icon in the toolbar is frequently misunderstood as a single feature with a single switch. It is not. The shield is a status display for the six independent protections listed beneath it, each of which has its own setting in Settings → Privacy and security.

Opening the shield on a page reports what occurred on that specific page: trackers and advertisements blocked, cookies blocked, and HTTPS upgrades performed. The counters reset on each main-frame navigation, so the figures describe the current page load rather than the session.

Behaviour when disabled

When a protection is switched off in Settings, it stops. The setting is consulted on every request rather than only at startup, so the change takes effect on the next request in both directions, without a restart.

Historical note

This was not always true. Before version 5.0.4, the ad-blocking engine read its setting only once, when the browser session was initialised. Disabling ad blocking mid-session therefore had no effect until the browser was restarted. The setting is now evaluated per request, and the release notes record the change.

Per-site exceptions

The shield panel contains a per-site switch, Ads blocked on this site. Turning it off adds that site to an exclusion list, which is checked on every request. This allows advertising on a chosen site, for example one the user wishes to support, without weakening the global configuration.

Privoo also maintains an internal compatibility list for sites, such as certain educational platforms, where aggressive filtering is known to break required functionality. Requests originating from those hosts bypass the blocking engine. Additionally, if a recognised third-party content blocker is installed, Privoo steps aside entirely on YouTube, because two blockers competing over the same requests can leave the player in a broken state.

Content blocking

Network-layer enforcement

Blocking is performed in the request pipeline by Ghostery's adblocker-electron engine. The distinction from cosmetic blocking matters: a blocked request is cancelled before it is issued. The resource is never fetched, so it transfers no bytes, executes no JavaScript, sets no cookies, and never observes the user's IP address. Hiding an advertisement with CSS after it has loaded achieves none of those.

This is also the mechanism behind the performance claim. A blocked advertisement is not merely invisible; it is work the browser never performed.

Filter lists are compiled into an engine at launch and cached on disk. The cache is invalidated after seven days so that rules, notably the anti-adblock countermeasures that change frequently, stay current. If the list fetch fails, for example on a network that is not yet connected at startup, Privoo retries and meanwhile falls back to a small built-in host blocklist rather than leaving the user unprotected.

Filter lists

Built-in filter lists
ListPurpose
EasyListThe primary advertising filter list.
EasyPrivacyTracking and analytics scripts.
uBlock Origin listsAdditional rules, including anti-adblock countermeasures.
Cryptojacking listKnown in-browser cryptocurrency mining scripts.

Any built-in list may be disabled, and arbitrary list URLs may be added, in Settings → Privacy and security → Filter lists. Because lists are compiled at launch, changes to the list selection apply after a restart.

HTTPS upgrading

Plaintext HTTP can be read and modified in transit by any intermediary, including the network operator. When a navigation targets an http:// URL, Privoo cancels it and reissues it over HTTPS.

If a site has no HTTPS version at all, Privoo presents an interstitial rather than silently returning the user to plaintext, so continuing is an explicit choice. A brief notice shown during the upgrade can be disabled separately for users who find it intrusive. Localhost and hosts the user has explicitly bypassed are exempt.

Cookie policy

A third-party cookie is one belonging to a domain other than the site being visited, and is the classic mechanism for correlating a user's activity across sites. Privoo strips them bidirectionally: the Cookie request header on outgoing cross-site subresource requests, and the Set-Cookie response header on the way back.

First-party cookies are untouched, which is why sessions on sites the user actually visits are preserved. A main-frame document request is first-party by definition and is never stripped.

Historical note

An earlier implementation compared a main-frame request against the previous page's origin, because during navigation the browser still reports the old URL. Top-level loads were therefore misclassified as cross-site and had their cookies removed, causing some services to sign users out on restart. Main-frame requests are now excluded from the check.

Encrypted DNS

Every navigation begins with a DNS lookup translating a hostname into an address. By default such lookups are sent in plaintext to whichever resolver the network provides, typically the ISP's, producing a complete and readable record of every site visited.

Privoo issues these lookups over DNS-over-HTTPS. It operates in strict mode, meaning that if the encrypted resolver is unreachable, resolution fails rather than falling back to plaintext. This is a deliberate and consequential choice: a DoH implementation that silently falls back leaks precisely when the network is most likely to be hostile.

Supported DoH providers
ProviderNotes
CloudflareDefault.
AdGuardFiltering variants available.
Quad9Malware-blocking resolver.
NextDNSConfigurable account-based resolver.
GooglePublic resolver.
CustomAny DoH endpoint, typically ending in /dns-query.

Fingerprint resistance

Blocking cookies alone is insufficient, because a site can identify a returning visitor from the combination of characteristics the browser exposes: fonts, screen geometry, graphics hardware behaviour, and so on. This technique requires no client-side storage, so clearing cookies does not affect it.

Canvas noise

A site can draw graphics to an off-screen canvas and read back the pixels; minute differences between graphics stacks yield a stable identifier. Privoo perturbs these reads.

The noise is deterministic per origin: a given site observes a consistent value across visits, while different sites observe different values. This is a considered design decision. Noise randomised on every read would defeat correlation within a site but would itself be conspicuous, since being the only visitor whose fingerprint changes on every read is a fingerprint.

User-Agent normalisation

Privoo reports a common Chrome identity rather than announcing itself as a niche browser, and keeps the User-Agent string, Client Hints headers and navigator.userAgentData mutually consistent. An inconsistency between those is itself detectable.

The reasoning is that a rare browser is trivially identifiable, so the larger crowd is the safer place to stand. A practical side effect is compatibility with sites that refuse to serve user agents they do not recognise.

WebRTC

WebRTC can disclose a device's real IP address even when a VPN or proxy is in use, which defeats the purpose of the proxy. Privoo restricts the WebRTC IP-handling policy to the public interface. An exception exists for Google properties, whose bot detection treats the restricted policy as suspicious and responds with persistent CAPTCHAs.

Stronger tracking protection

An optional layer that acts on requests which are not themselves blocked:

Cryptojacking protection

Some pages embed scripts that use the visitor's processor to mine cryptocurrency, typically manifesting as a hot, loud and slow machine. Privoo applies a dedicated blocklist of known mining scripts, enabled by default.

Tor, proxies and alternative naming

Traffic may be routed through a manual proxy, specified as a socks5:// or http:// URL, or through a bundled Tor circuit, configured in Settings → Privacy and security → Proxy. The Tor SOCKS port defaults to 127.0.0.1:9100.

Independently of that setting, .onion addresses are always routed over Tor by means of a proxy auto-configuration rule that matches only that suffix. The Tor process is started on demand at the first .onion navigation. The remainder of the user's browsing is not rerouted, so opening a single hidden-service link does not silently move all traffic onto Tor.

Alternative naming and transports
SchemeHandling
.onionRouted over the bundled Tor SOCKS proxy.
.ethENS name resolved via a public gateway.
.crypto, .wallet, .nft, othersUnstoppable Domains, via the same gateway.
ipfs://, ipns://Redirected to an IPFS gateway.
mariana://Privoo's own anonymous hosting. See .mariana hosting.
Gateways are third parties

ENS and IPFS resolution occur through public gateways. Those gateways observe the request. This is a pragmatic trade-off for convenience, and it is weaker than running a resolver or IPFS node locally.

Family filtering

Optional adult-content blocking is enforced at two layers simultaneously: DNS is routed through a family-safe resolver (Cloudflare or AdGuard family filters), and navigation is checked against a classified domain list containing approximately 76,000 entries. Enforcement occurs in the request pipeline rather than only at navigation, which covers script-driven redirects, popups and the initial load of a newly created tab. It requires encrypted DNS to be enabled.

Profiles and data isolation

Profiles are separate browsing identities. Isolation is achieved by redirecting Chromium's entire userData directory at process start, which separates cookies, cache, local storage, history, logins and settings at the filesystem level rather than by convention.

Guest mode provides a session that retains nothing. Incognito windows use a private session that is discarded on close and is never written to history. Incognito windows also close fully rather than minimising to the tray, so a private session does not persist in memory after the window is closed.

Clear data on exit erases selected categories on every quit. Delete all data removes everything Privoo has stored, returning the browser to a fresh state. Neither has a remote counterpart, because no remote copy exists.

Password storage

The built-in vault stores credentials encrypted on the local device. There is no cloud vault, no master account and no synchronisation.

The trade-off is worth stating in both directions: credentials cannot be exposed by a breach of a server that does not exist, and equally they will not appear on the user's other devices, because nothing transports them there.

Threat model

Privoo's documentation is explicit about what the browser does and does not address. Its protections are aimed at the commercial tracking industry: advertising networks, analytics providers, cross-site correlation and fingerprinting. Against that adversary the defaults are strong and enabled from first launch.

No browser makes a user anonymous. Privoo's own documentation states that a user whose adversary is a determined state actor should use Tor Browser, and notes that Privoo will route .onion traffic in the meantime.[1] Incognito mode prevents local retention only; it does not conceal the user from the sites visited or from the network.

See also

References

  1. Privoo Browser README. Project repository. Retrieved 16 July 2026.
  2. settings-store.js and main.js, request pipeline. Project repository, version 5.0.5.