This post was partially generated with the assistance of AI. I have carefully reviewed, edited, and refined the content to ensure its accuracy and alignment with my intended message.
This could be implemented using a certificate based system. Under normal circumstances, Space Station 14 requires online authentication when connecting. However, for situations where an internet connection is nonexistent, a fallback system similar to PGP/GPG could be utilized for offline authentication.
By default, the client should be configured to trust Wizden signed certificates. These certificates would validate the integrity and authenticity of files, such as replays or custom content bundles. This system should also allow third party certificates to be added, however those certificates should be treated similarly to third party hubs. Untrusted by default unless the user explicitly trusts it.
Users should be explicitly and heavily warned that sideloading custom certificates could compromise their client’s security. This safeguard is to make sure that only advanced users deliberately alter these settings, reducing the risk of unintentional exposure to malicious content.
At the end of each round, the server should perform an internal security check on the replay file. If these checks are successful, the server will automatically sign the replay with a trusted Wizden certificate.
If the security checks fail, the replay should be deleted to prevent loading corrupted or tampered files.
If a replay or content bundle lacks a valid signature, the client should display a generic notification prompting the user to connect to the internet for authentication. Avoiding detailed error messages prevents users from attempting workarounds that might compromise their security.
Advanced users who choose to interact with the signature system should be allowed to do so with caution, as improper usage, such as sideloading malicious certificates, will compromise their client.
If a replay is authenticated online, the client should self sign it for offline use. This makes sure that replays previously authenticated by wizden can be accessed without an internet connection, even after revocation.
In the event a certificate is compromised, the certificate trust server should send revocation signatures to clients. Signed by the affected certificate. These signatures would be automatically downloaded next time the client connects to the internet, revoking trust in older compromised materials. Revocation signatures should never be deleted. A new signature can be sent to clients via another update from the trust server, or through the discouraged custom method.
Wizden would likely need to issue a public announcement when such event occurs, including instructions for manual self-signing through the in-game console to re-authenticate trusted replays.
Certificates should only be used when:
The user lacks an internet connection or the server is unavailable.
The file being loaded (replay, custom content bundle) requires offline validation.
If these conditions aren’t met, the client should default to online authentication or refuse to load the file entirely.
By requiring valid and trusted signatures for offline files, this system makes sure that only trusted content is loaded, preserving the users security.
Users without internet access can still access trusted replays and content bundles seamlessly.
Advanced users retain the ability to manage certificates, while casual users remain shielded from unnecessary complexity.
Third party servers are still able to instruct users to trust their own certificates. Additionally, wizden could, manually at its own discretion, use the primary wizden signature to sign a third party certificate, thereby making it trusted. Allowing wizden to act as a root certificate authority. Additionally, it could be possible to automatically load other third party trusted certificates to the client through a certificate trust server. However, the primary wizden certificate can never be changed without a direct update to the client. The primary root trust certificate can only be revoked. Never modified or replaced by the certificate trust server. Clients should refuse any attempt to modify the primary trust certificate, and only accept revocation requests. The primary root trust certificate can only be changed through an update to the client itself. Other third party certificates may be changed via the trust server.
The private key for third party certificates should never be known to wizden. And changing the third party certificate on the primary trust server should both require approval from wizden, and the third party.
However wizden can, at any time, delete and revoke third party certificates from its own server. Which will force the necessity of sideloading.
In the event a client has already sideloaded a third party certificate, and it becomes trusted by a certificate trust server that the user trusts, than as long as the sideloaded certificate identifier is an exact match to the new trusted copy, the old sideloaded certificate should be replaced by the trusted copy.
Sideloaded certificates are immune to revocation, unless they have been replaced by a trusted copy, than revoked.
Wizden cannot blacklist a sideloaded certificate. As that would otherwise infringe on the open source nature of this game. Third parties are free to both make their own trust servers, the same way they may opt to use a third party hub.
Wizden can still force servers and users off from its own infrastructure, however those users retain the ability to switch to a third party provider. And sideload third party certificates (which, I expect third party servers will be relying on this feature if they aren’t able to get signed by wizden)
Let me know your thoughts about this <: