Confidentialité et sécurité

Anonymisation des données

Lorsque des résultats sont soumis à voxelbench.com, vous choisissez la quantité d'informations identifiantes incluses.

Niveaux d'anonymisation

À configurer dans config.yml :

anonymous:
  anonymization-level: PARTIAL    # NONE, PARTIAL ou FULL

NONE - Pas d'anonymisation

Toutes les données sont envoyées telles quelles, notamment :

• Adresses IP complètes (IPv4 et IPv6)
• Adresses MAC complètes
• Numéros de série des disques
• Nom d'hôte complet
• Noms complets des modèles de disque
• Liste complète des plugins avec leurs versions
• Flags Java complets avec leurs chemins

Non recommandé, sauf si vous faites entièrement confiance au backend et souhaitez un maximum de données pour la comparaison.

PARTIAL - Recommandé

Les identifiants sensibles sont hachés ou masqués :

C'est le niveau par défaut et recommandé. Il offre un bon équilibre entre confidentialité et comparaisons matérielles utiles.

FULL - Confidentialité maximale

Tout ce que fait PARTIAL, avec des protections supplémentaires :

Le nom du CPU, la quantité de RAM, la version de Java et le nom de l'OS restent envoyés pour la comparaison de base.

Ce qui est toujours envoyé

Quel que soit le niveau d'anonymisation, les rapports contiennent :

• Résultats de benchmark : TPS, MSPT, débits et toutes les métriques des tests
• Matériel : nom, fabricant, cœurs et threads du CPU ; quantité de RAM ; type et taille du disque principal
• Logiciel : nom de l'OS, version de Java, réglages mémoire de la JVM, logiciel serveur et sa version, version de VoxelBench, nombre de plugins
• Réglages serveur qui influencent les scores : par exemple la distance d'affichage et de simulation, les limites et fréquences d'apparition des mobs, comparées à leurs valeurs par défaut, et la difficulté du monde
• Serveurs hybrides : le fait que le serveur soit hybride, son mod loader et son nombre de mods
• Environnement d'hébergement : le niveau et l'hébergeur détectés, les signaux qui y ont conduit, le heap alloué et le nombre de processeurs (voir Configuration)

Sécurité de l'authentification

Système challenge-réponse

Lors de la soumission de benchmarks, VoxelBench utilise un système d'authentification challenge-réponse :

1. Le plugin demande un token challenge à usage unique au backend
2. Le challenge a une durée de vie (TTL) de 5 minutes
3. Le plugin calcule une signature HMAC-SHA256 du challenge, de l'identifiant du serveur, d'un horodatage et du hash du JAR, avec un secret intégré aux builds officiels
4. Le rapport est soumis accompagné de cette signature
5. Le backend vérifie la signature avant d'accepter le rapport

Le backend contrôle aussi le hash du JAR par rapport aux builds qu'il connaît : les rapports de builds modifiés ou non officiels sont refusés.

Cela empêche :

• Les attaques par rejeu : chaque challenge ne peut servir qu'une fois
• L'usurpation : seuls les builds officiels du plugin peuvent soumettre des rapports

La signature porte sur le challenge et l'identité du serveur, pas sur le contenu du rapport.

Identité du serveur

Chaque serveur possède un hash d'identité : un hash SHA-256 calculé une seule fois à partir de :

• L'adresse MAC de la première interface réseau qui en a une
• Le nom d'hôte
• Le numéro de série du premier disque

Il est stocké dans plugins/VoxelBench/identity.yml puis réutilisé. Ce hash permet de suivre votre serveur d'une soumission à l'autre sans révéler les identifiants matériels sous-jacents.

Authentification par token

Quand le serveur est lié à un compte VoxelBench (via /bench link), le plugin joint un token d'authentification à ses requêtes. Le token est stocké dans config.yml sous authentication.token.

Ne partagez jamais votre token d'authentification. Il permet de soumettre des rapports au nom de votre serveur.

Stockage des données

Données locales

VoxelBench stocke localement dans plugins/VoxelBench/ :

• config.yml : configuration, dont le token d'authentification et le hash du mot de passe du monitoring
• identity.yml : hash d'identité du serveur
• reports/ : rapports sauvegardés (fichiers JSON), et dans reports/profiles/ les sorties du profileur (JSON, le .jfr brut s'il est conservé, et une petite trace de chaque profil envoyé ou partagé ; celle d'un profil partagé garde le jeton qui supprime son lien public, et reste jusqu'à l'expiration du lien)
• custom_benchmarks/ : profils de benchmark et de stress personnalisés
• reports/memory/ : résumés du tas de /bench memory summary et analyses de vidages de /bench memory analyze (noms de classes, de champs et de plugins, tailles et comptes ; rien n'est tiré des objets eux-mêmes), et une petite trace de chaque rapport envoyé ou partagé (celle d'un rapport partagé garde le jeton qui supprime son lien public, et reste jusqu'à l'expiration du lien)
• heapdumps/ : vidages complets du tas de /bench memory dump, lisibles par le seul compte du serveur. Un vidage du tas contient tout ce que le serveur avait en mémoire, dont le jeton d'authentification, les mots de passe des plugins et les données des joueurs : ne le partagez jamais, et gardez ce dossier hors des dossiers partagés et des sauvegardes
• stress-warmstart.yml : dernières valeurs stables du Stress Limit
• lang/ : fichiers de langue
• certificates/ : certificats SSL (si le monitoring HTTPS est activé)

