FFB Probe Diagnostic
Lingua corrente del sito Italiano
Scaricamento
Privacy

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.

Visualizza l'anteprima di un report di esempio Scarica FFB Probe
In un inglese semplice

La condivisione è intenzionalmente limitata.

Nome, ID macchina, software installato e percorsi del file system non fanno parte dei dati del report. 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 lo stick e la sua classe di dispositivo, l'ambiente, l'intensità del test, gli effetti, la diagnostica, le etichette selezionate e le note di risposta; le pagine pubbliche omettono il campo delle note di risposta. Il controllo degli aggiornamenti è una richiesta di manifest separata e priva di identificatori.

Cosa viene inviato

Il contratto SubmissionPayload

Ogni campo di questo elenco è costituito da specifiche del dispositivo condivise tra unità identiche, informazioni generali sull'ambiente, intensità del test, diagnostica del test, etichette canoniche selezionate o note di risposta. Le note di risposta possono includere il movimento X/Y misurato dalla sonda, su Windows e Linux, oltre all'eventuale testo facoltativo che hai digitato.

  • device — VID:PID, nome del dispositivo, classe del dispositivo (device_type: flight, joystick, gamepad, wheel, other o unknown), 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.
  • run — l'intensità del test con cui è stato riprodotto ogni effetto (strength_pct) e se era quella predefinita del dispositivo o scelta da te (strength_source). Le pagine dei dispositivi mostrano quanti report sono stati eseguiti a ciascuna intensità.
  • responses — per effetto: etichette canoniche selezionate (pubblicate) e un campo di note di risposta che può contenere testo facoltativo più il movimento misurato dalla sonda, cioè i picchi X/Y con segno in percentuale della semi-escursione di ciascun asse (memorizzato, ma mai mostrato nella pagina hardware pubblica).
  • diagnostics — per effetto, risultati OK / 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_version e submitted_date — solo la data (senza l'ora).

Leggi il formato letterale del payload nella pagina del report di esempio →

Quello che non raccogliamo mai

Non presente nel payload del rapporto né accettato da /submit

Il JSON del rapporto condiviso ha un solo schema e l'app non invia nulla al di fuori di esso. Se una richiesta contiene un campo che non fa parte dello schema, /submit non lo pubblica mai. Questi elementi non fanno mai parte di un rapporto inviato dall'app:

  • 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 per l'hardware riconosciuto — a volte impostato dall'utente. Per un VID:PID presente nella tabella dei dispositivi dell'app viene inviato invece il nome descrittivo della tabella. Per un dispositivo che la tabella non conosce, l'app invia il nome del modello digitato quando richiesto oppure, in mancanza, un nome ripulito riportato dal driver; quel nome viene pubblicato come nome del dispositivo.
  • 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.
  • Nomi di altri programmi in esecuzione — l'avviso della schermata di benvenuto e il messaggio di accesso esclusivo indicano i programmi che possono occupare il tuo dispositivo, ma solo sul tuo schermo. Quei nomi non vengono aggiunti al report.
  • 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 /notify e la memorizza separatamente dagli invii.
Cos'è NOT nella pagina hardware pubblica

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 da chi esegue il test, che potrebbe includere accidentalmente dati personali, e il movimento misurato dalla sonda memorizzato insieme al testo; l'intero campo resta lato server.

Tutto il resto — classe del dispositivo, flag di funzionalità, effetti supportati, famiglia + versione del sistema operativo, intensità del test, 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.

Cancellazione

Rimozione di un invio

Se hai condiviso un report e vuoi che venga rimosso, scrivi a [email protected] indicando il codice di supporto che l'app ha mostrato dopo la condivisione (inizia con PRB-). Se non hai il codice, invia invece il VID:PID del dispositivo e la data approssimativa dell'invio. In nessun caso serve un account.

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.

Editore e contatto

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