Privacy

The literal bytes that get sent.

The probe writes two report files locally: HTML and JSON. Report and device data never leave your machine until you click Share; then the JSON file is what gets POSTed. The GUI separately reads a small public release manifest at startup to check for updates, without sending an install ID, device information, or probe results.

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 report payload. 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 covers the stick and its device class, the environment, the test strength, effects, diagnostics, chip selections, and response notes; public pages omit the response-notes field. The update check is a separate identifier-free manifest request.

What gets sent

The `SubmissionPayload` contract

Every field on this list is device-spec data shared across identical units, coarse environment information, the test strength, test diagnostics, chip-selected canonical labels, or response notes. Response notes can include probe-measured X/Y motion, on Windows and Linux, as well as any optional text you typed.

device — VID:PID, device name, device class (device_type: flight, joystick, gamepad, wheel, other, or unknown), 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), major version, build, architecture, and .NET runtime version. Every value is coarse environment data shared across many installations.
run — the test strength every effect played at (strength_pct) and whether it was the device's default or chosen by you (strength_source). Device pages show how many reports ran at each strength.
responses — per effect: chip-selected canonical labels (published) and a response-notes field that can contain optional typed text plus the probe-measured motion, signed X/Y peaks as a percentage of each axis's half range (stored but never rendered 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 report payload or accepted by /submit

The shared report JSON has one schema, and the app sends nothing outside it. If a request carries a field that is not on the schema, /submit never publishes it. These are never part of a report the app submits:

DirectInput Instance GUID — per-machine hash, a direct machine identifier.
Product GUID — duplicate hardware identity beyond VID:PID.
Raw DirectInput device name of recognised hardware — sometimes user-set. For a VID:PID in the app's device table, the table's friendly name is sent instead. For a device the table does not know, the app sends the model name you typed when asked or, failing that, a sanitised driver-reported name, and that name is published as the device name.
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.
Names of other running programs — the Welcome warning and the exclusive-access message name programs that can take your device, but only on your screen. Those names are not added to the report.
Email and contact fields — never part of the report payload. After a report is shared, the GUI offers a separate optional notification signup that sends only email + VID:PID to /notify and stores it separately from submissions.

What's NOT on the public hardware page

The one private field

The public DB philosophy is publish everything we safely can. We deliberately hold back the entire per-effect responses[].notes field. It can contain tester-typed text, which may accidentally include personal data, and the probe-measured motion stored alongside it; the whole field stays server-side.

Everything else — device class, capability flags, supported effects, OS family + version, test strength, 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.

Deletion

Removing a submission

If you've shared a report and want it removed, mail [email protected] with the support code the app showed after sharing (it starts with PRB-). Without the code, send the device's VID:PID and the approximate submission date instead. No account is needed either way.

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.

Publisher and contact

Published by Rohsam Inc.

FFB Probe is published by Rohsam Inc., a Canadian software publisher based in Toronto, Ontario.

Rohsam Inc.
2727 Steeles Ave West, Unit 103-886
Toronto, ON M3J 3G9
Canada

For privacy, deletion, or product support requests, contact [email protected]. For business or publisher validation inquiries, contact [email protected].