Getting started

1. Download the installer from the download page. It is roughly the size of a bundled Java runtime, because it carries one - you do not need Java installed.
2. Verify the checksum before you run it. The digest is on the download page; this is the command that produces it from the file you have.

Get-FileHash -Algorithm SHA256 .\Ward-Setup-1.1.1.exe

3. Run it. Windows will show a SmartScreen warning, because the build is not code-signed. The download page explains exactly what that means and what to check before clicking through it.
4. Open Ward. On first run it creates its database and its profiles directory, then asks you to sign in or make an account. There is no licence key and no activation step.

Choose New profile. A profile is three decisions and a name.

1. Name it, and file it. Give it a folder, any tags you want to filter by later, and a note. The note is the field people skip and then wish they had used: six months on, “which of these two is the one with the verified phone number” is not a question the profile list can answer for you.
2. Pick a browser. The list offers Camoufox, Ungoogled Chromium, Brave and Chromium. Ward detects what is installed from the standard Windows locations and the registry, downloads a portable build of Camoufox, Ungoogled Chromium or Brave on request against a pinned checksum, and lets you point at a binary by hand. Chromium is the one it will not fetch: the project publishes continuous snapshots with no checksum beside them, so there is nothing to verify an archive against, and Ward would rather find one you installed yourself. Google Chrome and Microsoft Edge are behind a toggle that is off by default - see below for the actual reason, which is not the one you are probably expecting.
3. Pick a device class. Ward generates a full identity to match it - user agent, platform, screen metrics, device pixel ratio, hardware concurrency, device memory, locale, languages, and WebGL vendor and renderer strings. These are generated together, as a set, so that they agree with each other.

The generated values are stored with the profile and reused on every launch. That stability is the point. A profile whose screen resolution changes between sessions is a far louder signal than any particular resolution ever was.

Why Chrome and Edge are not in the default list

Not because they leak your device. They do not: Ward applies each profile’s identity from outside the page, over the DevTools Protocol, and a site sees the same user agent, the same screen and the same timezone from Google Chrome as it does from Ungoogled Chromium. Swapping the engine changes nothing a page can read.

What it changes is what the installation reports about itself, on a schedule you did not ask for. Chrome fetches Safe Browsing lists and a field-trial seed, runs a component updater, and installs a separate machine-wide update service that reports the install and its machine identifier whether or not a browser is open. Edge adds its own diagnostic pipeline, SmartScreen URL lookups and a configuration-service fetch. Ward passes flags that quiet the part of that living inside the browser process, on every launch, for every build. The updater service is a different process and never sees a command line.

That traffic is keyed to the machine and the install, not to a profile - it is identical whether you run one profile or forty, which is exactly why it is the piece worth removing at the source rather than configuring away. It is a real reason to prefer a build that was never wired to those services, and it is a different reason from “Chrome leaks my fingerprint”. Ward will not make the second claim, because Ward cannot keep it.

Camoufox leads the list on a stronger argument than either: its anti-fingerprinting values are patched into the engine’s C++ rather than redefined by a script in the page, so there is no property descriptor for a site to inspect. Everything Ward applies over the DevTools Protocol leaves one. That is the ceiling of this approach and it is stated on the fingerprinting page.

Open the profile and add a proxy. Paste the string your provider gave you into the one box and press Check. Ward reads the shape rather than asking you to take it apart, because every provider writes the same five facts differently and a four-box form is how a username ends up in the password field.

All of these are one proxy, and all of them parse to the same thing:

socks5://198.51.100.7:1080:wardops7:Zx9-qw3rty
socks5://wardops7:Zx9-qw3rty@198.51.100.7:1080
socks5h://wardops7:Zx9-qw3rty@198.51.100.7:1080
198.51.100.7:1080:wardops7:Zx9-qw3rty
wardops7:Zx9-qw3rty@198.51.100.7:1080
wardops7:Zx9-qw3rty:198.51.100.7:1080
198.51.100.7,1080,wardops7,Zx9-qw3rty
198.51.100.7 1080 wardops7 Zx9-qw3rty

Commas, semicolons, spaces, tabs and newlines all separate. Surrounding quotes and a leading Proxy: label are removed. The inverted user:pass:host:port order is recovered by working out which token can be a host and which can be a port, not by preference - and when both readings are possible, Ward takes the common one and tells you which it took instead of choosing in silence. A string it cannot read is refused by name, with the part it could not identify; it never half-fills the fields.

Ward reads and dials HTTP, HTTPS, SOCKS4, SOCKS4a and SOCKS5; socks5h is a spelling of the last of those rather than a sixth protocol. One caveat, and it is real: SOCKS4 and SOCKS4a have no password field at all - the protocol carries a plain userid and nothing else - so a password on one of them is refused rather than dropped on the wire.

Names are never resolved on your machine. On SOCKS5 the destination hostname travels to the proxy unresolved, which is what socks5h means and what Ward always does; on SOCKS4 it goes in the 4a form. Where a proxy will not accept a name, the connection is refused rather than resolved locally, because a DNS query for every site a profile visits leaving your own resolver is worse than a page that does not load.

What happens underneath is worth understanding, because it is the part every other approach gets wrong. Chrome has no way to supply a username and password to a SOCKS5 proxy - it is a long-standing Chromium limitation, not a setting anyone has missed. The common workaround is a proxy extension that answers the authentication challenge, and that trade is a bad one: an installed extension is itself a distinguishing signal, its presence is detectable from a page, and its traffic is observable.

So Ward does not put anything in the browser. For each profile you launch, it:

1. starts a small forwarding proxy bound to 127.0.0.1 on an ephemeral port, reachable only from your own machine;
2. points the browser at that local port, which needs no credentials at all;
3. speaks upstream to your real proxy, in its own protocol, and supplies the credentials itself.

The relay lives and dies with the browser window. Nothing is left listening after you close a profile.

It fails closed. If the upstream proxy is not there, refuses your credentials, hangs up mid-handshake or goes silent, the relay refuses the browser’s connection. It never connects to the destination directly instead. A profile pointed at a dead proxy does not open a window at all: the pre-launch check refuses the launch and says so, because a window that has quietly fallen back to your own address, while the profile row still says it exits from São Paulo, is the worst thing this product could do and the one you would not see from inside it.

Press Launch. In order, Ward:

1. starts the local relay for this profile, if it has a proxy;
2. builds the command line for the engine you chose - one flag set for every Chromium build, which differ only by binary, and a generated user.js of preferences for Camoufox and Firefox, which take their proxy settings as preferences rather than as flags;
3. disables non-proxied UDP so WebRTC cannot hand out your real address behind the proxy's back - the equivalent host-candidate restrictions go into the Firefox preferences;
4. opens the browser against this profile's own directory, and applies the stored identity over the DevTools Protocol before any page script has run.

From there it is an ordinary browser window. Close it the way you close any other; Ward shuts the relay down and marks the profile idle.

Folders, tags and notes all exist for the same reason: the difference between five profiles and two hundred is not technical, it is navigational. Folders nest. Tags are yours to invent and can be applied across folders. Both filter the list.

Ward keeps one SQLite database and one directory of browser profiles, together, under your Windows local application data. The app shows you the exact path in its settings - it is a real folder you can open, copy and back up.

To move Ward to another machine, or to take a backup, close Ward and copy that folder. Copying it while a profile is running will capture a browser profile mid-write and you will not enjoy the result.