Données distantes

Les données envoyées à voxelbench.com comprennent :

• Les résultats et métriques des benchmarks, tests et runs Stress Limit
• Les informations matérielles et logicielles du serveur, selon le niveau d'anonymisation (voir plus haut)
• Le hash d'identité du serveur

Quand vous lancez /bench profile upload <id>, ce seul profil (un fichier JSON qui nomme vos plugins, leurs méthodes échantillonnées, les noms des threads, vos versions de serveur et de Java, le système et le nombre de processeurs) part aussitôt, tel quel, vers le compte auquel le serveur est lié ; ajoutez preview pour voir cela avant tout envoi, puis confirm envoie exactement ce qui a été montré. Aucun profil n'est envoyé autrement.

Quand vous lancez /bench profile share <id>, une copie nettoyée de ce seul profil est publiée derrière un lien public non listé, que toute personne qui l'a peut ouvrir, pendant 7 jours, sans aucun compte. Avant l'envoi, VoxelBench retire des noms de threads, de méthodes et de chargeurs de classes les adresses IP, noms d'hôtes, URL, adresses e-mail, chemins de fichiers, UUID, longues chaînes hexadécimales, et les noms des joueurs connectés, des mondes non standard, de l'utilisateur système, de la machine et du dossier du serveur ; les champs dont il ne sait pas qu'ils peuvent être publics ne sont pas recopiés du tout. La copie est publiée aussitôt ; ajoutez d'abord preview pour voir un avis qui dit que le lien est public et liste ce que la copie contient et ce qui a été retiré, puis confirm publie exactement cette copie. La requête est signée comme les rapports de benchmark (seuls les builds officiels peuvent partager) et porte le hash d'identité du serveur, que voxelbench.com n'utilise que pour limiter les abus, sans jamais l'afficher ni le relier au profil partagé. /bench profile unshare <id> supprime le lien avant son expiration, même après la suppression locale du profil.

Quand vous lancez /bench memory upload <id>, ce seul résumé du tas ou cette seule analyse de vidage (un fichier JSON qui nomme vos plugins, des classes et, pour une analyse, des champs, avec des tailles et des comptes, les versions du serveur et de Java, le système, le nombre de processeurs et les chiffres mémoire de la machine) part, tel quel, vers le compte auquel le serveur est lié ; ajoutez preview pour voir cela avant tout envoi.

Quand vous lancez /bench memory share <id>, une copie nettoyée de ce seul rapport est publiée derrière un lien public non listé, que toute personne qui l'a peut ouvrir, pendant 7 jours, sans aucun compte. Avant l'envoi, VoxelBench écarte les champs dont il ne sait pas qu'ils peuvent être publics et les notes de support, arrondit la date à l'heure en UTC (sans fuseau horaire), retire la mémoire libre de la machine et la limite du conteneur et arrondit les tailles du tas à 64 Mo, et retire des noms de classes, de champs et de plugins les adresses IP, URL, adresses e-mail, chemins de fichiers, UUID, longues chaînes hexadécimales, noms de scripts, et les noms des joueurs connectés, des mondes non standard, de l'utilisateur système, de la machine et du dossier du serveur. preview dit que le lien est public et liste ce que la copie contient. La requête est signée comme les rapports de benchmark (seuls les builds officiels peuvent partager) et porte le hash d'identité du serveur, utilisé seulement pour limiter les abus. /bench memory unshare <id> supprime le lien avant son expiration, même après la suppression locale du rapport.

Résumés et analyses ne partent que sur ces commandes (ou les boutons correspondants du menu), un à la fois, jamais pendant un run noté. Un vidage du tas n'est jamais envoyé : aucune commande, aucun bouton, aucun envoi automatique, aucun champ de rapport ou de monitoring ne transporte un .hprof, et le code d'envoi ne lit que le dossier des rapports. Une analyse de vidage tourne dans un processus Java séparé, sur votre machine, qui n'ouvre aucune connexion réseau.

Si vous activez le monitoring distant pour un serveur lié, VoxelBench envoie aussi des relevés de métriques périodiques et les événements détectés ; /bench monitor remote on liste les sources d'événements actives avant tout envoi. Les relevés ne contiennent que des mesures du serveur (TPS, durées de tick, mémoire, CPU, GC, compteurs, noms des mondes, ping moyen), aucun nom de joueur. Si vous activez l'intégration LiteBans (désactivée par défaut), les événements de modération incluent le nom du joueur et le modérateur, et le motif seulement si vous réglez include-reason: true.

Rate limiting

Pour prévenir les abus :

• Cooldown local : 30 minutes entre deux benchmarks (configurable)
• Rate limiting côté backend : protection supplémentaire côté serveur
• Les joueurs disposant de la permission voxelbench.start.force peuvent ignorer le cooldown local

Obfuscation

Les builds de production de VoxelBench sont obfusqués avec ProGuard pour :

• Protéger contre la rétro-ingénierie basique
• Rendre plus difficile l'extraction des endpoints API et des secrets d'authentification
• Réduire la taille du fichier JAR