I byte esatti che vengono inviati.
La sonda scrive localmente due file di rapporto: HTML e JSON. I dati del rapporto e del dispositivo non lasciano il computer finché non fai clic su Share; a quel punto il file JSON viene inviato tramite POST. La GUI legge separatamente all'avvio un piccolo manifesto pubblico delle versioni per verificare gli aggiornamenti, senza inviare ID di installazione, informazioni sul dispositivo o risultati della sonda.
La condivisione è intenzionalmente limitata.
Nome, ID macchina, software installato e percorsi del file system non fanno parte dei dati del rapporto. Il server vede un IP di richiesta come qualsiasi sito web, ma conserva solo un hash giornaliero con salt per prevenire abusi; gli IP grezzi non vengono scritti nel database né pubblicati. I dati condivisi coprono stick, ambiente, effetti, diagnostica, etichette selezionate e note di risposta; le pagine pubbliche omettono il campo delle note. Il controllo aggiornamenti è una richiesta di manifest separata e priva di identificatori.
Il contratto SubmissionPayload
Ogni campo di questo elenco è costituito da specifiche condivise tra unità identiche, informazioni generali sull’ambiente, diagnostica del test, etichette canoniche selezionate o note di risposta. Su Linux, le note possono includere il movimento X/Y misurato dalla sonda oltre all’eventuale testo digitato.
device— VID:PID, nome del dispositivo del produttore, assi, pulsanti, pov, periodo di campionamento, risoluzione temporale, revisione del firmware, revisione dell'hardware, versione del driver FF, flag di funzionalità ed elenco degli effetti supportati con flag di tipo.os— famiglia (Windows / Linux), versione principale, build, architettura e versione del runtime .NET. Ogni valore è un dato ambientale generico condiviso da molte installazioni.responses— per effetto: etichette canoniche selezionate (pubblicate) e un campo di note di risposta che può contenere testo facoltativo e movimento misurato dalla sonda su Linux (memorizzato, ma mai mostrato nella pagina hardware pubblica).diagnostics— per effetto, risultatiOK/FAIL: DIERR_…(vocabolario chiuso, indirizzi dei puntatori rimossi), il riepilogo degli effetti non riusciti ed eventuali errori dell'orchestratore con i percorsi dei file oscurati tramite regex in<path>. Pubblicato sulla pagina hardware pubblica in modo che gli autori dei driver e i creatori di strumenti possano agire di conseguenza.probe_versionesubmitted_date— solo la data (senza l'ora).
Leggi il formato letterale del payload nella pagina del report di esempio →
Non presente nel payload del rapporto né accettato da /submit
Il JSON del rapporto condiviso ha un solo schema. Se un campo non ne fa parte, /submit lo rifiuta invece di memorizzare dati aggiuntivi. Questi elementi non fanno mai parte di un rapporto accettato:
- GUID dell'istanza DirectInput — hash per macchina, un identificatore diretto della macchina.
- GUID del prodotto — identità hardware duplicata oltre il VID:PID.
- Nome non elaborato del dispositivo DirectInput — a volte impostato dall'utente. Gli invii utilizzano invece un nome descrittivo adatto alla tabella VID:PID.
- Elenco dei dispositivi USB — ogni dispositivo USB e HID presente sull'host. Ampia superficie per il fingerprinting.
- Elenco dei software installati — nessuna scansione del registro, nessun inventario dei simulatori, nessun inventario di SDK/runtime.
- Descrizione completa del sistema operativo — le stringhe host esatte sono troppo identificabili tramite fingerprinting. Il payload utilizza campi generici per famiglia/versione del sistema operativo.
- Percorsi dei file nei messaggi di errore — i percorsi come
C:\Users\…o/home/…vengono oscurati prima della serializzazione. - Registri di debug — non accettati dall'endpoint di invio pubblico.
- Orario effettivo di esecuzione — la data di invio contiene solo la data, non l'ora precisa.
- Campi email e di contatto — non fanno mai parte del payload del rapporto. Dopo la condivisione, la GUI offre un'iscrizione facoltativa separata alle notifiche, che invia solo email + VID:PID a
/notifye la memorizza separatamente dagli invii.
L'unico campo privato
La filosofia del database pubblico è pubblicare tutto ciò che possiamo in sicurezza. Tratteniamo intenzionalmente l’intero campo responses[].notes di ogni effetto. Può contenere testo digitato, che potrebbe includere accidentalmente dati personali, e movimento misurato dalla sonda su Linux memorizzato insieme al testo; l’intero campo resta lato server.
Tutto il resto — flag di funzionalità, effetti supportati, famiglia + versione del sistema operativo, etichette dei chip, codici HRESULT (nomi a vocabolario chiuso S_OK / DIERR_…), riepilogo degli effetti non riusciti, errori di esecuzione con percorsi oscurati, la nota della sonda — viene visualizzato sulla pagina del dispositivo esattamente come lo ha riportato la sonda. Gli autori di driver, gli sviluppatori di simulatori e i creatori di strumenti hanno bisogno di questi dati per agire; renderli pubblici è il senso stesso del progetto.
Rimozione di un invio
Se hai condiviso un report e desideri che venga rimosso, invia un'e-mail a [email protected] indicando il VID:PID del dispositivo e la data approssimativa di invio. Non chiediamo un account o un ID di tracciamento: questi sono gli unici campi che utilizzeremmo per trovare la riga.
Se hai attivato l'e-mail di notifica post-invio, tale indirizzo viene archiviato separatamente e può essere rimosso in modo indipendente. Invia la stessa casella di posta con "rimuovi email" e l'indirizzo.
Pubblicato da Rohsam Inc.
FFB Probe è pubblicato da Rohsam Inc., un editore di software canadese con sede a Toronto, Ontario.
Rohsam Inc.2727 Steeles Ave West, Unit 103-886
Toronto, ON M3J 3G9
Canada
Per richieste relative alla privacy, alla cancellazione o al supporto del prodotto, contatta [email protected]. Per richieste commerciali o di convalida dell'editore, contatta [email protected].