Privacy

The literal bytes that get sent.

The probe writes two files locally: an HTML report and a JSON payload. Nothing leaves your machine until you click Share. When you do, the JSON file is what gets POSTed. The HTML report shows the same JSON in a <pre> block at the bottom so you can read it before sharing.

Preview a sample report Download FFB Probe

In plain English

Sharing is intentionally narrow.

Your name, machine ID, installed software, and filesystem paths are not in the payload and do not leave your machine. The server sees a request IP like any website, but stores only a daily salted hash for abuse protection; raw IPs are not written to the database or published. The shared payload is your stick's model/capabilities, what effects played, and the chip selections you made.

What gets sent

The `SubmissionPayload` contract

Every field on this list is either device-spec data shared across identical units (VID:PID, capability flags, supported effects, firmware revision), coarse environment info (OS family + major version), or your own chip-selected canonical labels and any free-text notes you chose to type.

device — VID:PID, manufacturer device name, axes, buttons, povs, sample period, time resolution, firmware revision, hardware revision, FF driver version, capability flags, and the supported-effects list with type flags.
os — family (Windows / Linux / macOS), major version, build, architecture, .NET runtime version. Every value is shared across millions of identical installations.
responses — per effect: chip-selected canonical labels (published) and any free-text notes you typed (kept server-side only, never on the public hardware page).
diagnostics — per-effect OK / FAIL: DIERR_… results (closed vocabulary, pointer addresses stripped), the failed-effect roll-up, and any orchestrator errors with file paths regex-redacted to <path>. Published on the public hardware page so driver authors and tool builders can act on it.
probe_version and submitted_date — date only (no clock time).

Read the literal payload format on the sample report page →

What we never collect

Not in the payload, not accepted by the server

The shared JSON has one schema. If a field is not on that schema, the website rejects it rather than storing extra data. These are never part of an accepted submission:

DirectInput Instance GUID — per-machine hash, a direct machine identifier.
Product GUID — duplicate hardware identity beyond VID:PID.
Raw DirectInput device name — sometimes user-set. Submissions use a VID:PID-table friendly name instead.
USB device list — every USB and HID device on the host. Heavy fingerprinting surface.
Installed-software list — no registry walk, no simulator inventory, no SDK/runtime inventory.
Full OS description — exact host strings are too fingerprintable. The payload uses coarse OS family/version fields.
File paths in error messages — paths such as C:\Users\… or /home/… are redacted before serialization.
Debug logs — not accepted by the public submission endpoint.
Wall-clock run time — submitted date is date-only, not precise time.
Email and contact fields — the probe does not ask for them and the server schema does not accept them.

What's NOT on the public hardware page

The one private field

The public DB philosophy is publish everything we can. The only thing we deliberately hold back is per-effect free-text notes (responses[].notes) — what you typed in the answer text box. That's the one place a tester might paste something personal, copy-paste a path, or otherwise smudge the no-PII guarantee, so it stays server-side.

Everything else — capability flags, supported effects, OS family + version, chip labels, HRESULT codes (S_OK / DIERR_… closed-vocabulary names), failed-effect roll-up, path-redacted run errors, the probe note — is rendered on the device page exactly as the probe reported it. Driver authors, sim devs, and tool builders need this data to act on; making it public is the whole point of the project.

Audit it yourself

Read the source

The contract is one C# record: SubmissionPayload.cs. Anything not on that type cannot leave the machine. The renderer that builds it from the rich internal report is SubmissionPayloadFactory.cs — single trust boundary, single code path. The HTML report's <pre> block at the bottom shows the exact bytes the GUI's Share button will POST. There is no second hidden payload.

Deletion

Removing a submission

If you've shared a report and want it removed, mail [email protected] with the device's VID:PID and the approximate submission date. We don't ask for an account or a tracking ID — those are the only fields we'd use to find the row.

If you opted into the post-submission notification email, that address is stored separately and can be removed independently. Mail the same inbox with "remove email" and the address.