# Executable UGC Is a Software Supply Chain ## A capability and rollout contract for Steam-style mod ecosystems Author: Jason Doyle Drafted: 22 September 2026 > Disclosure: These views are my own and do not represent any current or > former employer. This paper uses public developer announcements, platform > documentation, technical standards and published research. It does not > describe non-public Steam architecture or moderation systems. > Prototype status: This draft defines a proposed UGC Execution Contract and a > reproducible prototype methodology. The reference runtime and benchmark have > not yet been implemented, and no performance or security result is claimed. ## Executive summary Steam Workshop makes user-created content easy to publish, discover and install. The same distribution path can carry a texture, a saved game or a compiled assembly. Those artifacts do not present the same risk after installation. The difference is authority. An image is processed by a decoder. A script may call game APIs. A managed assembly can run with the authority exposed by its host process. A native extension can inherit almost everything the game can reach. Calling all of them user-generated content describes who supplied the files and says little about what the files may do. The distinction became concrete for People Playground twice during 2026. On 1 February, the developer disabled its Workshop after a malicious addon spread by replacing users' own uploaded mods. A later announcement said the malware reset preferences, deleted contraptions and reset achievements. The developer then added a game-side content-hash approval gate for changed installed contents.\[1\]\[2\]\[3\] On 22 September, the developer announced that the Workshop had again been disabled. The initial warning said the new malware appeared able to delete personal data, alter Steam configuration and cloud data, publish identifiable information and republish itself through Workshop. The same warning stated that the investigation was incomplete. Those effects should therefore be attributed to the developer's assessment rather than treated as an independently verified forensic report.\[4\] VPet-Simulator published a separate response on 20 September after copied versions of popular mods were uploaded with malware. Its developers added hash-based integrity checks, required executable plugins to provide matching source links and restricted code-plugin uploads from accounts with less than ten hours in the game. They also moved uploads through an in-game tool that binds mod names and checks DLL content.\[5\] tModLoader had already introduced a Valve-partnered approval queue by February 2026. Its developers described the purpose directly: malicious mods and updates should be caught before reaching users.\[6\] These responses are useful but fragmented. They cover moderation, publisher friction and artifact checks. People Playground also added local approval for changed content. Each game still has to decide what installed code may do, how an update should change that authority and what happens when a dangerous release is already present on player machines. Valve's public Workshop documentation explains the platform boundary. Steam stores and distributes item files. A game obtains the installed directory and recognises the content in whatever way makes sense for that title.\[7\] The public API can represent dependencies through collection membership or soft relationships. The application still decides whether the installed content is usable.\[8\] That boundary gives games valuable freedom. It also means the distribution platform generally cannot determine runtime authority from file identity alone. A Workshop item can be a map in one game and an executable plugin in another. This paper argues for a separate contract for executable UGC: > Executable UGC should be distributed as an immutable software release, > accompanied by signed, monotonically versioned authorisation metadata. The > immutable release binds the artifact, requested capabilities, exact > dependency closure, compatibility and persistent-state schema. The current > authorisation record carries rollout state and determines whether that > release digest may execute. The proposal is a UGC Execution Contract shared by the platform and the game. The platform owns release identity, publisher authority, artifact digests, dependency resolution, rollout and revocation. The game or plugin runtime owns the execution sandbox, resource limits and mediated game APIs. Both layers must agree on the same release digest before code runs. The contract separates three questions: 1. Who was authorised to publish the release? 2. Which exact artifact and dependency closure were admitted? 3. What authority may that artifact exercise now? A signature answers the first question when the key and namespace are trustworthy. A digest answers the second for one artifact. Neither answer limits filesystem access, network access or calls into the game. The proposal also treats updates as deployments. A new artifact should enter a test ring before wider exposure. Capability expansion should require a new decision because the trust relationship has changed. Pausing distribution, rolling back an update and denying execution of an installed digest are different operations and need separate controls. WebAssembly provides one practical runtime for the low-authority tier. Core WebAssembly isolates linear memory and permits outside interaction only through linked interfaces.\[9\] WASI follows a capability model for filesystem and other resources.\[10\] Wasmtime documents both the strength and the limits of that arrangement. The host decides which imports mean what, and runtime or compiler defects remain possible.\[11\]\[12\] Managed and native extensions need separate treatment. A .NET AssemblyLoadContext supports dependency loading and unloading but Microsoft does not describe it as a hostile-code sandbox.\[15\] Native modules loaded inside the game process inherit the process boundary. They may require an operating-system sandbox and versioned RPC, or a clearly labelled high-risk tier. The proposed prototype would implement one narrow vertical slice using Wasmtime. It would package a useful configuration mod, a network-enabled mod and malicious fixtures. It would test filesystem escape, denied process creation, resource exhaustion, artifact substitution, dependency substitution and revocation. Performance work would separate validation, compilation, instantiation and steady-state execution. No universal WebAssembly overhead would be inferred from one workload. Capability systems, secure update frameworks and staged releases are already established. The proposed contribution is their specific synthesis for Steam-style executable UGC: one immutable release binds artifact identity, exact dependency closure, requested authority, compatibility and persistent-state schema, while separate signed status metadata carries rollout and current launch authorisation for runtime verification. ## 1. Executable UGC is a separate distribution class ### 1.1 One label covers different authority User-generated content describes origin. Security decisions need an execution class. Consider these files: ```text texture.png map.dat savegame.json commands.lua plugin.dll native-extension.dll ``` All can be created by a player and delivered through a Workshop-style platform. Their authority differs after the game opens them. | Class | Typical processing model | Main authority question | | --- | --- | --- | | Assets and data | Parsed by game code | Can malformed or oversized data exploit the parser or exhaust resources? | | Declarative commands | Interpreted by a bounded game language | Which game-state operations exist, and how much work can one artifact request? | | Script VM | Executed against host APIs | Which files, network endpoints and game objects can the script access? | | Managed plugin | Loaded by a language runtime | Does the loader isolate dependencies only, or does it restrict operating-system authority? | | WebAssembly component | Executed through explicit imports | Are the imports narrow, resource-bounded and implemented without confused-deputy paths? | | Native extension | Loaded as machine code | Is it isolated from the game process, credentials and player files? | Data-only content is lower authority, not zero risk. Image decoders, archive readers and shader compilers remain attack surfaces. A map can request enough objects to exhaust memory. A declarative command language can expose dangerous game operations. The architectural threshold appears when content receives general computation and broad host APIs. At that point the release resembles a dependency supplied by a third party and updated outside the game's ordinary release process. ### 1.2 Workshop distributes files and games decide what they mean Steam Workshop is documented as storage, discovery and distribution for content associated with a game or application.\[7\] A customer subscribes to an item. Steam downloads the item files. The game calls `GetItemInstallInfo` to obtain the local folder, then reads the data in the way defined by its integration.\[7\]\[8\] The public API supports item creation, content updates and metadata. It also supports dependencies between Workshop items. When the parent is a collection, the child becomes part of that collection. Other item-to-item dependencies are soft relationships displayed on the web and readable through the API. For an application dependency, Valve states directly that the application decides whether the item can actually be used.\[8\] Steam also supports multiple Workshop item versions whose validity is expressed as minimum and maximum Steam beta branches through `SetRequiredGameVersions`, `GetNumSupportedGameVersions` and `GetSupportedGameVersionData`.\[8\] This is a useful compatibility-selection primitive. It is not an artifact-provenance or capability-enforcement contract. That design does not imply an absence of internal security controls. It shows what the public integration contract exposes: content, metadata, dependency relationships, install state and beta-branch compatibility. It does not define a cross-game permission model for code inside the item. The game therefore owns the final authority boundary today. It decides whether to parse data, run a script, load a managed assembly or load native code. A platform can review or remove an item, but runtime mediation requires cooperation from the game or a shared plugin runtime. This is why a capability declaration cannot be a metadata-only feature. A manifest that says `network: false` has no value if the loaded code can call the operating system directly. ### 1.3 Executable UGC behaves like a dependency An executable mod enters the player's software system without being compiled into the original game release. It has a publisher, version history and update channel. It may also depend on other mods. Those properties match familiar software supply-chain concerns. The dependency can change after the player subscribes. An established item may receive a malicious update after account compromise or project transfer. A benign update may add a new transitive dependency. The artifact on disk may differ from the release that was reviewed. A game update can also change the meaning of a formerly safe host API. Security therefore needs a release identity stronger than a mutable item ID: ```text platform game item release sequence artifact digest ``` The item remains useful for discovery and subscription. The digest identifies the bytes admitted for execution. Dependencies need the same identity. Resolving `mod-a depends on mod-b` to a mutable item leaves the executable closure open to later change. A launch record should identify the exact release of every transitive dependency. ## 2. The 2026 incidents expose a repeated failure mode ### 2.1 People Playground in February On 1 February 2026, the developer of People Playground disabled the Workshop after a malicious addon spread through uploaded mods. The first announcement said the exact behaviour was still being investigated. It instructed players to update the game, remove downloaded mods and inspect their own uploads for unexpected changes.\[1\] The same announcement was later updated with a narrower account. The developer said the malware removed People Playground files and replaced user-created mods with itself. The latest game patch prevented that behaviour, while the Workshop remained disabled.\[1\] On 3 February, a separate security update said the mod had spread by uploading itself over users' own Workshop uploads. It reset preferences, deleted saved contraptions and reset achievements. The developer said no other effects or propagation paths were known at that point.\[2\] The Workshop later reopened. The 6 February announcement recorded two changes with direct architectural significance: - mods no longer updated automatically; - changed mod contents required manual approval. The same release also made the trust cache take the mod content hash into account.\[3\] These controls move the decision from subscription time to release time. A player who once trusted an item is asked again when its executable contents change. The response also illustrates a limit. Local approval tells the player that bytes changed. It does not explain whether the release gained filesystem or Workshop publishing authority, because that authority is not represented as a portable contract. ### 2.2 The September recurrence On 22 September, the People Playground developer published another warning after the Workshop had been disabled. The developer wrote that the investigation was not complete and described the apparent effects with that qualification.\[4\] The warning said the malware appeared able to: - delete a considerable amount of personal data; - alter Steam configuration and cloud data; - publish Discord identity and other information to Workshop; - publish itself through Workshop. This is not a forensic report. It is an urgent developer warning issued during an active incident. The paper uses it as evidence of the responsibility boundary and the potential blast radius. It does not treat each listed effect as independently confirmed. The recurrence matters because the February changes addressed one known propagation route. A content-hash trust cache and manual approval for changed mods cannot constrain code that has already been approved and then runs with broad host authority. ### 2.3 VPet and tModLoader moved controls closer to publication VPet-Simulator published its own Workshop security notice on 20 September. The developers reported copied versions of popular mods that had been injected with malware and uploaded under other accounts. The known items were banned, and samples were submitted for analysis.\[5\] The response combined several controls: - an in-game uploader for executable plugins; - integrity checks over DLL content; - unique names intended to reduce impersonation; - source-code links for released code plugins; - a ten-hour account threshold for code-plugin uploads. The game also added interception for mods confirmed to carry security risk. The notice is candid about the boundary. Banning an item stops further subscriptions and does not restore machines that already executed it.\[5\] tModLoader described a different control in its February 2026 stable update. In partnership with Valve, the project introduced an approval queue intended to catch malicious mods and updates before they reached users.\[6\] These responses place useful gates before distribution or load. They also show why one universal control is unlikely to be sufficient. Review queues can miss malicious behaviour. Signatures can authenticate a malicious publisher. Source availability does not establish that a binary matches that source. That connection requires verified provenance from a trusted builder or an independently verified reproducible build. Even then, it establishes artifact correspondence rather than benignness.\[20\]\[21\] The gap exposed by these incident responses is not runtime sandboxing in general. Factorio, Roblox, browser extensions and Fuchsia already establish important parts of that design.\[13\]\[14\]\[23\]\[25\] The proposed synthesis is a shared, versioned link between immutable release identity, exact dependency closure, user-visible authority, rollout and current launch authorisation. ### 2.4 Takedown does not repair an endpoint Project Zomboid provides an independent example. On 8 April 2026, The Indie Stone reported that obfuscated Workshop mod code had created malicious files outside the game directory. The items were removed and the uploader was banned. The developer then warned that uninstalling the mods was insufficient for machines where the code had already run.\[33\] The case separates distribution containment from endpoint recovery. Removing an item can stop further subscriptions. It cannot undo operating-system effects that occurred before removal. This is another reason revocation and launch denial belong in the contract. They reduce continued exposure while incident response handles affected machines. ## 3. Identity, artifact integrity and execution authority are separate ### 3.1 Publisher identity Publisher identity answers who was authorised to submit a release in one namespace. It supports accountability and revocation of future publishing rights. An account threshold can slow disposable attackers. A verified organisation or maintainer key can provide a stronger attribution signal. Neither makes the submitted code benign. Publisher authority should be scoped. A key authorised for one item should not automatically publish another. Project transfer should leave an explicit record because a change in control alters the trust basis for future releases. ### 3.2 Artifact identity An artifact digest answers which exact bytes were admitted. OCI content descriptors provide a useful precedent: media type, size and a collision-resistant digest identify a content-addressed object, and a client verifies size and digest before processing it.\[18\] A release signature binds an authorised publisher key to that digest. Build provenance can describe how the artifact was produced. These are different claims. The platform should assign an immutable release sequence. Item titles and version labels remain human-facing metadata. They must not be the execution identity. ### 3.3 Execution authority Execution authority answers what the admitted artifact can do at launch. Launch authorisation is evaluated first: ```text launch allowed only if the installed artifact digest matches a release the platform admitted and signed rollout or cohort policy permits launch and that release is not quarantined or revoked and authorisation metadata satisfies the declared freshness policy ``` If launch is allowed, the effective capability grant is: ```text requested capabilities intersect platform policy intersect game policy intersect player grant ``` The host may reduce authority. It must not silently expand it. An artifact digest does not constrain authority. A perfectly verified DLL loaded into the game process can still read player files if the operating system allows it. The same rule applies to WebAssembly. Core WebAssembly isolates memory and requires host interaction through imports.\[9\] The security of the full system depends on the imports. A generic host function that accepts arbitrary paths or URLs can recreate broad ambient authority inside a typed interface. ### 3.4 Update and propagation risk An update changes at least one of these: - executable bytes; - dependencies; - compatibility; - requested authority; - persistent-state schema. The risk is not proportional to file size. A tiny change can add a network destination or a Workshop publishing call. A dependency update can expand authority without changing the parent artifact. Propagation risk depends on how quickly the release reaches subscribers and whether the code can publish or update other artifacts. The February People Playground incident used user uploads as a propagation path.\[1\]\[2\] Rollout policy should derive reverse-dependency count from a specified repository snapshot. Because that count changes as other items are published or removed, it belongs in derived risk and status data rather than the immutable release. A widely depended-on library mod can have a larger blast radius than a visible end-user mod with more direct subscribers. ## 4. Threat model ### 4.1 Malicious publication An attacker creates an item whose stated purpose conceals harmful behaviour. The publisher identity may be accurate. Moderation and reputation are the primary pre-publication signals, while runtime capabilities limit the effect of a miss. ### 4.2 Account or build compromise A trusted publisher account or build process is compromised. The attacker publishes an update through a namespace players already trust. Verified upload signing, as offered by the Chrome Web Store, can reduce account compromise risk by requiring a separate signing key for package updates.\[23\] It does not protect a compromised signing key or malicious build. Build provenance helps identify the builder and inputs. in-toto records signed steps, materials and products.\[20\] SLSA provenance records builder identity, build type and resolved dependencies.\[21\] Neither framework claims to prove that source or dependencies are safe. ### 4.3 Dependency substitution A benign mod depends on another item by mutable name or ID. The dependency later changes, or resolution selects a release that was not evaluated with the parent. The contract should lock the complete transitive closure to release digests. Cycles and graph-size limits must be checked before launch. SLSA dependency reporting remains best effort, so provenance should not be the normative runtime resolver.\[21\] ### 4.4 Confused-deputy access A low-authority mod calls a host API that performs a privileged action using the game's own credentials or authority. The mod never receives a raw filesystem or Workshop handle and still causes a privileged effect. Every host operation needs object-scoped handles, caller context and explicit checks. A capability name alone is too coarse if the function behind it can act on arbitrary resources. ### 4.5 Sandbox escape and host defects The runtime, compiler or host API contains a vulnerability. Wasmtime published 2026 advisories covering a compiler defect that allowed a guest to reach memory outside its sandbox, a filesystem sandbox escape and guest-controlled host allocation.\[12\] The contract does not make sandbox escapes impossible. It creates a smaller authority surface and a patchable runtime boundary. A worker process with operating-system restrictions provides another layer when the mod is hostile. Runtime version is therefore part of the launch decision. A revoked or vulnerable runtime profile can block execution even when the mod artifact has not changed. ## 5. A UGC Execution Contract ### 5.1 Artifact and provenance fields The contract describes one immutable executable release. It is not a mutable profile attached only to a Workshop item. A minimal release record needs: ```yaml release_payload: platform: steam game_id: 67890 item_id: 12345 sequence: 17 artifact: media_type: application/wasm size: 481203 digest: sha256:... dependency_lock: media_type: application/vnd.example.ugc-lock+json size: 2841 digest: sha256:... publisher: namespace: workshop:12345 identity: key-or-platform-subject runtime: profile: game-wasm-v2 interface: example:game/mod-api@2.1.0 compatibility: game_build: minimum: 4102 maximum: 4199 release_envelope: payload_digest: sha256:... publisher_signature_bundle_digest: sha256:... ``` The platform item ID remains the subscription identity. The release tuple identifies what may run: ```text platform game ID item ID release sequence artifact digest ``` The platform hashes the exact serialised bytes of the completed immutable release payload. The payload does not contain its own digest or signature. A detached publisher signature bundle binds the publisher identity and namespace to that digest. The full payload contains or digest-references the executable, dependency lock, requested capabilities, resource limits, runtime profile, compatibility and persistent-state schema. Changing any of those bytes creates a new release. Platform admission and current launch authorisation are separate signed records, so policy can change without rewriting release history. A platform may revoke current launch authority without changing the historical publisher signature. Build provenance is optional evidence at lower trust tiers and can become a requirement for high-authority releases. in-toto and SLSA provide useful formats for builder identity, steps and resolved inputs.\[20\]\[21\] The platform still signs its own admission result because provenance policy is a platform decision. Sigstore provides identity-bound signing and transparency records that can carry release evidence.\[22\] A transparency entry supports audit and does not create the runtime revocation decision by itself. An SBOM can record libraries embedded inside the package. It supplements the normative dependency lock and does not replace it. ### 5.2 Capability fields The capability vocabulary must be stable enough for code and understandable enough for players and developers. One possible shape is: ```yaml capabilities: game: read: - world.weather - player.location write: - world.weather filesystem: mounts: - name: mod-data mode: read-write quota_mib: 32 network: http: - scheme: https host: api.example.net methods: [GET] request_limit_per_minute: 10 response_limit_kib: 256 process: spawn: false workshop: publish: false update: false ``` The manifest should not expose host paths. A logical `mod-data` mount maps to a runtime-controlled directory. Network authority should name destinations and methods. A boolean such as `network: true` is too broad for a useful permission decision. Game capabilities need object and operation scope. A single `world.write` entry can cover anything from changing weather to deleting a save. Splitting read and write over a named object, as in `write: world.weather`, lets each grant be authorised and tested separately. Optional capabilities should be requested when the feature is used. A mod that offers a Discord integration does not need network authority for players who never enable it. Required capability expansion between releases should pause the update until the player accepts the new authority. Chrome provides a useful precedent: extensions adding warning-producing permissions are disabled until the user accepts the change.\[23\] ### 5.3 Runtime and resource fields Authority includes resource consumption. The release should declare limits such as: ```yaml resources: memory_mib: 64 cpu: callback_budget_ms: 2 callbacks_per_second: 60 handles: maximum: 1024 storage: files: 500 bytes_mib: 32 logs: kib_per_minute: 128 ``` The game may reduce these values. A release cannot increase them at runtime. Storage is bounded in two places. The mount quota limits one logical mount and the release storage budget limits the total across mounts. The effective limit is the lower of the two. WebAssembly engines expose controls for memory growth and interruption. Wasmtime supports deterministic fuel and epoch-based interruption, with different performance and determinism tradeoffs.\[11\] Host allocations still need separate bounds because guest input can cause the host to allocate memory outside the WebAssembly linear memory.\[12\] Fuel and epochs constrain time spent executing WebAssembly instructions. They do not interrupt a guest blocked inside a host call. Brokered filesystem, network and game operations therefore need their own deadlines, cancellation and host-allocation limits.\[11\] Runtime identity includes: - engine and version; - compiler backend; - WASI or component profile; - game API version; - operating-system sandbox profile. Writing `WASI compatible` is not precise enough. WASI 0.3 reached stable status in 2026 while broader Component Model work and toolchain support remained in progress.\[32\] ### 5.4 Update and rollout fields An immutable release should have a separate control-plane authorisation record. Every launch-relevant version of that record must be signed and monotonically versioned, and may carry one of these states: ```text draft admitted canary published paused yanked quarantined revoked superseded ``` Each state has separate install, update and launch meaning. | State | New install | Automatic update | Existing launch | | --- | --- | --- | --- | | Draft | No | No | No | | Admitted | Testers only | No | Testers only | | Canary | Cohort only | Cohort only | Allowed for cohort | | Published | Allowed | Allowed | Allowed | | Paused | No expansion | No expansion | Allowed | | Yanked | No | No | Policy dependent | | Quarantined | No | No | Blocked pending review | | Revoked | No | No | Blocked | | Superseded | No new resolution | Move to replacement | Allowed by compatibility policy | Rollout fields can include: ```yaml rollout: ring: fixed-cohort minimum_users: 25 minimum_launches: 100 observation_hours: 24 automatic_promotion: false rollback: compatible_to: - release: 15 - release: 16 ``` The persistent-state schema version stays in the immutable release payload because it describes the code. The control plane records only which earlier releases it currently authorises as rollback targets, and a platform may narrow that set after a migration defect is found. An emergency rollback should create newer trusted metadata that points to an older artifact. Secure update systems such as TUF prevent attackers from forcing old metadata on clients.\[19\] Product rollback must preserve that monotonic trust record. ### 5.5 Receipts and observed behaviour The declared contract is useful only when the platform and runtime can prove what they applied. A modset-lock digest covers the complete ordered set of release digests admitted for one launch, so a receipt identifies the combination instead of one mod. A launch receipt should connect: ```text account or anonymous cohort game build modset-lock digest release digest runtime profile effective capability grant launch decision revocation metadata version termination reason resource-limit events ``` The receipt does not need to contain player content or raw mod data. Privacy and retention should be designed separately. Runtime telemetry can show: - denied capability calls; - resource-limit terminations; - crashes by release and modset; - save migration failure; - rollback success; - unexpected network destinations; - launch of revoked content attempted while offline. Observed behaviour is not a substitute for authority. A mod that has not yet used its network access still holds it. Telemetry supports rollout and investigation after the grant has been made. ## 6. Enforcement has two owners ### 6.1 Platform responsibilities The distribution platform is positioned to own release trust. Its responsibilities include: - immutable artifact storage; - publisher namespace and key management; - release sequence and digest assignment; - dependency lock resolution; - signature and provenance verification; - compatibility metadata; - permission-change consent state; - staged rollout; - current revocation state. Content-addressed descriptors, as used by OCI, provide a suitable artifact identity model.\[18\] TUF provides a mature model for signed update metadata, role separation, expiration and rollback protection.\[19\] The proposal does not require copying those formats unchanged. It needs equivalent properties. mod.io provides useful cross-game prior art through modfile versions, an MD5 file-hash field, dependency support and automated scanning.\[17\] The MD5 value is useful for file matching but is not a modern collision-resistant trust anchor. Executable release identity still needs SHA-256, BLAKE3 or an equivalent approved digest.\[18\] mod.io's controls manage distribution and moderation rather than defining the game's execution sandbox. Fuchsia provides a broader architectural analogue. Its component framework routes explicit capabilities between isolated components and combines that model with content-addressed packages and secure updates.\[25\] It is an operating-system design rather than a player-facing mod platform. Chrome extensions provide especially close operational store prior art. Declared permissions, user approval after warning-producing required permission expansion, partial rollout and rollback are coordinated across the store and browser. They do not model exact mod dependency closure, game-specific API authority or save-state rollback compatibility.\[23\] The platform can also calculate graph-level risk. A dependency used by ten thousand other items needs a stricter release path than an isolated test mod. The platform sees that graph more clearly than one game runtime. Platform admission cannot prove safe execution. Static analysis, malware scanning and moderation reduce risk before install. They cannot enumerate every future host interaction. ### 6.2 Game and runtime responsibilities The game defines the operations that make a mod useful. That makes the game or shared runtime responsible for enforcement. The runtime also performs the launch-time checks. Before instantiation it hashes the installed artifact and compares it with the admitted release. It refuses dependencies outside the lock and evaluates revocation metadata against the declared freshness window. It then computes the effective grant and writes the launch receipt. The platform decides admission. The runtime is the layer that can refuse to execute installed bytes. A safe host API uses typed resource handles rather than raw pointers or global object IDs. The handle is scoped to one mod instance and checked on every use. A weather mod may receive a weather-controller handle without receiving the world save or arbitrary entity mutation. Filesystem access should be split into logical mounts: - read-only package files; - temporary storage for one release; - persistent storage for one item; - restricted migration storage. Network access should pass through a broker. The broker validates the destination after DNS resolution, blocks private-address redirection, limits response size and records the release identity behind the request. Authoritative simulation needs a stricter profile. A deterministic mod can use a seeded game RNG and simulation clock. Network work should remain outside the simulation callback and return through queued messages. Multiplayer authority remains server-side. A client mod should not gain the ability to commit shared state because it received a local capability grant. The runtime also owns failure containment. Infinite loops, excessive memory, log floods and expensive host calls need limits. A terminated mod should not corrupt the host or prevent the game from loading a safe modset. ### 6.3 Native extensions need a separate risk tier One contract cannot turn arbitrary in-process native code into low-authority code. Managed loaders also require care. tModLoader loads .NET assemblies through AssemblyLoadContext. Microsoft describes AssemblyLoadContext as a dependency-loading boundary and states that it provides no binary isolation.\[15\] Garry's Mod permits native binary modules, while its documentation warns that they can be malicious and harm the system. Those modules are installed manually rather than delivered as ordinary addons.\[16\] A practical tier model is: | Tier | Execution model | Default treatment | | --- | --- | --- | | Data | Parsed assets or declarative data | Parser limits and schema validation | | Script | Restricted game VM | Game API capabilities and quotas | | Wasm | Component runtime | Explicit imports, resource limits and worker sandbox | | Managed | Out-of-process runtime | Versioned RPC and OS sandbox | | Native | Out-of-process native worker | Explicit high-risk consent and strong provenance | Same-process native auto-installation should sit outside the standard low-authority guarantee. A game may still support it for expert users, but the platform should label the change honestly. Process isolation has costs. It adds IPC and complicates debugging. Those tradeoffs should be measured against a security-equivalent baseline rather than comparing an isolated plugin with an unrestricted DLL and calling the difference sandbox overhead. ## 7. Updates should be treated as deployments ### 7.1 Capability expansion is a new approval event A player who approved a weather mod did not necessarily approve a later release that uploads analytics or publishes Workshop content. Update consent should compare semantic authority. For an admitted release, the required grant is the set of non-optional capabilities requested by it and its locked dependency closure after platform and game policy approval. It excludes the player's prior grant because this comparison determines whether new consent is needed. The comparison is: ```text old required grant over the old locked dependency closure prospective required grant over the new locked dependency closure ``` An update that requests authority prohibited by platform or game policy fails admission instead of prompting the player. A digest change with no expansion of the prospective required grant can follow the normal rollout policy. An expansion of the prospective required grant pauses automatic update until the player accepts it. Optional features can request authority when used. The comparison must include dependencies. A parent executable may remain byte-for-byte identical, but selecting a different dependency release requires a new release payload and dependency lock. If that dependency expands the prospective required grant, the update has changed authority. Permission prompts need stable platform wording. Publisher descriptions can explain why the feature is useful and cannot redefine what a capability means. ### 7.2 Staged rollout limits blast radius Chrome Web Store supports percentage rollouts for extensions with more than ten thousand seven-day active users.\[23\] Google Play and the Apple App Store also support staged or phased release patterns.\[24\] A canary limits initial exposure. It does not contain every effect or prove safety. Effects may reach shared external systems, and malicious behaviour may be delayed until after promotion. A useful canary receives enough representative use to reveal common failures before wider deployment. Google SRE guidance notes that a handful of requests provides weak evidence for a heterogeneous workload.\[30\] An executable-UGC rollout should begin with: 1. the maintainer; 2. a compatibility test ring; 3. an explicit opt-in beta; 4. a fixed minimum cohort; 5. percentage expansion after minimum event counts. The cohort should be stable for one release digest. A keyed assignment can combine account, item and release identity without exposing the raw account identifier to the publisher. Telemetry must include the complete modset-lock digest. Otherwise a crash cannot be attributed reliably when several interacting mods changed. ### 7.3 Revocation needs an execution path Stopping new downloads does not stop an installed artifact from running. The control plane needs four distinct actions: | Action | Effect | | --- | --- | | Pause | Stop rollout expansion | | Yank | Stop new resolution or install | | Roll back | Authorise a previous artifact through newer trusted metadata | | Revoke | Deny launch of a digest already installed | Google Play documents the distinction directly: halting a staged rollout does not remove the release from users who already received it.\[24\] Revocation metadata needs an offline policy. A client that has been offline for months cannot know the current denylist. The platform must declare a maximum metadata age and decide whether offline launch is blocked, permitted under grace or limited to lower-risk tiers. Long-running servers create another problem. A release can be revoked after it starts. High-authority plugins may need a short-lived execution lease that the host renews periodically. ### 7.4 Small audiences limit statistical confidence Many mods will never have enough users for a meaningful percentage canary. One per cent of forty subscribers is not a representative cohort. Small releases need stronger pre-release evidence: - deterministic save/load tests; - fuzzing of parsers and host APIs; - compatibility matrices; - malicious-fixture tests; - explicit beta users; - a fixed minimum launch count. Promotion rules should combine time and event count. Twenty-four quiet hours with two launches does not establish readiness. Deployment controllers also encounter a rounding problem when small replica counts are converted into rollout percentages.\[31\] UGC systems should use absolute cohort minima before percentage expansion. The platform should report uncertainty rather than turning a small sample into a green badge. Manual review may remain the correct gate for a high-authority release with a small population. ## 8. Security controls must preserve a usable mod ecosystem ### 8.1 Stable APIs reduce requests for broad authority Mod creators ask for broad access when the platform lacks a supported API for the capability they need. A stable game API can expose common operations through narrow calls. A media integration can receive a brokered HTTP capability. A configuration mod can receive one storage mount. A deterministic simulation mod can receive an event stream and a command buffer. Batch operations also matter for performance. A host API that requires one boundary crossing for every entity field can make a sandbox appear unreasonably expensive. Versioned query and command buffers preserve authority while reducing calls. API design is part of the security model. A sandbox with weak developer ergonomics will push creators toward native extensions or unofficial loaders. Factorio provides mature game-specific precedent. Its Lua environment removes general filesystem and operating-system facilities and modifies parts of the runtime for determinism. Its official Mod Portal also exposes versioned releases, dependency constraints, game-version compatibility and per-release SHA-1 values. These are meaningful distribution precedents, although SHA-1 is not suitable as a new collision-resistant trust anchor.\[13\] Roblox provides closer runtime-enforcement prior art for marketplace UGC. On 13 May 2026 it announced automatic sandboxing of assets inserted from the Creator Store and engine-level blocking of specified high-risk capabilities. Its broader fine-grained Script Capabilities system remained experimental. These systems establish game-UGC runtime enforcement. They do not bind modern provenance, exact transitive dependency identity, rollout and launch revocation in one release contract.\[14\] ### 8.2 Permission prompts need meaningful differences Permission prompts fail when every release asks for broad access or when the wording does not explain consequence. The platform should show changes: ```text This update adds outbound access to api.example.net. It does not add access to local files, process creation or Workshop publishing. ``` The second sentence should be generated from the capability diff, not written by the publisher. Platform wording is fixed for the classes the platform mediates: filesystem, network, process and publishing. Game capability namespaces stay game-defined. The game supplies the display string for each named operation, and the platform reviews it once per interface version before rendering it unchanged. Low-risk optional capabilities can be requested in context. Chrome recommends optional permissions because the user sees the request when the feature is used.\[23\] The same pattern can work for a mod feature that needs one external service. Approval fatigue remains a risk. The vocabulary should remain small enough for stable meaning and detailed enough to separate materially different authority. ### 8.3 Reputation can inform review without becoming authority Publisher age, prior violations and update history can influence review priority. Popularity and account age should not become permission to bypass runtime controls. New creators need a route into the ecosystem. A staged trust model can require lower-authority runtimes or smaller rollout cohorts without preventing useful data and script mods. VPet's ten-hour threshold is a friction control against newly created uploader accounts.\[5\] It is useful within that incident response and does not prove that established accounts are safe. The platform should retain an appeal and recovery path when an account or artifact is wrongly classified. ### 8.4 Compatibility is part of the security design Mod ecosystems depend on deep integration. Restricting every mod to a small API can remove the experimentation that made the ecosystem valuable. Compatibility metadata needs: - game build range; - runtime profile; - interface version; - dependency release digests; - persistent-state schema; - migration entry point; - rollback compatibility. Save compatibility is especially important. A release can pass security checks and still make rollback unsafe because it migrated persistent data. Chrome's rollback documentation warns that returning to a previous extension version can break state or lose data when formats are incompatible.\[23\] The platform should snapshot state before a migration where practical. A release with an irreversible migration needs a stricter rollout and an honest rollback status. Several execution tiers may coexist. Most players can use the standard sandboxed path. Expert users can opt into native extensions with a clear warning. The goal is to make the safe path capable enough that broad authority is exceptional. ## 9. Proposed reference prototype ### 9.1 Runtime The reference prototype should be narrow enough to complete and broad enough to test the contract. One implementation can use a Rust host with a current patched Wasmtime release. The host exposes one versioned WIT world for: - configuration reads and writes; - deterministic game events; - bounded entity queries; - batched command submission; - brokered HTTP; - logging. The WebAssembly worker should also run inside an operating-system sandbox with no ambient access to player files, credentials or unrestricted network. This provides defence in depth when the runtime or host contains a defect. The release package contains: ```text component.wasm ugc-contract.yaml dependency-lock.json sbom.json provenance.json signature bundle ``` A small TUF repository can distribute fresh, signed release metadata and the current authorised-target set.\[19\] Runtime revocation of an already installed digest should be expressed in a separate signed launch-policy or digest-denylist object carried by that update channel. The prototype does not need to reproduce a commercial store. It needs to demonstrate release identity, update consent, rollout state and launch enforcement. The game host can be a deterministic arena simulation rather than a complete game. That keeps the benchmark focused on execution and host calls. Extism can provide a second Wasm plugin baseline because it exposes a practical manifest and multi-language plugin interface around Wasmtime.\[26\] ### 9.2 Test mods The benign fixtures should exercise distinct authority: | Fixture | Intended authority | | --- | --- | | WeatherMod | Read configuration and submit weather commands | | ScoreboardMod | Read match events and write local persistent state | | CommunityStatusMod | Call one declared HTTPS endpoint outside the simulation loop | | SharedLibrary | Supply a helper dependency with no direct game authority | | MigratingMod | Update a versioned persistent-state record | The malicious suite should include: - path traversal and symlink escape attempts; - undeclared network destinations; - private-address and redirect-based SSRF; - process creation attempts; - excessive memory growth; - infinite loops; - oversized host-call inputs; - forged or stale object handles; - terminal escape sequences in logs; - artifact and dependency substitution; - use of a revoked digest. A second release of one benign mod should add a new required capability. The update must pause until the player accepts it. A dependency update should request broader authority without changing the parent code. The required-grant comparison over the new locked dependency closure must still detect the expansion and pause the update. ### 9.3 Security evaluation Each security test needs an expected decision and an observed result. ```text release admitted? installed? update paused? launch allowed? host call allowed? worker terminated? receipt emitted? ``` The required invariants include: 1. An artifact whose digest differs from the admitted release does not launch. 2. A dependency outside the lock does not load. 3. A capability outside the effective grant does not reach the host operation. 4. A revoked digest does not launch when revocation metadata is within the declared freshness window. 5. A resource-limit violation terminates the mod without terminating the host. 6. Capability expansion does not update silently. Regression tests should include public Wasmtime advisories relevant to the chosen runtime version.\[12\] The aim is to make runtime patching and security regression part of the product contract without recreating every vulnerability. Fuzzing should target the manifest parser, dependency resolver and host APIs. The guest can generate validly typed inputs whose sizes and combinations are hostile. ### 9.4 Performance evaluation Performance comparisons must separate unlike security properties. The prototype should compare: | Baseline | Interpretation | | --- | --- | | Data or command-only mod | Lowest authority when the feature allows it | | Core WebAssembly module | Core engine and boundary cost | | WebAssembly component | Proposed standard sandbox path | | Extism plugin | Practical Wasm plugin framework baseline | | Managed plugin in sandboxed subprocess | Higher compatibility with process isolation | | Native plugin in sandboxed subprocess | Native compatibility with RPC overhead | | Native in-process DLL | Unsafe performance upper bound | The unrestricted DLL is not a security-equivalent competitor. It estimates the performance available when isolation is removed. Workloads should include: - compute-heavy procedural work; - frequent scalar host calls; - batched entity reads and command writes; - large binary payloads; - persistent storage; - cold load; - warm frame callbacks; - several concurrent plugins; - forced termination. Measure: - validation and compilation time; - instantiation and first-call latency; - p50, p95 and p99 callback latency; - frame or tick budget impact; - CPU time and context switches; - process and per-instance memory; - host allocations caused by guest calls; - boundary crossings and copied bytes; - termination and restart time; - signature and metadata verification time. No universal overhead number should be inferred. A 2019 browser study found substantial gaps between WebAssembly and native code for its selected engines and workloads.\[27\] A 2024 peer-reviewed study using Wasmtime and Sightglass measured compilation, instantiation and execution separately across x86, ARM and RISC-V.\[28\] Sightglass itself warns that it is not a general-purpose cross-engine benchmark suite and that engine-specific configuration can make cross-engine comparisons invalid.\[29\] Report the exact compiler backend, AOT or JIT mode, pooling configuration, WASI profile and interruption mechanism. ### 9.5 Developer-effort evaluation A platform contract fails when ordinary developers cannot adopt it. The prototype should record: - time to first working mod; - host and guest glue code; - generated binding size; - build time; - debugging and profiling workflow; - effort to declare least privilege; - effort to migrate an existing plugin; - errors produced by an incompatible interface; - packaging and signing steps. A small controlled task can compare the WebAssembly path with a managed subprocess and Extism. The aim is to find where tooling creates friction. Ranking programming languages is out of scope. The host API should also be reviewed by a mod developer. A theoretically safe interface can still be unusable because it omits common operations. ### 9.6 Required artifacts The future repository should publish: - host and plugin source; - pinned runtime and toolchain versions; - WIT interfaces; - release and capability schemas; - dependency-lock schema; - signed test repository metadata; - malicious fixtures; - deterministic security tests; - benchmark harness; - raw result files; - environment manifest; - analysis scripts; - licence and third-party notices; - exact reproduction commands. Raw evidence should connect a release digest to its requested grant, effective grant, launch decision and observed outcome. ## 10. Where the contract stops The contract does not establish that a release is benign. A publisher can request only permitted capabilities and still abuse them. A network-enabled integration can exfiltrate information it legitimately reads. A simulation mod can manipulate game state within its declared API in a way that ruins a save. The contract also does not remove moderation. Item descriptions, community reports, account abuse and deceptive behaviour remain platform concerns. Anti-cheat and competitive integrity need separate controls. A locally approved client mod cannot be allowed to define shared multiplayer truth. Copyright, privacy and consent are also outside the capability decision. A mod can distribute infringing assets while requesting no dangerous runtime authority. The host remains trusted. A capability check implemented incorrectly can widen authority. Runtime patching and game API review remain required. Finally, legacy compatibility may prevent one transition. An ecosystem with years of in-process native mods cannot move every item into WebAssembly without breaking it. The contract should support explicit tiers and migration rather than pretending the legacy authority does not exist. ## 11. The strongest counterargument The strongest objection is that the proposal moves an operating-system security problem into a game distribution platform and creates complexity that most games cannot afford. Games already choose their mod architecture. A title that executes arbitrary C# or native code has made a compatibility decision, and Steam cannot safely infer or intercept every operation from outside the process. A cross-platform capability vocabulary can become either too coarse to help or too complex for players to understand. Sandboxing can also remove the features that made a mod ecosystem valuable. Large overhauls often depend on reflection, native libraries or deep access to internal state. A narrow stable API may work for small extensions and fail for the projects players care about most. Performance and support cost are material. An extra worker process consumes memory. RPC adds latency. A shared runtime becomes another patch obligation. Game developers must maintain interface compatibility across releases and investigate failures involving combinations of mods they did not create. Rollout controls can create a false sense of evidence. Popular mods can still have highly varied player environments. Long-tail mods may never generate enough launches for a useful canary. Malicious code can delay its behaviour until after promotion. These objections narrow the proposal. The largest practical objection is adoption. Every platform duty in Section 6.1 requires either distribution-platform participation or a game-operated control plane. A game cannot make Steam issue these records, but a game or shared loader can implement release identity, dependency locking, capability grants, launch receipts and revocation checks against its own signed metadata. Platform-issued identity can be integrated later without changing guest APIs. The platform should not promise that metadata alone secures arbitrary executable UGC. It should define a standard trust path that games can adopt. Games retain control over their API and can support a separate legacy tier. The capability vocabulary should focus on authority the host can actually mediate. Filesystem mounts, brokered network destinations and named game APIs are enforceable. Vague declarations such as `safe` or `trusted` are not. Canary evidence should supplement pre-release testing. It should not become an automatic proof of security. High-risk releases can require manual approval or remain opt-in. The cost is justified where the ecosystem already distributes executable code automatically. In that setting, each game is operating a package ecosystem without shared release identity, permission semantics or revocation behaviour. A common contract reduces duplicated work even when enforcement remains game-owned. ## 12. What this paper does not claim This paper does not claim: - that Steam Workshop has no existing security, moderation or abuse controls; - that the public Steamworks API describes Valve's complete internal architecture; - that the September People Playground warning is a completed forensic report; - that WebAssembly cannot escape its sandbox; - that signatures or provenance prove code is safe; - that data-only UGC is risk-free; - that every game should replace its current mod architecture; - that one permission taxonomy can describe every game API; - that staged rollout revokes content already installed; - that a small canary proves a release is safe; - that native mods can receive low authority while executing in the game process; - that the proposed prototype has been implemented or benchmarked. The paper proposes a contract and a test method. Its usefulness depends on whether real games can expose capable APIs without recreating broad ambient authority. ## 13. Conclusion Executable UGC is software delivered through a content platform. The 2026 Workshop incidents show the cost of treating subscription as a sufficient trust decision. People Playground added content-aware approval after self-propagating malware. VPet added integrity checks and stronger publisher requirements. tModLoader introduced a review queue with Valve. Each response reduced a part of the risk. The remaining gap exposed by these Steam-style incidents is the shared link between release trust and runtime authority. A platform knows the publisher namespace, the item and the distribution state. A game knows what installed files mean and which operations its runtime exposes. A useful security model has to connect those layers. The proposed UGC Execution Contract binds an immutable release digest to its dependency closure, compatibility and requested capabilities. The distribution platform, or a game-operated control plane where platform support is unavailable, controls admission, rollout and current launch authorisation. The runtime applies the effective grant at launch and records what happened. This model does not make moderation or malware analysis unnecessary. It limits the authority available when those controls miss something. It also improves ordinary change management. Capability expansion becomes visible. Rollback compatibility becomes explicit. A revoked release can be denied after installation when the client holds signed launch-authorisation metadata within the declared freshness window. Crashes can be linked to one release and one modset rather than a mutable item name. Modding succeeds because creators can change games in ways the original team did not predict. The goal is to preserve that freedom while making executable authority deliberate. ## About the author Jason Doyle writes about software systems, reliable products, applied AI and practical controls for systems that influence human and organisational decisions. He publishes at [jasondoyle.ie](https://jasondoyle.ie) and can be contacted at [contact@jasondoyle.ie](mailto:contact@jasondoyle.ie). ## References 1. Studio Minus, *Urgent PSA*, People Playground Steam Community announcement, 1 February 2026, [https://steamcommunity.com/games/1118200/announcements/detail/534373847137256682](https://steamcommunity.com/games/1118200/announcements/detail/534373847137256682). 2. Studio Minus, *Security Update*, People Playground Steam Community announcement, 3 February 2026, [https://steamcommunity.com/games/1118200/announcements/detail/534373847137257252](https://steamcommunity.com/games/1118200/announcements/detail/534373847137257252). 3. Studio Minus, *Updates and Workshop*, People Playground Steam Community announcement, 6 February 2026, [https://steamcommunity.com/games/1118200/announcements/detail/536626281230369458](https://steamcommunity.com/games/1118200/announcements/detail/536626281230369458). 4. Studio Minus, *Bad event*, People Playground Steam Community announcement, 22 September 2026, [https://steamcommunity.com/games/1118200/announcements/detail/717916455762396046](https://steamcommunity.com/games/1118200/announcements/detail/717916455762396046). 5. VPet-Simulator development team, *Notice on Steam Workshop MOD Safety, Anti-Fraud, and Submission Rule Changes*, Steam Community announcement, 20 September 2026, [https://steamcommunity.com/games/1920960/announcements/detail/702153857067647635](https://steamcommunity.com/games/1920960/announcements/detail/702153857067647635). 6. tModLoader team, *February 2026 Stable Update*, Steam Community announcement, 2 February 2026, [https://steamcommunity.com/games/1281930/announcements/detail/503973915196918696](https://steamcommunity.com/games/1281930/announcements/detail/503973915196918696). 7. Valve, *Steam Workshop Implementation Guide*, Steamworks documentation, accessed 22 September 2026, [https://partner.steamgames.com/doc/features/workshop/implementation](https://partner.steamgames.com/doc/features/workshop/implementation). 8. Valve, *ISteamUGC Interface*, Steamworks documentation, accessed 22 September 2026, [https://partner.steamgames.com/doc/api/ISteamUGC](https://partner.steamgames.com/doc/api/ISteamUGC). 9. WebAssembly Community Group, *Security*, accessed 22 September 2026, [https://webassembly.org/docs/security/](https://webassembly.org/docs/security/). 10. WebAssembly/WASI, *WASI Design Principles*, commit `4124135c543a1d103561f741af102a7ea9a0a8d0`, accessed 22 September 2026, [https://github.com/WebAssembly/WASI/blob/4124135c543a1d103561f741af102a7ea9a0a8d0/docs/DesignPrinciples.md](https://github.com/WebAssembly/WASI/blob/4124135c543a1d103561f741af102a7ea9a0a8d0/docs/DesignPrinciples.md). 11. Bytecode Alliance, *Wasmtime Security*, *Interrupting Wasm Execution*, `Config` API and runtime-limit documentation, accessed 22 September 2026, [https://docs.wasmtime.dev/security.html](https://docs.wasmtime.dev/security.html), [https://docs.wasmtime.dev/api/wasmtime/struct.Config.html](https://docs.wasmtime.dev/api/wasmtime/struct.Config.html), [https://github.com/bytecodealliance/wasmtime/blob/54988feba2b9737c3b12642ec8fe07f5b29dfd61/docs/examples-interrupting-wasm.md](https://github.com/bytecodealliance/wasmtime/blob/54988feba2b9737c3b12642ec8fe07f5b29dfd61/docs/examples-interrupting-wasm.md), [https://github.com/bytecodealliance/wasmtime/blob/cc8d04f45d9bcc7889c91ed35f88302202413488/crates/wasmtime/src/runtime/limits.rs](https://github.com/bytecodealliance/wasmtime/blob/cc8d04f45d9bcc7889c91ed35f88302202413488/crates/wasmtime/src/runtime/limits.rs). 12. Bytecode Alliance, Wasmtime security advisories `GHSA-jhxm-h53p-jm7w`, `GHSA-vqjp-4c8c-hfgg` and `GHSA-x84v-gj2h-g759`, 2026, [https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-jhxm-h53p-jm7w](https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-jhxm-h53p-jm7w), [https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-vqjp-4c8c-hfgg](https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-vqjp-4c8c-hfgg), [https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-x84v-gj2h-g759](https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-x84v-gj2h-g759). 13. Wube Software, Factorio *Libraries and functions*, *Data lifecycle*, *Mod Structure* and *Mod portal API* documentation, accessed 22 September 2026, [https://lua-api.factorio.com/latest/auxiliary/libraries.html](https://lua-api.factorio.com/latest/auxiliary/libraries.html), [https://lua-api.factorio.com/latest/auxiliary/data-lifecycle.html](https://lua-api.factorio.com/latest/auxiliary/data-lifecycle.html), [https://lua-api.factorio.com/latest/auxiliary/mod-structure.html](https://lua-api.factorio.com/latest/auxiliary/mod-structure.html), [https://wiki.factorio.com/Mod_portal_API](https://wiki.factorio.com/Mod_portal_API). 14. Roblox, *Embedding a sandboxed Luau virtual machine*, *Script capabilities*, and Roblox Creator Store Team, *Protect Your Games with Script Capabilities Sandboxing*, 13 May 2026, accessed 22 September 2026, [https://luau.org/sandbox/](https://luau.org/sandbox/), [https://create.roblox.com/docs/scripting/capabilities](https://create.roblox.com/docs/scripting/capabilities), [https://devforum.roblox.com/t/protect-your-games-with-script-capabilities-sandboxing/4634642](https://devforum.roblox.com/t/protect-your-games-with-script-capabilities-sandboxing/4634642). 15. tModLoader, `AssemblyManager.cs`, commit `07a92615df6e8e644eb66bf94b51959005ebc79e`, and Microsoft, *About AssemblyLoadContext*, accessed 22 September 2026, [https://github.com/tModLoader/tModLoader/blob/07a92615df6e8e644eb66bf94b51959005ebc79e/patches/tModLoader/Terraria/ModLoader/Core/AssemblyManager.cs](https://github.com/tModLoader/tModLoader/blob/07a92615df6e8e644eb66bf94b51959005ebc79e/patches/tModLoader/Terraria/ModLoader/Core/AssemblyManager.cs), [https://learn.microsoft.com/en-us/dotnet/core/dependency-loading/understanding-assemblyloadcontext](https://learn.microsoft.com/en-us/dotnet/core/dependency-loading/understanding-assemblyloadcontext). 16. Facepunch Studios, Garry's Mod documentation for `require`, accessed 22 September 2026, [https://wiki.facepunch.com/gmod/Global.require](https://wiki.facepunch.com/gmod/Global.require). 17. mod.io, *Automated Scanning*, *Dependency Management* and Modfile API documentation, accessed 22 September 2026, [https://docs.mod.io/moderation/automated-scanning/](https://docs.mod.io/moderation/automated-scanning/), [https://docs.mod.io/dependency-management/](https://docs.mod.io/dependency-management/), [https://docs.mod.io/restapi/docs/schemas/modfile-object](https://docs.mod.io/restapi/docs/schemas/modfile-object). 18. Open Container Initiative, *OCI Content Descriptors*, commit `13cff54902ec9ad6320cbc487a685b66fcd67171`, accessed 22 September 2026, [https://github.com/opencontainers/image-spec/blob/13cff54902ec9ad6320cbc487a685b66fcd67171/descriptor.md](https://github.com/opencontainers/image-spec/blob/13cff54902ec9ad6320cbc487a685b66fcd67171/descriptor.md). 19. Justin Cappos, Trishank Karthik Kuppusamy, Joshua Lock, Marina Moore and Lukas Puehringer, *The Update Framework Specification 1.0.36*, 5 August 2026, [https://github.com/theupdateframework/specification/blob/59e601ed29c0d2e497264ae8b31c11b8ef07df1e/tuf-spec.md](https://github.com/theupdateframework/specification/blob/59e601ed29c0d2e497264ae8b31c11b8ef07df1e/tuf-spec.md). 20. in-toto project, *in-toto Specification 1.0.0*, accessed 22 September 2026, [https://github.com/in-toto/docs/blob/117bb8e34aee9a7a6a5f6242b3e97c7c1391663a/in-toto-spec.md](https://github.com/in-toto/docs/blob/117bb8e34aee9a7a6a5f6242b3e97c7c1391663a/in-toto-spec.md). 21. SLSA project, *SLSA Specification 1.2*, build provenance and verification documentation, accessed 22 September 2026, [https://slsa.dev/spec/v1.2/](https://slsa.dev/spec/v1.2/), [https://slsa.dev/spec/v1.2/build-provenance](https://slsa.dev/spec/v1.2/build-provenance), [https://slsa.dev/spec/v1.2/verifying-artifacts](https://slsa.dev/spec/v1.2/verifying-artifacts). 22. Sigstore, *Security Model*, *Fulcio* and *Rekor* documentation, accessed 22 September 2026, [https://docs.sigstore.dev/about/security/](https://docs.sigstore.dev/about/security/), [https://docs.sigstore.dev/certificate_authority/overview/](https://docs.sigstore.dev/certificate_authority/overview/), [https://docs.sigstore.dev/logging/overview/](https://docs.sigstore.dev/logging/overview/). 23. Google Chrome, extension permission warnings, Chrome Web Store updates and rollback documentation, accessed 22 September 2026, [https://developer.chrome.com/docs/extensions/develop/concepts/permission-warnings](https://developer.chrome.com/docs/extensions/develop/concepts/permission-warnings), [https://developer.chrome.com/docs/webstore/update](https://developer.chrome.com/docs/webstore/update), [https://developer.chrome.com/docs/webstore/rollback](https://developer.chrome.com/docs/webstore/rollback). 24. Google Play Console, *Release app updates with staged rollouts*, and Apple App Store Connect, *Release a version update in phases*, accessed 22 September 2026, [https://support.google.com/googleplay/android-developer/answer/6346149](https://support.google.com/googleplay/android-developer/answer/6346149), [https://developer.apple.com/help/app-store-connect/update-your-app/release-a-version-update-in-phases](https://developer.apple.com/help/app-store-connect/update-your-app/release-a-version-update-in-phases). 25. Fuchsia, component framework and software update documentation, accessed 22 September 2026, [https://fuchsia.dev/fuchsia-src/concepts/components/v2/introduction](https://fuchsia.dev/fuchsia-src/concepts/components/v2/introduction), [https://fuchsia.dev/fuchsia-src/concepts/packages/software_update_system](https://fuchsia.dev/fuchsia-src/concepts/packages/software_update_system). 26. Extism project, README, manifest definition and Wasmtime runtime dependency, commit `1e281e93cdf189fbf4a753ee8f6ed8b5dceef29b`, accessed 22 September 2026, [https://github.com/extism/extism/blob/1e281e93cdf189fbf4a753ee8f6ed8b5dceef29b/README.md](https://github.com/extism/extism/blob/1e281e93cdf189fbf4a753ee8f6ed8b5dceef29b/README.md), [https://github.com/extism/extism/blob/1e281e93cdf189fbf4a753ee8f6ed8b5dceef29b/manifest/src/lib.rs](https://github.com/extism/extism/blob/1e281e93cdf189fbf4a753ee8f6ed8b5dceef29b/manifest/src/lib.rs), [https://github.com/extism/extism/blob/1e281e93cdf189fbf4a753ee8f6ed8b5dceef29b/runtime/Cargo.toml](https://github.com/extism/extism/blob/1e281e93cdf189fbf4a753ee8f6ed8b5dceef29b/runtime/Cargo.toml). 27. Abhinav Jangda, Bobby Powers, Emery D. Berger and Arjun Guha, *Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code*, 2019 USENIX Annual Technical Conference, pages 107-120, [https://www.usenix.org/conference/atc19/presentation/jangda](https://www.usenix.org/conference/atc19/presentation/jangda). 28. Sangeeta Kakati and Mats Brorsson, *An Investigative Study of WebAssembly Performance in Cloud-to-Edge*, 2024 International Symposium on Parallel Computing and Distributed Systems, DOI [10.1109/PCDS61776.2024.10743586](https://doi.org/10.1109/PCDS61776.2024.10743586). 29. Bytecode Alliance, *Sightglass README and benchmarking methodology*, commit `ee2d1fd224dbd713609a02457e63119c73af38b5`, accessed 22 September 2026, [https://github.com/bytecodealliance/sightglass/blob/ee2d1fd224dbd713609a02457e63119c73af38b5/README.md](https://github.com/bytecodealliance/sightglass/blob/ee2d1fd224dbd713609a02457e63119c73af38b5/README.md). 30. Alec Warner and Stepan Davidovic, with Alex Hidalgo, Betsy Beyer, Kyle Smith and Matt Duftler, *Canarying Releases*, Site Reliability Engineering Workbook, Google, [https://sre.google/workbook/canarying-releases/](https://sre.google/workbook/canarying-releases/). 31. Argo Project, *Canary Deployment Strategy*, accessed 22 September 2026, [https://argo-rollouts.readthedocs.io/en/stable/features/canary/](https://argo-rollouts.readthedocs.io/en/stable/features/canary/). 32. Bailey Hayes and Yosh Wuyts, *WASI 0.3 Launched*, Bytecode Alliance, 11 June 2026, [https://bytecodealliance.org/articles/WASI-0.3](https://bytecodealliance.org/articles/WASI-0.3); Eric Gregory, *The Road to Component Model 1.0*, Bytecode Alliance, 8 June 2026, [https://bytecodealliance.org/articles/the-road-to-component-model-1-0](https://bytecodealliance.org/articles/the-road-to-component-model-1-0). 33. The Indie Stone, *Patching a Zero Day Exploit*, Project Zomboid official announcement, 8 April 2026, [https://store.steampowered.com/news/app/108600/view/494973688019419974](https://store.steampowered.com/news/app/108600/view/494973688019419974).