Security, freedom and the PlatinumSDK Runtime

This chapter is a three-part explanation of the security model: what protects you today, why the optional services exist, and where isolation is going. It distinguishes software behavior from a policy setting and from a future guarantee. For the current branch's exact implementations and checks, see security controls and the .

Security model diagrams

The following release diagrams show Runtime components and the default Winnitude services in green, and planned isolation in gray. PlatinumAuth and PlatinumSHL provide the cloud functions; their rollout and verification complete before publication. They are architecture illustrations, not product screenshots. Diagram sources and SVG exports can be reused with this manual.

Part I — Boundaries, identity and present protection

What we are defending

An application can be buggy, malicious, compromised after publication, or tricked by an imported document. A network peer can lie. A license server can be unavailable. A legitimate update changes files. The Runtime needs to distinguish these situations without making ordinary computing depend on a permanent central approval.

The assets include your files and credentials, other applications' private state, the identity of publishers, and the responsiveness of the machine. The host OS, drivers, trusted Runtime components and installed authority/key providers remain part of the trust boundary. An attacker who controls the host can replace executable code, observe plaintext, steal accessible keys, or defeat locally enforced checks. A signed hash stored beside the thing being checked is useful evidence, but not an independent defense against that attacker.

Permissions are about a specific operation

The shared capability model binds an authenticated participant to a resource, generation, operation, expiry and policy context. Reading a Live Object, editing it, subscribing to changes, invoking a command and exporting its contents are distinct rights. An object ID or filename identifies something; it does not authorize access. A UI button being enabled is not proof of permission.

The owning service checks authority when an operation takes effect. Revocation and generation checks prevent an old handle or delayed operation from becoming a permanent grant. Applications must use those checks at their actual command boundary. In-process reference checks alone do not authenticate a network client or prevent arbitrary native OS calls.

A permitted read has already disclosed the returned information. Revoking future reads cannot erase a screenshot, a copy made earlier, or a malicious recipient's memory. Sharing a resource with mixed-sensitive fields requires a properly restricted projection or separate resources; a generic whole-resource snapshot can reveal all its fields.

PLA, executable and native extension

PLA packages let a host validate declared contents and compatibility before interpreting scripts or loading modules. The intended release chain binds the complete runtime inventory, not just a friendly launcher icon. Native code inside a package still matters: static constructors, a loader, a plugin or a JIT can execute code before a superficially placed “startup check.” Admission must precede the protected execution boundary and preserve the checked bytes until use.

Current package hashing can establish consistency. A reviewed signer/provider and a trusted publication record are needed to establish publisher authenticity. A license grants a defined use, not goodness. Cloud registration cannot prove that a developer never wrote malware. Native EXEs retain the operating system privileges of their process unless an actual OS restriction is installed.

There is no general app-code container sandbox in this release branch. Lua library restrictions and broker-scoped IPC reduce particular risks; they do not contain every host vulnerability or native escape. Treat an unfamiliar native module as code you are choosing to run on your computer.

Default service provider: Winnitude

The Runtime’s default online provider is winnitude.ca. PlatinumSDK-powered PlatinumAuth supplies identity, sessions and key/account services; PlatinumSHL (the Software Licensing Hub) supplies licensing, application/release verification and the registered settings-integrity/recovery services. These are supplied services in the release configuration, not gaps users must fill themselves. Production mounts are /auth_s/ and /shl_s/; public demonstrations use separate _d mounts and never carry production authority. See deployment modes.

The services are being deployed and tested alongside the Runtime. This manual is released only after that deployment and acceptance work finishes. The separate tracks current evidence; the green release diagrams describe the intended accepted distribution. You can still choose an explicitly supported custom provider, use authentic offline information, or disable optional cloud features. Cloud opt-out prevents the optional handshake and service traffic rather than contacting Winnitude just to ask permission to stay offline.

Before using an online Winnitude provider, the Runtime verifies the expected HTTPS origin and a fresh, single-use OpenPGP signed challenge against Winnitude’s pinned company-authorized signing key. The signed transcript binds a random challenge, expected service/origin, audience, expiry and authenticated connection context. A stale, replayed, wrong-origin, wrong-key or wrong-channel response is rejected. A public key supplied only by the unverified endpoint cannot replace the trusted pin; key rotation/revocation uses the reviewed trust-update path.

Only the matching private-key holder can create a valid signature under the chosen cryptographic assumptions; the client checks it with the public key. This is signing and verification, rather than “encrypt with the private key and decrypt with the public key.” For confidentiality, OpenPGP encryption instead uses the recipient’s public key and recipient’s private decryption key. See OpenPGP’s encryption and signature definitions. HTTPS, channel/context binding and key verification work together: a signed challenge alone must not become a reusable token or prove the identity of an unrelated relaying connection.

Cryptography and keys

PlatinumCryptography is the common utility direction for generating/importing PGP keys and authorizing their use. The current branch includes a callable GPG-backed command utility. It delegates cryptographic operations to maintained GnuPG and its agent/pinentry rather than inventing a signature scheme. It is not yet a universally installed Runtime-owned graphical prompt or an operating-system credential vault.

A key fingerprint identifies a key. Check it through a trusted channel before pinning it; accepting whatever public key arrives beside a signature does not authenticate a publisher. A passphrase protects access to a private key, subject to the agent's unlock/cache policy and the security of the endpoint. Do not put passphrases in scripts, shell arguments, URLs, screenshots or logs. Cancellation must cancel the operation, and unrelated application content must not be allowed to impersonate the trusted authorizing prompt.

Signatures prove that a holder of the relevant key signed specific bytes. They do not prove those bytes are safe, secret, current, or the user's intended choice. Hashing, signing, encryption and authorization solve different problems.

Integrity of files that legitimately change

A configuration cannot be compared forever with its installation hash. Legitimate settings changes need new baselines, while silent changes need to be noticed. The new changed-file model registers a configuration/data identity and signs a domain-separated statement containing the account/machine/install identity, application, configuration, revision and SHA-256 digest.

The intended developer experience is to mark a configuration SecurityVerified and let the Runtime's registered settings/storage route maintain it. The current controller consumes explicit SecurityVerified configuration declarations and resolves them under an authorized root, then performs signed baseline and actual file operations. Automatic discovery across all app settings, system accounts and arbitrary host files is not installed. This is not a claim to monitor every file on the OS.

A newly signed pending revision is not yet the latest Hub-confirmed revision. Local pending bytes can be recognized as awaiting confirmation without being mislabeled as an attack. A signature on a remote receipt must be verified against the expected Hub key and exact identity/revision/digest. Replayed, mismatched or unrelated confirmations do not establish a baseline. Cloud opt-out permits a locally signed baseline with correspondingly lower independence from host compromise.

Hashing does not make all information “unrecoverable.” A hash of a low-entropy setting can be guessed by hashing possible values; stable identifiers and hashes can also permit correlation. Middle must disclose metadata sent to the configured service. Highest must separately disclose the actual contents retained for recovery. Do not upload passwords, private keys or account credential databases merely because “system files” were mentioned in a policy.

The native rooted-file controller currently targets Windows; other OSes fail explicitly until equivalent rooted IO is implemented. The policy/model layer is portable. A lifetime single-owner lock protects its signed state; stop a standalone watch before opening a second command instance.

The default interval in the added model is one hour; checks are also requested at a new session and after a clock rollback. The native controller persists signed state and its operational watch command performs actual timed checks. This is not an installed system scheduler: the Runtime host still needs to supervise it, preserve single-owner state and expose failures to the user. The accepted release config selects Winnitude’s services and pins their identity; the UI should show actual reachability/check results and offline state. Custom deployments must configure an equivalent reviewed provider and schedule.

An install GUID should survive ordinary updates. If a recognizable device/account returns with a different install GUID, show:

You seem to have just reinstalled PlatinumSDK. If this is not the case, please verify your system integrity.

This is a prompt to investigate. A privacy-conscious machine fingerprint can help correlate expected continuity; it cannot prove physical identity or defeat an attacker controlling the host. Reinstallation, restoring a backup and changing hardware are legitimate explanations. Do not silently erase previous evidence or treat the warning as a finding of malware.

On a mismatch, retain the suspicious data and the last accepted evidence, identify legitimate pending work, then offer explicit verification/recovery. Automatically blessing the current file defeats detection. Automatically overwriting current user work can cause data loss. The explicit verified-restore transition cancels a superseded pending change, rejects its late receipt, and keeps revision issuance monotonic. A failure after replacing bytes but before publishing signed state reports an uncertain recovery, not success. A restored settings file must not resurrect revoked credentials, obsolete grants or expired licenses; current authority still applies.

Part II — Choice, trust and privacy

Why add these measures?

A framework can leave all trust decisions to each app. That gives developers great freedom but makes every user repeat the same publisher, update, permission and recovery judgments. Shared verification and scoped operations aim to protect users from tampering and developers from impersonation, corrupted distributions and unauthorized capability use.

These measures introduce real trade-offs. A central service sees requests and can be unavailable, compromised, censored or governed by policies you reject. You may object for political, personal, privacy or philosophical reasons. You may want to build a small program, put it on a BBS or file-sharing site, and run it without a vendor account or online registration. Platinum's intended runtime trust controls should preserve that choice.

Optional cloud checks, reporting and extra verification are opt-out, with explicit effective settings. Turning one off must not quietly enable an unrelated upload. A separate developer/product license may still impose its own terms; changing a runtime security preference does not manufacture an entitlement or bypass another person's access controls.

Baseline parser bounds, current operation permissions and cryptographic protocol validity are not sliders that one application can silently lower. Your freedom to trust an unverified local app does not give that app rights to somebody else's resource or force a remote server to accept it. This is the distinction between accepting risk on your own machine and changing another party's policy.

Offline does not have to mean blind

Authentic bundled/imported definitions and retained exact-build verification can support offline decisions. They tell you what was known and signed at a particular point. They cannot tell you about a later revocation or vulnerability you have not received. “Previously verified” must remain separate from “currently allowed” and “currently licensed.”

The intended all-online opt-out covers automatic DNS/discovery, login refresh, license checks, definitions feeds, telemetry and retries in the participating adapters. An explicit one-shot Verify/Download must be scoped to its exact destination and action; it must not flip the Runtime into a globally online mode. The setting cannot restrain an arbitrary native app making its own OS socket calls until OS-level mediation exists.

To run an unregistered application, use the host's explicit trust/exception workflow, inspect its scope, and retain a record tied to its exact identity/build. Where policy permits, you can temporarily reduce verification, install and trust that app, then restore stronger defaults. Stronger defaults do not retroactively certify the exception, and an update should not inherit a blanket exemption for unrelated new native code. The current library branch does not supply a completed installer/Hub exception screen; its availability is a release gate.

Disabling independent verification increases the risk of severe malware events. Today that risk includes ordinary host compromise by native code, because full containment is still planned. The system should explain the consequence without making local ownership of your machine difficult.

Tunnel encryption settings

Normal tunnels should encrypt and authenticate traffic transparently. Ordinary text, commands, credentials and modest state updates rarely benefit from exposing their contents. Encryption has real CPU, buffering and protocol costs, however; moving entire game worlds or other large, low-density data streams may justify an explicit application-specific optimization after measurement.

The model includes Force Encryption on All Tunnels at system level and per-application tunnel policies. The system force setting is a floor: an app cannot turn it off with a request. A force-encrypted request requires encryption. A force-unencrypted request is a negotiation request, never an instruction to override the other endpoint.

A game server may refuse encrypted sessions for measured deployment reasons. It should publish that limitation; users with forced encryption cannot connect until policy changes at an endpoint. Conversely, a privacy-conscious server may refuse plaintext entirely. No silent fallback is acceptable. Compatibility with another SDK tunnel adapter requires agreement on the protocol and verified channel, not merely a matching flag.

