FFB Probe Diagnostic
Langue actuelle du site Français
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.

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 de réponse. 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 leurs 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 si elle correspondait à la valeur par défaut du périphérique ou à votre choix (strength_source). Les pages des périphériques indiquent combien de rapports ont été exécuté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, sous forme de 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 OK / FAIL: DIERR_… par effet (vocabulaire fermé, adresses de pointeur supprimées), le cumul des effets ayant échoué et toutes les erreurs de l'orchestrateur dont les chemins de fichiers sont 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à du 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 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 sur l'hôte. Surface importante de prise d'empreintes.
  • Liste des logiciels installés — pas de parcours de 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'empreintes. 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.
  • Heure d'exécution réelle — 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 uniquement 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, libellés de puces, codes HRESULT (noms à vocabulaire fermé S_OK / DIERR_…), récapitulatif des effets en échec, erreurs d’exécution aux chemins expurgés, note de la sonde — est affiché 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 qu’il soit supprimé, écrivez à [email protected] en indiquant le code d’assistance affiché par l’application 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 les deux cas.

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 basé à Toronto, Ontario.

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

Pour toute demande de confidentialité, de suppression ou de support produit, contactez [email protected]. Pour toute demande commerciale ou de validation d'éditeur, contactez [email protected].