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.
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
| List | Purpose |
|---|---|
| EasyList | The primary advertising filter list. |
| EasyPrivacy | Tracking and analytics scripts. |
| uBlock Origin lists | Additional rules, including anti-adblock countermeasures. |
| Cryptojacking list | Known 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.
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.
| Provider | Notes |
|---|---|
| Cloudflare | Default. |
| AdGuard | Filtering variants available. |
| Quad9 | Malware-blocking resolver. |
| NextDNS | Configurable account-based resolver. |
| Public resolver. | |
| Custom | Any 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:
- Tracking parameter stripping. Identifiers appended to URLs are removed before the request is issued, and the page is loaded at the cleaned URL. Affected parameters include
utm_*,fbclid,gclid,gbraid,wbraid,msclkid,twclid,igshid,yclid,dclid,mc_eidand others. - Referer minimisation. On cross-origin requests the
Refererheader is reduced to the origin, so the destination learns the referring domain but not the exact page. - Global Privacy Control. The
Sec-GPCheader is sent, which in some jurisdictions constitutes a legally binding instruction not to sell or share personal data.
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.
| Scheme | Handling |
|---|---|
.onion | Routed over the bundled Tor SOCKS proxy. |
.eth | ENS name resolved via a public gateway. |
.crypto, .wallet, .nft, others | Unstoppable Domains, via the same gateway. |
ipfs://, ipns:// | Redirected to an IPFS gateway. |
mariana:// | Privoo's own anonymous hosting. See .mariana hosting. |
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
- Privoo Desktop: .mariana hosting
- Privoo Desktop: Built-in tools
- Privoo Desktop: FAQ and troubleshooting
- Privoo Desktop: Privacy model
References
- Privoo Browser README. Project repository. Retrieved 16 July 2026.
settings-store.jsandmain.js, request pipeline. Project repository, version 5.0.5.