Security & privacy.

How Nebulah keeps console access local, protects private data and separates identity checks from trust claims.

Local console access.

Nebulah Link uses a local Windows bridge and trusted LAN. The public website is not a cloud-to-console service.

Separate private reads.

CPU-key display requires explicit separate confirmation and is transient. It is not normal telemetry or persistent data.

No proprietary redistribution.

Nebulah does not ship Microsoft XDK binaries/headers, console keys, copyrighted game content or extracted dashboard assets.

Pairing & sessions

Pairing token: used to establish local bridge access; do not expose it through the public site.
Trial 5 browser session: refresh-safe session cookie with a 300-second user-idle expiry. Background polling does not extend idle time.
Bridge restart: invalidates previous browser sessions. Expiry signs the browser out without stopping the console.
LAN HTTP: Link is intended for a trusted private network; do not port-forward it or route it through nebulah.app.

Verification boundaries

Hash ≠ trust

Measured SHA-256 identity does not automatically approve a build. Candidate proposals remain untrusted until separate review.

Metadata ≠ verification

Title names and cover artwork can improve presentation but never turn an unknown XEX green.

Structure ≠ compatibility

A structurally valid XEX can still fail to launch or behave differently on a specific console/setup.

Public demo safety

The interactive website demo uses simulated local state only. It must never contain a real pairing token, CPU key, console identifier or route to a live Neighborhood bridge.