The new negotiation code selects a permitted mode and validates host-supplied transport facts, and the core admission path applies it before its existing network-profile checks. Current profiles still reject plaintext; a compatible high-throughput plaintext transport is not delivered by this branch. Negotiation does not itself implement encryption or a network connection. Actual adapters must enforce the result and authenticate the policy exchange to prevent downgrade. TLS 1.3 is an example of a standardized authenticated transport; it does not automatically provide application-to-application end-to-end secrecy through every service.

Properly authenticated end-to-end encryption is intended to keep an intermediate gateway from reading an app-to-app tunnel. This cannot be promised as “no way to MITM”: compromised endpoints, a stolen key, a wrongly trusted key/certificate or a deliberately decrypting proxy changes the boundary. Traffic timing, sizes and destinations may remain visible even when contents are secret. If an authoritative game server processes plaintext game state, it can see that state.

Part III — Planned isolation and the operating-system direction

Small, separate environments

Full application sandboxing/containerization is planned, with a default-enabled, user-opt-out policy direction. It is not enforced by the present framework. The design takes inspiration from Qubes' compartmentalization and from Plan 9's composable namespaces: expose only a useful resource/interface, instead of granting an app ambient access to everything on the host.

The target application environment has a shared minimal Linux base image, immutable from outside the guest, with transient writable state. The ambition is a very small RAM footprint and shared read-only backing data. “A few megabytes” is a research target, not a measured minimum or a release requirement. A guest changing its internal mount to read-write should still be unable to modify a backing image that the host/hypervisor exposes read-only. That depends on actual host ACLs, handles, device configuration and hypervisor enforcement—not a read-only flag stored inside the guest.

Apps would not receive ambient network devices or direct host filesystem access. Scope-based IPC permissions would expand to brokered native OS services and APIs. Device/driver access is an explicit, difficult boundary; granting raw hardware access can weaken isolation. Container images, writable overlays, memory/CPU quotas, parsers and GPU interfaces all need their own hostile-code tests.

A Runtime broker and network gateway

The Runtime is intended to be a secured, independently checked broker in its own containment boundary. Specialized, immutable service environments would mediate outside access; only a narrowly authorized updater would replace their images. Applications would reach the outside through their permitted Runtime operations. A Networking Gateway VM would carry traffic for the relevant app environments, similar to a policy-controlled gateway; describing it as “NAT” alone does not specify its authorization or encryption.

Independent local/remote integrity verification would scale with user configuration. Local stored keys/hashes give offline control, but a sufficiently powerful host attacker can replace them. Remote verification adds an independent source of evidence and new trust/privacy dependencies. Self-hashing from inside a compromised process is not proof that the process is honest.

The proposed optional traffic inspector would use a compatible open-source proxy/backend, bounded container-to-container channels, and a dedicated viewer rather than expose a browser dashboard port by default. It may inspect traffic the user explicitly authorizes for decryption. It must not secretly break end-to-end encryption. An end-to-end tunnel can remain opaque to the gateway; decryption needs endpoint/key cooperation or an explicitly different trust configuration.

Heuristic traffic analysis could flag unexpected destinations, timing or volumes. It will have false positives and false negatives and cannot prove that an encrypted flow is harmless. Rules, retention, captured personal data, proxy credentials, allowed destinations and remote-dashboard exposure all require clear settings. This inspector, its auto-configuration and the Gateway VM remain planned; no backend has been silently installed by this work.

What success would mean

The long-term goal is an operating system and ecosystem that does what you ask, when you ask, while keeping a compromised application from trivially owning the entire machine. The path is small boundaries, reviewed protocols, explicit authority, recoverable state and independent verification—not a promise of cryptographically bulletproof software. Cryptography cannot remove bugs in the host, drivers, prompts, update service or keys.

Before advertising containment, demonstrate failed direct socket/filesystem/process probes, malicious parser/worker behavior, resource exhaustion isolation, revocation under load, update/rollback resistance, and recovery after crashes on every supported OS. Independent review and reproducible evidence matter more than the number of security switches. Users who opt out should see the actual reduced boundary, and users who opt in should receive a protection that is actually enforced.