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, environment, 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, test diagnostics, chip-selected canonical labels, or response notes. On Linux, response notes can include probe-measured X/Y motion as well as any optional text you typed.

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), major version, build, architecture, and .NET runtime version. Every value is coarse environment data shared across many installations.
responses — per effect: chip-selected canonical labels (published) and a response-notes field that can contain optional typed text plus Linux probe-measured motion (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. If a field is not on that schema, /submit rejects it rather than storing extra report data. These are never part of an accepted report 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 — 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 Linux probe-measured motion stored alongside it; the whole field 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.

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.

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].