Collect less. Explain the rest.

1. Scope of this draft

This engineering draft describes data boundaries planned for the Sky-Boost private alpha website, account, Windows client, control plane, and VPN node. It will be replaced or supplemented by a formally reviewed privacy notice before public accounts or payments are enabled.

2. Information the service may need

To operate an invited account and its devices, the control plane may process an account identifier, device identifier, public WireGuard key, app version, node selection, short-lived tunnel lease state, and subscription entitlement state. Operational events may include authentication, device registration, lease issuance, revocation, and administrative security actions.

Route selection can use aggregate measurements such as round-trip time, jitter, packet loss, connection success, and recent stability. Metrics should use low-cardinality labels and should not contain access tokens or private keys.

3. What is outside the intended telemetry

• WireGuard private keys, which are generated on the client device;
• packet payload contents;
• payment-card data in Sky-Boost application logs;
• access tokens and credentials;
• game files, game memory, or injected process data;
• full DNS query contents outside a separately approved, consented diagnostic.

Sky-Boost does not use the marketing phrase “no logs” in this alpha. A public claim must match implemented code, operational policy, retention settings, and independent review.

4. Diagnostics and support

A support bundle must require explicit user consent before upload. The intended bundle contains app and service versions, a redacted operating-system and network summary, redacted route-table excerpts, DNS configuration, WireGuard handshake timestamps and counters, error codes, and aggregate probe results.

The diagnostic flow must show what will be included, exclude secrets by construction, and let the user cancel before transmission.

5. Retention and access

Final retention periods are not yet approved. Before public launch, each stored category must have a documented purpose, owner, access boundary, deletion schedule, and incident-response procedure. Administrative access must be auditable and limited to operational need.

6. Your controls

The planned account experience includes device review and revocation, logout, diagnostic consent, and an account-support path. Applicable access, correction, deletion, objection, and portability procedures will be documented with the final legal entity and privacy contact.

7. Contact status

A monitored privacy contact and the identity of the responsible legal entity will be published before public registration. Until then, this page should be read as an implementation commitment under review, not a completed consumer privacy notice.