Privacy & Security
VoxelBench is designed with privacy in mind. You control what data is collected and shared.
Data Anonymization
When benchmark results are submitted to voxelbench.com, you can choose how much identifying information is included.
Anonymization Levels
Configure in config.yml:
anonymous:
anonymization-level: PARTIAL # NONE, PARTIAL, or FULL
NONE - No Anonymization
All data is sent as-is. Includes:
- Full IP addresses (IPv4 & IPv6)
- Full MAC addresses
- Disk serial numbers
- Full hostname
- Full disk model names
- Complete plugin list with versions
- Full Java flags and paths
Not recommended unless you fully trust the backend and want maximum data for comparison.
PARTIAL - Recommended
Sensitive identifiers are hashed or masked:
| Data | Treatment |
|---|---|
| IP addresses | Last 2 octets masked (e.g., 192.168.xxx.xxx) |
| MAC addresses | SHA-256 hash (16 characters) |
| Disk serial numbers | SHA-256 hash (16 characters) |
| Hostname | SHA-256 hash (16 characters) |
| CPU name | Sent as-is (needed for comparison) |
| Disk models | Sent as-is (e.g., "Samsung 980 PRO") |
| Plugin list | Sent as-is |
| Java version | Sent as-is |
| OS name | Sent as-is |
This is the default and recommended level. It provides a good balance between privacy and useful hardware comparisons.
FULL - Maximum Privacy
Everything from PARTIAL, plus additional protections:
| Data | Treatment |
|---|---|
| Disk models | Replaced with generic type (e.g., "Generic SSD", "Generic NVMe") |
| Plugin list | Removed (only total plugin count is sent) |
| Network interfaces | Anonymized names (e.g., eth_a1b2) |
| Java flags | Paths anonymized (e.g., /home/<user>/...) |
Still keeps CPU name, RAM amount, Java version, and OS name for basic comparison.
What is Always Sent
Regardless of anonymization level, the following is always included in reports:
- Benchmark results: TPS, MSPT, throughput, and all test metrics
- CPU name and vendor: Required for meaningful hardware comparisons
- RAM amount: Total and available memory
- Java version: JRE version and vendor
- OS name: Operating system name and version
- Server type: Spigot, Paper, or Folia
Authentication Security
Challenge-Response System
When submitting benchmarks, VoxelBench uses a challenge-response authentication system:
- The plugin requests a one-time challenge token from the backend
- The challenge has a 5-minute TTL (time-to-live)
- The plugin signs the challenge using HMAC-SHA256
- The signed report is submitted to the backend
- The backend verifies the signature before accepting the report
This prevents:
- Replay attacks: Each challenge can only be used once
- Tampering: Reports cannot be modified after signing
- Spoofing: Only the official plugin can generate valid signatures
Server Identity
Each server has a unique identity hash generated from:
- Network interface MAC addresses
- Hostname
- Disk serial numbers
This hash is used to track your server across benchmark submissions without revealing actual hardware identifiers (when using PARTIAL or FULL anonymization).
JWT Authentication
When linked to a VoxelBench account (via /bench link), the plugin uses JWT tokens for authenticated requests. The token is stored in config.yml under authentication.token.
Never share your authentication token. It grants the ability to submit reports on behalf of your server.
Data Storage
Local Data
VoxelBench stores the following locally in plugins/VoxelBench/:
config.yml: Configuration including authentication tokenreports/: Saved benchmark reports (JSON files)server-identity.yml: Server identity hashcertificates/: SSL certificates (if HTTPS monitoring is enabled)
Remote Data
Data sent to voxelbench.com includes only:
- Benchmark results and metrics
- Server hardware information (subject to anonymization level)
- Server identity hash
Rate Limiting
To prevent abuse:
- Local cooldown: 30 minutes between benchmarks (configurable)
- Backend rate limiting: Additional server-side protection
- Players with
voxelbench.start.forcepermission can bypass the local cooldown
Obfuscation
Production builds of VoxelBench are obfuscated to:
- Protect against casual reverse engineering
- Prevent extraction of API endpoints and authentication secrets
- Reduce JAR file size