I byte esatti che vengono inviati.
La sonda scrive due file in locale: un report HTML e un payload JSON. Nulla lascia la tua macchina finché non fai clic su Share. Quando lo fai, è il file JSON a essere inviato tramite POST. Il report HTML mostra lo stesso JSON in un blocco <pre> in fondo, così puoi leggerlo prima di condividerlo.
La condivisione è intenzionalmente limitata.
Il tuo nome, ID macchina, software installato e percorsi del file system non sono nel payload e non lasciano la tua macchina. Il server vede un IP di richiesta come qualsiasi sito web, ma memorizza solo un hash salato giornaliero per la protezione dagli abusi; gli IP grezzi non vengono scritti nel database né pubblicati. Il carico utile condiviso dipende dal modello/capacità del tuo stick, dagli effetti riprodotti e dalle selezioni di chip effettuate.
Il contratto SubmissionPayload
Ogni campo in questo elenco contiene dati sulle specifiche del dispositivo condivisi tra unità identiche (VID:PID, flag di funzionalità, effetti supportati, revisione del firmware), informazioni generali sull'ambiente (famiglia del sistema operativo + versione principale) o etichette canoniche selezionate dal chip ed eventuali note di testo libero che hai scelto di digitare.
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 / macOS), versione principale, build, architettura, versione del runtime .NET. Ogni valore è condiviso tra milioni di installazioni identiche.responses— per effetto: etichette canoniche selezionate tramite chip (pubblicate) ed eventuali note di testo libero che hai digitato (conservate solo lato server, mai sulla 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 nel payload, non accettato dal server
Lo JSON condiviso ha uno schema. Se un campo non è presente in quello schema, il sito web lo rifiuta anziché archiviare dati aggiuntivi. Questi non fanno mai parte di una presentazione accettata:
- 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 e-mail e di contatto — la sonda non li richiede e lo schema del server non li accetta.
L'unico campo privato
La filosofia del database pubblico è pubblicare tutto ciò che possiamo. L'unica cosa che tratteniamo deliberatamente sono le note di testo libero per effetto, ovvero ciò che hai digitato nella casella di testo della risposta. È l'unico punto in cui un tester potrebbe incollare qualcosa di personale, copiare e incollare un percorso o altrimenti compromettere la garanzia di assenza di PII, quindi rimane 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].