Security architecture

Overview

CrowdMe is built around a simple principle: every browsing session runs inside a newly created virtual machine that is destroyed when the session ends.

Unlike a traditional browser, VPS or VPN account, no user ever reuses a previous browsing environment. Every session starts from the same clean template, making all users technically similar from the browser's perspective.

The infrastructure is intentionally simple. Each CrowdMe server is a complete, independent installation capable of serving users without relying on central infrastructure.

Server model

CrowdMe currently runs on one physical server using Proxmox VE. The design can be expanded by adding more independent Proxmox servers.

Each server contains the complete stack: Proxmox, pfSense, the CrowdMe application, Tor gateway VM, and disposable browser VM templates.

Users can be distributed between servers using round-robin distribution. There is no central session service. All servers can run independently.

The only information synchronized between servers is token state: token hash, remaining session count and update timestamp. No browsing sessions, browser state, IP addresses or user activity are synchronized.

Network segmentation

The physical server has one connected network interface. That interface is bridged to a pfSense virtual machine. pfSense is the firewall and router for the internal VLANs.

The CrowdMe application, disposable browser VMs and Tor gateway VM run on separate VLANs. No traffic can pass between these networks unless pfSense has an explicit rule allowing it.

The default security model is deny by default, allow only what is required.

Public access and noVNC tunnel

Public HTTPS traffic first reaches an Nginx reverse proxy running on a separate network segment. Nginx terminates the public web connection and forwards allowed requests to the CrowdMe application.

Disposable browser VMs are not exposed directly to the Internet. When a user opens a session, the noVNC connection is tunneled through the CrowdMe application to the assigned VM.

This means users connect to CrowdMe.One, not directly to internal VM addresses. VM network details remain internal to the server.

Browser VM isolation

Every user receives a newly cloned virtual machine. The VM starts from an unchanged template, runs for the lifetime of the session, and is destroyed afterwards.

No disposable browser VM is reused for another user. The template itself is not exposed to users.

Because every VM begins from the same image, browser fingerprint differences between users are minimized. Cookies, local storage, browser cache and any malware that only lives inside the VM disappear when the VM is deleted.

Isolation between user VMs

Disposable browser VMs share one VLAN, but they are not allowed to communicate with each other.

Proxmox firewall rules block VM-to-VM traffic on the browser VLAN. The relevant rule is an outbound drop rule with destination 10.10.80.0/24. This prevents one browser VM from reaching another browser VM on the same subnet.

On pfSense, the browser VLAN only allows the minimum required traffic: time synchronization to pfSense and access to the Tor SOCKS proxy. Other traffic is blocked.

Internet access

Browser VMs have no direct Internet access. The only permitted route to the Internet is through the Tor SOCKS proxy running on a separate VLAN.

The intended path is:

Browser VM → Tor SOCKS proxy → Tor network → Internet

Browser VMs cannot bypass the Tor proxy under normal firewall rules. The Tor gateway is separated from the browser VM network and cannot freely reach back into the browser VLAN.

User inspectability

Unlike many hosted privacy services, CrowdMe gives the user access to a complete Ubuntu desktop, not only to a hidden browser process. A technical user can minimize the browser and inspect the running VM from inside the session.

This means users can inspect things such as the Ubuntu version, Firefox version, installed software, running processes, network connections, routing table, DNS configuration, Firefox profile, systemd services, startup scripts, certificates, and local system logs inside the VM.

This provides practical transparency. It lets users verify that the disposable VM itself looks like a normal Ubuntu environment, that the browser configuration matches the documented design, and that networking behaves as expected from inside the VM.

However, this inspection has clear limits. Users cannot inspect Proxmox, pfSense, the CrowdMe application, the Tor gateway VM, other users' VMs, the VM template, the token database, or the physical host. Those components are outside the disposable VM and remain part of the trust boundary.

VM inspection is therefore useful, but it is not proof. It can show what the running disposable VM contains, but it cannot prove that the underlying infrastructure cannot observe or modify the session.

Administrative access and trust

Administrative access is intentionally limited. Currently, only the owner, Jan Jonsson, has access to the Proxmox server, pfSense and the CrowdMe infrastructure.

No other people have passwords, SSH keys or administrative access.

This means users must trust the operator. This is true for every hosted privacy service. A system operator with full control of the physical infrastructure can always change the system, inspect running machines or deploy modified software.

If you do not trust the operator, you should not use the service.

Logging and session retention

CrowdMe is designed to minimize the amount of information that can exist. The most important design decision is that browser VMs are temporary.

When a session ends, the VM is powered off, deleted and removed from the pool. Its virtual disk is deleted with it. Nothing from the browsing environment is meant to remain after normal cleanup.

In this architecture, meaningful logging of browser activity would require active intervention. An administrator could technically open the Proxmox console during a live session, modify the VM template, add monitoring software, copy a VM disk before deletion, or change the application so that VMs are preserved instead of destroyed.

CrowdMe does not claim that such actions are technically impossible for the infrastructure owner. The claim is narrower: under normal documented operation, sessions are short-lived, VMs are destroyed, and retaining browsing sessions would require deliberate changes to the system.

Strengths

• Every session starts from the same clean VM template.
• No browser VM is reused between users.
• Browser state disappears when the VM is destroyed.
• Browser VMs cannot communicate with each other.
• Internet access is forced through a separate Tor gateway.
• Internal services are separated by VLANs and pfSense rules.
• Servers can operate independently without central session state.
• Only token hash and remaining session count are synchronized.

Limitations

• The operator must be trusted not to inspect or modify live sessions.
• A compromised administrator account would be serious.
• A malicious template would compromise future sessions.
• One physical server is still a single point of failure until more servers are added.
• Tor provides network privacy but does not make unsafe browser behavior safe.
• Websites may still identify users through logins, behavior or information typed into pages.

Design philosophy

CrowdMe does not attempt to prove that the operator cannot observe users. Instead, the architecture minimizes what exists to observe and makes retention of browsing sessions something that would require deliberate changes to the documented system rather than happening as part of normal operation.