FFB Probe Diagnostic
Langue actuelle du site Français (Canada)
Télécharger
Confidentialité

Les octets exacts qui sont envoyés.

La sonde écrit localement deux fichiers de rapport : HTML et JSON. Les données du rapport et de l'appareil ne quittent jamais votre machine avant que vous cliquiez sur Share ; le fichier JSON est alors envoyé par POST. L'interface lit séparément au démarrage un petit manifeste public des versions pour rechercher les mises à jour, sans envoyer d'identifiant d'installation, d'informations sur l'appareil ni de résultats de la sonde.

Prévisualiser un exemple de rapport Télécharger FFB Probe
En langage clair

Le partage est volontairement limité.

Votre nom, l’identifiant de la machine, les logiciels installés et les chemins du système de fichiers ne figurent pas dans les données du rapport. Le serveur voit une adresse IP de requête comme tout site web, mais ne conserve qu’un hachage salé quotidien contre les abus ; les adresses IP brutes ne sont ni écrites dans la base ni publiées. Les données partagées couvrent le manche et sa classe de périphérique, l’environnement, l’intensité du test, les effets, les diagnostics, les libellés choisis et les notes de réponse ; les pages publiques omettent le champ des notes. La recherche de mise à jour est une requête de manifeste séparée et sans identifiant.

Ce qui est envoyé

Le contrat SubmissionPayload

