11-security.md

id	nuif:spec:security
kind	specification
status	draft

11 — Security and resource limits

Status: draft.

NUIF documents and extensions are untrusted input.

Implementations MUST bound decoded sizes, nesting depth, entity/relation counts, path segment counts, image/font sizes, decompression ratios and renderer resource allocations. Cyclic references MUST be detected where forbidden.

Executable profile-0 limits

An implementation claiming executable profile-0 conformance MUST accept values at these boundaries and MUST reject the first value above them as a resource-limit error:

Resource	Limit
encoded document bytes	16 MiB
text or CBOR syntax depth	64
entities	8,192
roots	4,096
tokens	8,192
relations	32,768
child references	8,191
responsive overrides	16,384
property values	65,536
property-value depth	24
containment depth	128
total retained string bytes	8 MiB
bytes in one string	1 MiB
total retained binary bytes	8 MiB
retained binary bytes in nuif-text-0	512 KiB

Stream readers MUST stop after reading the first byte beyond the encoded limit; reading an entire larger stream and checking afterward is non-conforming. Syntax depth MUST be checked outside quoted strings and comments. Semantic limits MUST be checked before recursive evaluation. Encoders MUST stop before producing the first byte beyond the encoded limit.

Validators MUST retain no more than 1,024 ordinary diagnostics plus one explicit truncation diagnostic. Implementations MAY use tighter operational limits when they are not making a profile-0 conformance claim, but MUST expose those limits to automation.

The reference conformance run measures each boundary and one-over case in a warmed release process. Its regression ceilings are 2 seconds, 64 MiB of allocator traffic and 16 MiB retained per case. These are reference-implementation CI ceilings rather than portable format semantics; the report MUST identify its allocator method, toolchain, build profile and hardware context.

Fonts, images, SVG/imported data, adapters and plugins require sandbox-aware handling. Script/data-binding extensions are non-core and MUST NOT execute merely by opening a document.

Package readers MUST reject duplicate/traversal/absolute/backslash paths, symlinks, directory entries, encryption, split archives, unsupported compression and inconsistent local/central metadata. Implementations MUST verify declared resource size and digest before image/font/media decoding and MUST NOT extract untrusted members to a filesystem.

Loading a package MUST NOT initiate network access. Linked resources require an explicit caller-supplied resolver and exact digest verification. Resource locators and provenance MUST NOT carry cookies, authorization values or other credentials.

Observation providers and model output are untrusted inputs. Reconstruction profiles MUST bound screenshots, observations, candidates, operations, iterations, model/tool calls, renders, time, memory and GPU use. Generated URLs and scripts are inert. Text visible in an image is input data and cannot alter tool authority, security policy or operation grammar.

Screenshot/capture records can contain personal, credential or proprietary information. Retention, remote inference, telemetry and training are separate purposes requiring explicit policy. Private/authenticated captures MUST default to no training.

Headless rendering MUST expose deterministic timeout/memory/resource budgets. GPU failures must not compromise process memory safety.

The experimental live Chromium capture segment runs each page in a fresh temporary profile and accepts only its ws://127.0.0.1 debugger endpoint. It caps one debugger message/frame at 32 MiB, queued events at 65,536 and their aggregate encoded bytes at 64 MiB, commands at 100,000, DOM nodes at 32,768, captured responses at 8,192, one response/screenshot at 16 MiB, total response bodies at 64 MiB, platform-font records at 64 per node and 32,768 total, and the WebSocket write buffer at 1 MiB. Browser startup and protocol I/O each have 10-second bounds, while the connected capture has a 30-second deadline. The discovery HTTP response is capped at 1 MiB and must contain a valid content length. Query/fragment values are removed before serialization; cookie, storage and request-header APIs are never read.

The live conformance fixture accepts only complete captures. A missing response body remains an omission in the adapter result; the harness may retry that viewport in a new isolated profile at most three times and records every attempt. Network response bodies are primary, Page resource content is a post-load fallback, and the canary probe body is retained only after its in-page response completes and is checked for reflected canary values.

Live capture still executes the target page inside Chromium and may cause its declared network behavior. The caller MUST authorize the target and apply network/process isolation appropriate to untrusted content. The experimental adapter MUST NOT import a user's persistent browser profile or credentials. Exact response bodies can themselves contain sensitive data, so their retention, transfer and training policy remains explicit even when transport canaries are absent.

Image, font, compressed-package, path-segment and GPU budgets are not part of executable CPU profile 0. Orthogonal resource profiles MUST calibrate and publish their own limits before claiming those resource classes.

The orthogonal experimental nuif-png-rgba8-0 image segment publishes a 32 MiB encoded-byte limit, 8,192-pixel limit per dimension, 16,777,216-pixel decoded limit and 4,096-chunk limit. Its inspector applies these bounds before inflation. Render scenes additionally cap unique decoded RGBA surfaces at 64 MiB, preflight each new surface, and deduplicate repeated digest/profile uses. Its two decoders verify datastream integrity. These limits do not authorize other PNG forms, non-PNG media, GPU allocation or inclusion in CPU render profile 0.

The orthogonal experimental nuif-opentype-static-single-0 segment publishes a 32 MiB encoded-byte limit, 256-table limit, 256-family-name limit, 65,536-coverage-range limit and 64-feature-setting limit. It validates sfnt search fields, sorted unique table records, exact contiguous zero-padded packing, per-table checksums and the whole-font checksum before accepting face metadata. Its warmed reference implementation additionally caps one inspection or packaged-font validation at 4 MiB allocator traffic and 2 MiB retained memory. The allocation ceilings are CI regressions rather than portable format semantics. These limits do not authorize other font containers/outlines, external/native rasterizer execution, redistribution or inclusion in CPU render profile 0. The separately gated reference composition shapes and rasterizes one accepted non-Ahem fixture under the same session/resource limits; it is not evidence that every accepted font is safe in an arbitrary downstream font stack.