Skip to content

Guest ROM policy: signed official-release prohibitions and user content responsibility #140

Description

@EriArk

Parent: #136

Current owner decision: official prohibitions and user responsibility

Maintain encrypted signed prohibition rules for known official releases, regions and revisions. Do not catalogue ROM hacks/transformed images, infer their ancestry, or require automatic classification of unknown files as hack/homebrew/publisher-authorized content. There is no per-homebrew Approved list and no per-file verified-licence/provenance prerequisite for user-supplied transmissions.

Users undertake responsibility for having the rights to their files and transmissions under the proposed agreement. Unauthorized transmission and modifying content to evade restrictions are prohibited uses. Unknown is not automatically forbidden; no matching prohibition is not legal clearance. Valid policy, consent, exact runtime/format compatibility, integrity and session controls are independent mandatory gates. Operator-curated OddCrate publications still require rights review.

The agreement is currently a draft; this policy decision does not claim immunity, effective legal terms or implemented transfer behaviour. See full product contract.

First mandatory seed: Nintendo official releases

The first real private catalogue must contain verified Nintendo-owned/published first-party official games across relevant supported platforms, with identifiable editions/regions/revisions. Do not equate games for Nintendo hardware with Nintendo-owned games. Third-party and homebrew content is not blocked solely by platform. Joint ownership/publication needs an explicit reviewed scope.

Known official content must not evade its applicable rule by filename, emulator/core or platform-alias changes. Supported container parsing may identify an exact official payload; it does not require recognizing every hack, transformed image or derivative. Filename alone is not reliable identity. Preserve the documented matching boundary and do not guess ownership of an unknown file.

Artifact scope and model

  • One versioned encrypted policy artifact per canonical platform/content family, including modern platforms with an implemented provisioning route; platform age is not an eligibility cutoff.
  • Optional runtime overlays may narrow a rule, never bypass the platform prohibition.
  • Use the existing platform/runtime registry for aliases; distinguish BIOS/firmware and multipart sets, which cannot gain permission through a broad platform match.
  • Store official-build hashes/exact-payload identities, region/revision, reviewed official-title/rights-owner scope, specific documented exceptions, schema/sequence, integrity and supported IDs.
  • Broad title/owner rules must resolve to verified official identities within documented boundaries, not fuzzy classification of modified content.
  • A specific rights-holder permission may justify a reviewed policy exception; there is no automatic receiver-supplied licence assertion overriding a deny.

Cryptography and privacy

  • Encrypt payloads to avoid publishing a convenient plaintext catalogue. This is limited confidentiality because the client ultimately reads the policy; do not claim secure DRM against the device owner.
  • Authenticate each artifact or its parent manifest with a digital signature and integrity hash.
  • Private editor source/binary/project, real plaintext policy/evidence, signing keys, credentials and correspondence must never enter any GitHub repository, attachments, public releases or client builds. This includes prototypes.
  • Public material is limited to non-secret schemas, loader/verifier, verification public keys, synthetic fixtures and compiled signed/encrypted policies.
  • Missing, damaged, unsigned, unsupported, tampered or insufficiently current policy fails closed for guest transfer, not normal local play. Unknown content under a valid policy is a different state and is not automatically denied.

Distribution and freshness

Policies are a component of ordinary TrainerOS Software S updates (#153/#154), independent of Linux image I or external host H. No standalone list updater, polling client, public policy-editing API or separate download button.

The Software manifest #119 binds policy schema/sequence/hashes. Prepared image and supported SteamOS/Bazzite installations use the same compatible S policy identity; a fresh image may embed a baseline S. A policy-only S point release changes only policies/signatures/release metadata, leaving app/emulator/core binaries and image/host unchanged. It does not require an OS update or reboot unless an actual loader constraint requires a documented restart.

Validate before atomic activation and preserve Software last-known-good recovery. Image rollback #71 remains separate. Keep a monotonic last-seen policy revision outside replaceable S/I slots where feasible; rollback must not silently restore revoked transfer. Disable guest transfer until sufficiently current signed policy is restored if needed. A device offline or not yet updated cannot know new prohibitions instantly.

Enforcement and private authoring

The sender evaluates the exact proposed payload and effective policy, and rechecks before bytes leave. Bind authorization to accepted participants/session/content/runtime. Receiver verifies identity/hash and never indexes temporary ROMs. Peer consent does not bypass a prohibition.

This governs guest transmission only: no blocking ordinary local play, deleting personal ROMs, rewriting saves, or uploading/scanning collections for policy enforcement. The owner's local ROM Policy Studio #142 maintains evidence/history, exports signed encrypted artifacts and hands them to the ordinary Software pipeline #143. Private source/evidence stays out of every GitHub repository.

Acceptance

  • First real policy blocks known Nintendo first-party official releases, not every game on Nintendo hardware.
  • Official regions/revisions/aliases/core changes are covered within explicit matching rules; no hack/transformed-image catalogue or universal lineage classifier is required.
  • A technically supported unknown file is not rejected solely for absent per-file licence evidence; absence from the list is never described as legal clearance.
  • Consent, integrity, runtime/format/session isolation and revocation remain independently required; real transmission fixtures have known permission.
  • Valid signed encrypted policies load offline per platform/family; missing/tampered/stale policies disable guest transfer only.
  • Same policy identity installs through ordinary S on image/SteamOS/Bazzite; policy-only release changes no unrelated binaries or host/image.
  • Signature, known-official matching, alias/core bypass, unknown-file handling, sequence/rollback floor and atomic activation have public synthetic tests without ROM bytes or real plaintext policy.
  • Software/image rollback remains available but cannot silently re-enable revoked transfer; no instant offline takedown promise.
  • Zero private editor, plaintext rules, credentials or signing secrets in any GitHub repo/public artifact.

Related: #136, #137, #138, #139, #141, #142, #143, #70, #71, #118, #119, #153, #154.

Activity

  1. changed the title [-]Content policy: exact-title rights catalog for temporary retro ROM sharing[/-] [+]Guest ROM policy: encrypted platform deny-rules, rights basis and signed release bundles[/+] on Oct 7, 2026
  2. changed the title [-]Guest ROM policy: encrypted platform deny-rules, rights basis and signed release bundles[/-] [+]Guest ROM policy: signed official-release prohibitions and user content responsibility[/+] on Oct 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions