What Your Setup Says About You

Vera sessions now include a system profile: a snapshot of the hardware and software environment where gameplay happened. When you visit a session on a Vera profile, you'll see it displayed above the process and driver tables. Operating system, processor, GPU, RAM, BIOS mode, Secure Boot state, and virtualization configuration.

Vera is a trust product, and trust products don't get to ship data collection features without explaining exactly what they collect, what they don't, and why.

What We Capture

The system profile is built from standard Windows Management Instrumentation (WMI) queries, the same data you'd see if you opened msinfo32.exe on your machine. Here's what a profile looks like:

Operating System

• OS name and version (e.g., "Windows 11 Home, 10.0.26220, x64")
• Install date (date only, no time, no precision beyond the day)

Hardware

• System manufacturer and model (e.g., "Gigabyte B550 AORUS PRO AC")
• Processor name, core count, and logical processor count
• Total physical memory
• Graphics card(s) with VRAM

BIOS & Boot

• BIOS version and mode (UEFI or Legacy)
• Secure Boot state (Enabled, Disabled, or Not Supported)

Virtualization

• Hyper-V VM Monitor Mode Extensions
• Hyper-V Second Level Address Translation
• Hyper-V Virtualization Enabled in Firmware
• Hyper-V Data Execution Protection

System

• Locale and time zone
• Boot device (drive letter only)

That's the full list. No more, no less.

Why This Matters for Integrity

System profile data isn't interesting by itself. A Ryzen 5 5600X with 32GB of RAM is just hardware. What makes it meaningful is context: the relationship between the system environment and the integrity claims built on top of it.

Virtualization state is directly relevant. A player running inside a virtual machine with specific Hyper-V configurations has a different trust posture than someone on bare metal. VMs can sandbox cheat software in ways that are invisible to user-mode detection. Knowing the virtualization state doesn't prove anything by itself, but it provides context that makes the rest of the evidence more interpretable.

Secure Boot affects the driver trust chain. When Secure Boot is enabled, Windows enforces that only signed, verified drivers can load at boot time. When it's disabled, unsigned drivers, including those used by some cheating tools, can run without restriction. Again: not proof, but context. A session recorded on a system with Secure Boot disabled is in a different trust category than one with it enabled.

Hardware consistency matters over time. If a player's system profile shows the same GPU, CPU, and motherboard across hundreds of sessions, that consistency itself is a signal. A sudden change (different hardware, different virtualization state) isn't suspicious by default, but it's a data point. The record captures it. The community can interpret it.

The system profile doesn't prove anything on its own. It provides the environmental context that makes every other piece of evidence more meaningful.

What We Redact, and Why

Here's what Vera does not store from your system:

• Computer name → Replaced with [REDACTED] or omitted entirely
• User name → Replaced with [REDACTED]
• Windows directory paths → Stripped to drive letter only
• System directory paths → Stripped to drive letter only
• Any path containing your username → Stripped to drive letter
• Network MAC addresses → Not collected
• Disk serial numbers → Not collected
• License keys → Not collected
• Unique device identifiers → Not stored in identifiable form

The redaction happens before the data leaves your machine. Not on the server. Not in transit. At the source, on your system, in the collector process, before anything is written to disk or transmitted anywhere.

This is a deliberate architectural decision. There's a simpler implementation where you collect everything and redact on the server. We rejected it because it means sensitive data exists, even briefly, outside the player's control. In Vera's model, your computer name never leaves your computer. Your username never leaves your machine. The redaction boundary is the machine itself.

How Change Detection Works

Here's a detail that matters for both privacy and performance: Vera doesn't send your system profile every session.

Instead, the collector calculates a SHA-256 hash of the normalized system information. That hash is stored locally. On each subsequent session, the collector hashes the current system state and compares it to the stored hash. If nothing changed (which is the case for 99.9% of sessions, because hardware doesn't change often) nothing is sent. No network call. No data leaves the machine.

Only when the hash changes (a hardware upgrade, a BIOS update, a change in virtualization settings) does the collector submit the new profile to the server.

The result:

• Near-zero network overhead. Most sessions transmit zero additional bytes for system info.
• Near-zero CPU overhead. The WMI queries take 50-200ms. The hash calculation takes about 1ms. It runs once, on startup.
• No "phoning home." Vera isn't reporting your hardware fingerprint every time you play. It reports it once, and then only reports changes.

This is infrastructure-level efficiency for a privacy-sensitive data type. The system doesn't just claim to be lightweight. It actually is, and the mechanism is explainable.

What We Learned Building This

Some things were harder than expected. Some were easier. A few were genuinely surprising.

WMI is reliable but inconsistent. The same query returns slightly different formatting across Windows versions. Normalization (trimming whitespace, standardizing case, handling null fields) took more care than the queries themselves. We documented every edge case in the code for future reference.

Graphics cards are messy. Some systems have multiple GPUs, integrated and discrete. Some report VRAM in bytes, some in kilobytes, some in a format that doesn't match any documented standard. We display all detected GPUs with whatever VRAM information is available, and we don't pretend the data is cleaner than it is.

The hardest part is deciding what not to collect. There's a constant temptation to add "just one more field": network adapter info, disk model, installed software list. Every additional field provides more context. Every additional field is also more data leaving the player's machine. The discipline of minimization, collecting only what's directly relevant to gaming integrity, is a design constraint, not a technical one. It requires saying no to things that would be useful.

Privacy isn't a feature you add. It's a constraint you design around. The system profile reflects that constraint at every level.

What You'll See

On session pages (/w/ routes), the system profile appears as a compact card above the process and driver tables. It shows 4-5 lines of key information:

• OS, version, architecture
• Processor, cores, RAM
• GPU(s), system manufacturer
• BIOS mode, Secure Boot, Hyper-V summary
• First seen date, last verified date

If no system info exists for a session (older sessions recorded before this feature shipped) the card shows a clean fallback message. No broken UI. No misleading absence.

The "first seen" and "last verified" dates are important. They tell you how long this specific hardware configuration has been associated with this device. A system profile that's been consistent since January carries a different signal than one that changed yesterday. The dates are the difference.

Why We're Telling You This

Most companies ship features like this and write a changelog line: "Added system information collection." We could do that. It would be easier.

But Vera is a product that asks to run on your gaming PC. It collects data about your system while you compete. That relationship, between the software and the person who installs it, only works if the person understands exactly what the software does.

So we wrote this. Not because we had to. Because it's the kind of thing a trust product should do.

If you can't explain your data collection in a public blog post, you probably shouldn't be collecting the data.

We can explain it. We just did.

To see system profiles in action, visit a session on any verified profile at veraproject.xyz/explore. If you have questions about what's collected or want to suggest changes, hit the Share an Idea button.