Privoo Desktop: .mariana hosting

From the Privoo reference. Introduced in version 5.0.5, 15 July 2026.

Main article: Privoo Desktop. See also Privacy and security: Tor.

.mariana is a feature of Privoo 5.0.5 that publishes a directory from the user's own computer as a website reachable over the Tor network. It requires no server, no domain registration, and no port forwarding. The browser acts as the host. Between two Privoo instances, an additional post-quantum encryption layer is negotiated on top of Tor's own encryption.

Technical basis

A .mariana site is a Tor version 3 hidden service. This is established technology, the same mechanism underlying .onion sites and tools such as OnionShare. Privoo's contribution is not a new protocol but the removal of the setup: the user does not install Tor, edit a torrc file, or run a web server.

Publishing performs three actions:

1. Privoo starts an HTTP server bound to 127.0.0.1 on an ephemeral port, serving the chosen directory. It is not reachable from the network directly.
2. Privoo connects to Tor's control port and issues an ADD_ONION command, creating a hidden service whose virtual port 80 maps to that loopback server. Authentication to the control port uses Tor's cookie file.
3. Tor returns a service identifier, and Privoo composes a share link from it.

The user's computer is therefore the host, and Tor provides both reachability and anonymity for the operator and the visitor. The site is available only while Privoo is running. The project describes this plainly as ad-hoc personal publishing rather than a substitute for a hosting provider.

Publishing a site

From privoo://mariana, reachable from the system tray menu:

1. Enter a name, for example myblog.
2. Choose a directory, or drag one onto the page. It should contain an index.html.
3. Select Publish.

The site is served with the following behaviour:

Address format

The share link takes the form:

mariana://myblog.<56-character-onion-address>/

The 56-character component is the Tor service address, which is a base32 encoding derived from the service's Ed25519 public key. It is therefore self-authenticating: the address is the key, so a third party cannot impersonate the site without possessing the corresponding private key. There is no registry, no lookup service and no authority able to revoke a name.

The leading label is a human-readable convenience only and carries no authority. On first visit Privoo records the mapping locally, after which the short form myblog.mariana resolves. A short name that the browser has not previously seen produces an explanatory page rather than a guess.

Address persistence

Privoo stores the hidden service's private key together with the site record, so restarting the browser restores the same address and previously distributed links continue to work. Sites marked active are republished automatically at launch, after a delay allowing Tor to bootstrap. On quit, Privoo issues DEL_ONION for each service so that no orphaned descriptors are left published on the network.

The post-quantum layer

Rationale

Tor already encrypts traffic end to end. The additional layer addresses one specific and credible threat, usually termed harvest now, decrypt later: an adversary able to record encrypted traffic today may store it indefinitely and decrypt it once a cryptographically relevant quantum computer exists. Conventional key exchange is vulnerable to that machine; post-quantum algorithms such as ML-KEM are designed to resist it.

The layer therefore protects against future decryption of traffic captured today. It provides no benefit against an adversary who can already read the plaintext by other means.

Handshake

ML-KEM-768 is the NIST-standardised form of the Kyber key encapsulation mechanism. Privoo's exchange proceeds as follows:

1. Each published site generates an ML-KEM-768 key pair, stored with the site record.
2. The visitor's browser requests the site's public key over Tor. Because a Tor v3 address authenticates the service, the key cannot be substituted in transit.
3. The visitor performs encapsulation against that public key, producing a ciphertext and a 32-byte shared secret. The secret itself is never transmitted.
4. The visitor sends the ciphertext with its request. The host decapsulates it using its private key, recovering the identical shared secret.
5. Both sides derive an AES-256-GCM key from the shared secret using HKDF-SHA256, bound to a fixed context string.
6. The response body is encrypted with that key inside the Tor connection. A fresh secret is negotiated per page load.
7. If the ciphertext fails authentication, indicating alteration in transit, Privoo declines to render the page rather than displaying tampered content.

Scope and limitations

The project documents the boundaries of this feature explicitly rather than marketing around them:

• It applies between Privoo instances only. Both ends must implement the handshake. A visitor using a conventional Tor browser receives the site over Tor alone, with no additional layer. The mechanism is opportunistic, so nothing breaks; the visitor simply does not receive the extra protection.
• It protects the transport, not the content. It does not anonymise authorship, conceal what was published, or help if identifying information appears on the page itself.
• It is not described as unbreakable. The project's own documentation declines that claim and notes that a security tool asserting unbreakability should be treated with suspicion.
• It is additive, not a replacement. Tor's own encryption remains the primary protection; this is a second layer over it.

Managing sites

Site records, including the onion private key and the ML-KEM secret key, are stored in the Privoo configuration directory. They are the material that allows an address to persist, and should be treated with the same care as the password store. See Installation: data storage.

Visiting a site

Paste a share link into the address bar. Privoo starts Tor if required, retrieves the site through it, performs the post-quantum handshake where offered, and renders the result. Retrieval uses a dedicated session whose proxy is set to the Tor SOCKS port, so hostname resolution occurs at the Tor exit rather than locally.

The mariana:// scheme is registered as a standard, secure scheme, so pages receive an ordinary origin and relative URLs, fetch() and similar APIs behave normally.

Comparison with alternatives

Intended use

Anonymous publishing has well-established legitimate purposes: journalism, dissent in repressive environments, whistleblowing, and simply publishing without surrendering one's identity to a hosting company. Those purposes are the reason the underlying technology exists and continues to be maintained.

See also

• Privoo Desktop: Tor, proxies and alternative naming
• Privoo Desktop: Anonymous hosting
• Privoo Desktop: FAQ and troubleshooting

References

1. mariana.js, hosting engine and cryptography. Project repository, version 5.0.5.
2. FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard. NIST.
3. Tor control protocol specification, ADD_ONION and DEL_ONION commands. The Tor Project.