Skip to main content
Browse guides

Permissions and data sharing

What is available now, what remains a design, and what you can turn off.

Important
Current behavior and future plans are different
Older versions of this page described a proposed permission system as if every part already worked. That was not clear enough. This page now separates observed public behavior, release statements, and planned architecture. A design document is not proof that a feature is running.

The public website

The website can offer optional diagnostic data sharing. Diagnostic data means information used to find errors or performance problems. It is off until you save a sharing choice, and the site should continue to work when it is off. You can reopen the choice and turn it off.

Signing in, buying something, or publishing content may require additional information for that specific action. The relevant screen must explain what it needs before you continue. See the privacy policy for the legal details.

The current LoA test build

Labyrinth of Apocalypse (LoA) is currently offered as an early Windows test build. The release is intended to run locally, meaning on your own computer. It has no copy-protection system and no operating-system-level anti-cheat driver. Those statements do not prove that every future feature will be offline or that every unfinished component has passed a privacy audit.

The safest practical control is still your operating system and network firewall. If a future release adds an online feature, its purpose, destination, data, and off switch must be explained before use.

What “cap” means in technical material

Some source documents use cap as shorthand for capability. In computing, a capability is a permission represented in code. The phrase sovereign-cap is an internal engineering term for such an authorization. It is not a claim that a machine, program, or tool is a sovereign person.

The current public test build does not provide a complete, verified visitor-facing control panel for every capability named in the architecture specifications. References to files, masks, grants, or revocation flows in those specifications describe implementation work or plans unless a release page explicitly marks them as available and they have been tested in that release.

The planned permission design

The design goal is simple: a networked action should require a narrow permission; the permission should identify what it allows; and withdrawing it should stop future use. Different actions should not be bundled into one vague agreement.

  • Local play should not silently become data sharing.
  • Joining another player should be separate from sharing diagnostic data.
  • Connecting an outside language model should be separate from either of those actions.
  • A record should show which permission was used, without exposing private content.

How to read stronger technical claims

Words such as default-deny, air-gapped, and revocable describe testable properties. They should be treated as verified only when the named release has matching tests and observable behavior. If the evidence is missing, the claim is a goal—not a guarantee.

Related pages