Die exakten Bytes, die gesendet werden.
Die Probe schreibt zwei Berichtsdateien lokal: HTML und JSON. Berichts- und Gerätedaten verlassen Ihren Rechner erst, wenn Sie auf Share klicken; dann wird die JSON-Datei per POST gesendet. Die GUI liest beim Start separat ein kleines öffentliches Veröffentlichungsmanifest, ohne Installations-ID, Geräteinformationen oder Probe-Ergebnisse zu senden.
Das Teilen ist absichtlich eng begrenzt.
Ihr Name, Ihre Rechner-ID, installierte Software und Dateisystempfade stehen nicht in den Berichtsdaten. Der Server sieht wie jede Website eine Anfrage-IP, speichert zum Missbrauchsschutz aber nur einen täglich gesalzenen Hash; rohe IP-Adressen werden weder in die Datenbank geschrieben noch veröffentlicht. Die geteilten Daten umfassen Stick, Umgebung, Effekte, Diagnosen, Auswahlbezeichnungen und Antwortnotizen; öffentliche Seiten lassen das Antwortnotizfeld weg. Die Updateprüfung ist eine separate, kennungsfreie Manifestanfrage.
Der SubmissionPayload-Vertrag
Alle Felder dieser Liste sind zwischen identischen Geräten geteilte Gerätespezifikationen, grobe Umgebungsdaten, Testdiagnosen, ausgewählte kanonische Bezeichnungen oder Antwortnotizen. Unter Linux können Antwortnotizen neben optional eingegebenem Text auch die von der Sonde gemessene X/Y-Bewegung enthalten.
device– VID:PID, Gerätename des Herstellers, Achsen, Tasten, POVs, Abtastzeitraum, Zeitauflösung, Firmware-Revision, Hardware-Revision, FF-Treiberversion, Fähigkeitsflags und die Liste der unterstützten Effekte mit Typflags.os— Familie (Windows / Linux), Hauptversion, Build, Architektur und .NET-Laufzeitversion. Jeder Wert ist eine grobe Umgebungsangabe, die viele Installationen gemeinsam haben.responses— je Effekt: ausgewählte kanonische Bezeichnungen (veröffentlicht) und ein Antwortnotizfeld, das optional eingegebenen Text sowie unter Linux von der Sonde gemessene Bewegung enthalten kann (gespeichert, aber nie auf der öffentlichen Hardwareseite dargestellt).diagnostics–OK/FAIL: DIERR_…-Ergebnisse pro Effekt (geschlossenes Vokabular, Zeigeradressen entfernt), das Rollup der fehlgeschlagenen Effekte und alle Orchestratorfehler mit Dateipfaden, die per regulärem Ausdruck zu<path>geschwärzt wurden. Wird auf der öffentlichen Hardwareseite veröffentlicht, damit Treiberautoren und Toolentwickler darauf reagieren können.probe_versionundsubmitted_date– nur Datum (keine Uhrzeit).
Lesen Sie das wörtliche Nutzlastformat auf der Beispielberichtsseite →
Nicht im Berichtspayload und nicht von /submit akzeptiert
Das geteilte Berichts-JSON hat ein einziges Schema. Wenn ein Feld nicht darin enthalten ist, lehnt /submit es ab, statt zusätzliche Berichtsdaten zu speichern. Diese Angaben sind niemals Teil einer akzeptierten Berichtseinsendung:
- DirectInput Instanz-GUID – Hash pro Maschine, eine direkte Maschinenkennung.
- Produkt-GUID – doppelte Hardwareidentität über VID:PID hinaus.
- Roher DirectInput-Gerätename – manchmal vom Benutzer festgelegt. Für Übermittlungen wird stattdessen ein für die VID:PID-Tabelle geeigneter Anzeigename verwendet.
- USB-Geräteliste – jedes USB- und HID-Gerät auf dem Host. Starke Oberfläche mit Fingerabdrücken.
- Liste der installierten Software – kein Registry Walk, keine Simulatorinventur, keine SDK-/Laufzeitinventur.
- Vollständige Beschreibung des Betriebssystems – genaue Host-Strings sind zu fingerabdruckbar. Die Nutzlast verwendet grobe Betriebssystemfamilien-/Versionsfelder.
- Dateipfade in Fehlermeldungen – Pfade wie
C:\Users\…oder/home/…werden vor der Serialisierung geschwärzt. - Debug-Protokolle – vom öffentlichen Einreichungsendpunkt nicht akzeptiert.
- Laufzeit der Wanduhr – beim übermittelten Datum handelt es sich nur um das Datum, nicht um die genaue Uhrzeit.
- E-Mail- und Kontaktfelder — niemals Teil des Berichtspayloads. Nach dem Teilen eines Berichts bietet die GUI eine separate optionale Benachrichtigungsanmeldung an, die nur E-Mail + VID:PID an
/notifysendet und getrennt von Einsendungen speichert.
Das eine private Feld
Für die öffentliche Datenbank gilt: Wir veröffentlichen alles, was sicher möglich ist. Das vollständige Feld responses[].notes jedes Effekts halten wir bewusst zurück. Es kann von Testpersonen eingegebenen Text enthalten, der versehentlich persönliche Daten umfasst, sowie daneben gespeicherte, unter Linux von der Sonde gemessene Bewegung; das gesamte Feld bleibt serverseitig.
Alles andere – Fähigkeitsflags, unterstützte Effekte, Betriebssystemfamilie + -version, Chipetiketten, HRESULT-Codes (S_OK / DIERR_…-Namen aus geschlossenem Vokabular), Rollup fehlgeschlagener Effekte, pfad-geschwärzte Ausführungsfehler, die Sondennotiz – wird auf der Geräteseite genau so gerendert, wie es von der Sonde gemeldet wurde. Treiberautoren, Sim-Entwickler und Tool-Entwickler benötigen diese Daten, um darauf reagieren zu können; sie öffentlich zu machen ist der ganze Sinn des Projekts.
Eine Einreichung entfernen
Wenn Sie einen Bericht geteilt haben und ihn entfernen möchten, senden Sie eine E-Mail an [email protected] mit der VID:PID des Geräts und dem ungefähren Einreichungsdatum. Wir fragen nicht nach einem Konto oder einer Tracking-ID – das sind die einzigen Felder, die wir verwenden würden, um die Zeile zu finden.
Wenn Sie sich für die E-Mail-Benachrichtigung nach der Übermittlung entschieden haben, wird diese Adresse separat gespeichert und kann unabhängig entfernt werden. Senden Sie eine E-Mail an denselben Posteingang mit „E-Mail entfernen“ und der Adresse.
Herausgegeben von Rohsam Inc.
FFB Probe wird von Rohsam Inc. herausgegeben, einem kanadischen Softwareherausgeber mit Sitz in Toronto, Ontario.
Rohsam Inc.2727 Steeles Ave West, Unit 103-886
Toronto, ON M3J 3G9
Canada
Für Anfragen zu Datenschutz, Löschung oder Produktsupport wenden Sie sich an [email protected]. Für Anfragen zu Geschäftlichem oder zur Herausgeber-Validierung wenden Sie sich an [email protected].