Privacy & Security

Data Anonymization

When 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:

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:

Still keeps CPU name, RAM amount, Java version, and OS name for basic comparison.

What is Always Sent

Regardless of anonymization level, reports include:

• Benchmark results: TPS, MSPT, throughput, and all test metrics
• Hardware: CPU name, vendor, cores and threads; RAM amount; primary disk type and size
• Software: OS name, Java version, JVM memory settings, server software and version, VoxelBench version, plugin count
• Server settings that affect scores: for example view and simulation distance, spawn limits and spawn rates, compared to their defaults, and the world difficulty
• Hybrid servers: whether the server is a hybrid, its mod loader and mod count
• Hosting environment: the detected hosting tier and provider, the signals that led to it, the allocated heap and the processor count (see Configuration)

Authentication Security

Challenge-Response System

When submitting benchmarks, VoxelBench uses a challenge-response authentication system:

1. The plugin requests a one-time challenge token from the backend
2. The challenge has a 5-minute TTL (time-to-live)
3. The plugin computes an HMAC-SHA256 signature of the challenge, the server ID, a timestamp and the plugin JAR hash, with a secret embedded in official builds
4. The report is submitted together with that signature
5. The backend verifies the signature before accepting the report

The backend also checks the plugin JAR hash against the builds it knows, so reports from modified or unofficial builds are refused.

This prevents:

• Replay attacks: Each challenge can only be used once
• Spoofing: Only official plugin builds can submit reports

The signature covers the challenge and the server identity, not the content of the report.

Server Identity

Each server has an identity hash: a SHA-256 hash computed once from:

• The MAC address of the first network interface that has one
• The hostname
• The serial number of the first disk

It is stored in plugins/VoxelBench/identity.yml and reused afterwards. This hash is used to track your server across submissions without revealing the underlying hardware identifiers.

Token Authentication

When linked to a VoxelBench account (via /bench link), the plugin sends an authentication token with its 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 the authentication token and the monitoring password hash
• identity.yml: Server identity hash
• reports/: Saved reports (JSON files), and in reports/profiles/ the profiler output (JSON, the raw .jfr if kept, and a small record of each profile you uploaded or shared; a shared profile's record holds the token that deletes its public link, and stays until the link has expired)
• custom_benchmarks/: Custom benchmark and stress profiles
• reports/memory/: Heap summaries from /bench memory summary and dump analyses from /bench memory analyze (class, field and plugin names, sizes and counts; nothing taken from the objects themselves), and a small record of each report you uploaded or shared (a shared report's record holds the token that deletes its public link, and stays until the link has expired)
• heapdumps/: Full heap dumps from /bench memory dump, only readable by the server's account. A heap dump contains everything the server had in memory, including the authentication token, plugins' passwords and players' data: never share it, and keep this folder out of shared folders and backups
• stress-warmstart.yml: Last stable stress limit values
• lang/: Language files
• certificates/: SSL certificates (if HTTPS monitoring is enabled)

Remote Data

Data sent to voxelbench.com includes:

• Benchmark, test and stress limit results and metrics
• Server hardware and software information, subject to the anonymization level (see above)
• The server identity hash

When you run /bench profile upload <id>, that one profile (a JSON file naming your plugins, their sampled methods, thread names, server and Java versions, OS and CPU count) goes at once, as it is, to the account the server is linked to; add preview to see this before anything is sent, then confirm sends exactly what was shown. Profiles are never uploaded otherwise.

When you run /bench profile share <id>, a cleaned copy of that one profile is published behind a public, unlisted link that anyone who has it can open, for 7 days, without any account. Before it leaves, VoxelBench removes from thread, method and class-loader names the IP addresses, host names, URLs, e-mail addresses, file paths, UUIDs, long hexadecimal strings, and the names of online players, non-default worlds, the OS user, the machine and the server folder; fields it does not know to be safe are not copied at all. It is published at once; add preview first to see a notice that says the link is public and lists what the copy contains and what was removed, then confirm publishes exactly that copy. The request is signed like benchmark reports (only official builds can share) and carries the server identity hash, which voxelbench.com uses only to limit abuse and never shows or links to the shared profile. /bench profile unshare <id> deletes the link before it expires, even after you deleted the profile locally.

When you run /bench memory upload <id>, that one heap summary or dump analysis (a JSON file naming your plugins, classes and, for an analysis, fields, with sizes and counts, the server and Java versions, OS, CPU count and the machine's memory figures) goes, as it is, to the account the server is linked to; add preview to see this before anything is sent.

When you run /bench memory share <id>, a cleaned copy of that one report is published behind a public, unlisted link that anyone who has it can open, for 7 days, without any account. Before it leaves, VoxelBench drops the fields it does not know to be safe and the support notes, truncates the date to the hour in UTC (no time zone), removes the machine's free memory and container limit and rounds heap sizes to 64 MB, and removes from class, field and plugin names the IP addresses, URLs, e-mail addresses, file paths, UUIDs, long hexadecimal strings, script names, and the names of online players, non-default worlds, the OS user, the machine and the server folder. preview says the link is public and lists what the copy contains. The request is signed like benchmark reports (only official builds can share) and carries the server identity hash, used only to limit abuse. /bench memory unshare <id> deletes the link before it expires, even after you deleted the report locally.

Summaries and analyses leave only on those commands (or the matching menu buttons), one at a time, never during a scored run. A heap dump is never sent: no command, button, automatic path, report or monitoring field carries a .hprof, and the sending code only reads the reports folder. A dump analysis runs in a separate Java process on your machine that opens no network connection.

When you enable remote monitoring for a linked server, VoxelBench also sends periodic metric snapshots and detected events; /bench monitor remote on lists the event sources that are on before anything is sent. Snapshots contain server figures only (TPS, tick times, memory, CPU, GC, counts, world names, average ping), no player name. When you turn on the LiteBans integration (off by default), moderation events include the player name and the operator, and the reason only if you set include-reason: true.

Rate Limiting

To prevent abuse:

• Local cooldown: 30 minutes between benchmarks (configurable)
• Backend rate limiting: Additional server-side protection
• Players with voxelbench.start.force permission can bypass the local cooldown

Obfuscation

Production builds of VoxelBench are obfuscated with ProGuard to:

• Protect against casual reverse engineering
• Make it harder to extract API endpoints and authentication secrets
• Reduce JAR file size