Chaque champ de cette liste correspond à des spécifications partagées entre des unités identiques, à des informations générales sur l’environnement, à l’intensité du test, à des diagnostics de test, à des libellés canoniques choisis ou à des notes de réponse. Sous Windows comme sous Linux, ces notes peuvent inclure le mouvement X/Y mesuré par la sonde ainsi que tout texte facultatif saisi.

  • device — VID:PID, nom de l'appareil, classe d'appareil (device_type : flight, joystick, gamepad, wheel, other ou unknown), axes, boutons, points de vue, période d'échantillonnage, résolution temporelle, révision du micrologiciel, révision du matériel, version du pilote FF, indicateurs de capacité et liste des effets pris en charge avec les indicateurs de type.
  • os — famille (Windows / Linux), version principale, build, architecture et version du runtime .NET. Chaque valeur est une donnée d'environnement générale partagée par de nombreuses installations.
  • run — l’intensité du test à laquelle chaque effet a été joué (strength_pct) et s’il s’agissait de la valeur par défaut du périphérique ou d’une valeur que vous avez choisie (strength_source). Les pages des périphériques indiquent combien de rapports ont été effectués à chaque intensité.
  • responses — pour chaque effet : libellés canoniques choisis (publiés) et champ de notes de réponse pouvant contenir du texte facultatif ainsi que le mouvement mesuré par la sonde, soit les pics X/Y signés en pourcentage de la demi-course de chaque axe (stocké, mais jamais affiché sur la page publique du matériel).
  • diagnostics — résultats par effet OK / FAIL: DIERR_… (vocabulaire fermé, adresses de pointeur supprimées), le cumul des effets échoués, et toutes les erreurs de l'orchestrateur avec les chemins de fichiers expurgés par regex vers <path>. Publié sur la page publique du matériel afin que les auteurs de pilotes et les constructeurs d'outils puissent agir en conséquence.
  • probe_version et submitted_date — date uniquement (pas d'heure).

Lisez le format littéral de la charge utile sur l'exemple de page de rapport →

Ce que nous ne collectons jamais

Absent de la charge utile du rapport et refusé par /submit

Le JSON du rapport partagé suit un seul schéma, et l'application n'envoie rien en dehors de celui-ci. Si une requête contient un champ absent du schéma, /submit ne le publie jamais. Ces éléments ne font jamais partie d'un rapport envoyé par l'application :

  • GUID de l'instance DirectInput — hachage par machine, un identifiant direct de la machine.
  • GUID du produit — identité matérielle dupliquée au-delà de VID:PID.
  • Nom brut de l'appareil DirectInput pour le matériel reconnu — parfois défini par l'utilisateur. Pour un VID:PID présent dans la table des appareils de l'application, c'est le nom convivial issu de la table qui est envoyé. Pour un appareil que la table ne connaît pas, l'application envoie le nom de modèle que vous avez saisi à sa demande ou, à défaut, un nom nettoyé signalé par le pilote ; ce nom est publié comme nom de l'appareil.
  • Liste des périphériques USB — chaque périphérique USB et HID de l'hôte. Surface importante de prise d'empreinte.
  • Liste des logiciels installés — pas de parcours du registre, pas d'inventaire de simulateur, pas d'inventaire SDK/runtime.
  • Description complète du système d'exploitation — les chaînes d'hôte exactes sont trop propices à la prise d'empreinte. La charge utile utilise des champs grossiers de famille/version du système d'exploitation.
  • Chemins de fichiers dans les messages d'erreur — les chemins tels que C:\Users\… ou /home/… sont expurgés avant la sérialisation.
  • Journaux de débogage — non acceptés par le point de terminaison de soumission publique.
  • Durée d'exécution à l'horloge murale — la date soumise est uniquement la date, pas l'heure précise.
  • Noms des autres programmes en cours d’exécution — l’avertissement de l’écran d’accueil et le message d’accès exclusif nomment les programmes susceptibles d’accaparer votre périphérique, mais seulement sur votre écran. Ces noms ne sont pas ajoutés au rapport.
  • Champs d'adresse courriel et de contact — ils ne font jamais partie de la charge utile du rapport. Après le partage d'un rapport, l'interface propose une inscription facultative et séparée aux notifications, qui envoie uniquement l'adresse courriel + VID:PID à /notify et la stocke séparément des envois.
Qu'est-ce que NOT sur la page publique du matériel

Le seul domaine privé

La philosophie de la base publique est de publier tout ce que nous pouvons en toute sécurité. Nous retenons volontairement l’intégralité du champ responses[].notes de chaque effet. Il peut contenir du texte saisi susceptible d’inclure accidentellement des données personnelles, ainsi que le mouvement mesuré par la sonde stocké avec ce texte ; tout le champ reste côté serveur.

Tout le reste — classe de périphérique, indicateurs de capacité, effets pris en charge, famille et version du système d’exploitation, intensité du test, étiquettes de puces, codes HRESULT (noms à vocabulaire fermé S_OK / DIERR_…), cumul des effets échoués, erreurs d’exécution aux chemins expurgés, la note de la sonde — est rendu sur la page du périphérique exactement comme la sonde l’a signalé. Les auteurs de pilotes, les développeurs de simulateurs et les créateurs d’outils ont besoin de ces données pour agir ; les rendre publiques est toute la raison d’être du projet.

Effacement

Supprimer une soumission

Si vous avez partagé un rapport et souhaitez le faire retirer, écrivez à [email protected] en indiquant le code d’assistance affiché par l’app après le partage (il commence par PRB-). Sans ce code, envoyez plutôt le VID:PID du périphérique et la date approximative de la soumission. Aucun compte n’est nécessaire dans un cas comme dans l’autre.

Si vous avez accepté de recevoir l'e-mail de notification post-soumission, cette adresse est stockée séparément et peut être supprimée indépendamment. Envoyez la même boîte de réception avec "supprimer l'e-mail" et l'adresse.

Éditeur et contact

Publié par Rohsam Inc.

FFB Probe est publié par Rohsam Inc., un éditeur de logiciels canadien établi à Toronto, en Ontario.

Rohsam Inc.
2727 Steeles Ave West, Unit 103-886
Toronto, ON M3J 3G9
Canada

Pour des demandes de confidentialité, de suppression ou de soutien produit, contactez [email protected]. Pour des demandes commerciales ou de validation d'éditeur, contactez [email protected].