Security Model

What parsers and components are and aren't allowed to do, and why the runtime owns file I/O.

Security Model

Parser and component code may be generated by an LLM and re-run automatically when a source changes. The spec treats that code as untrusted by default and puts the runtime, not the parser or component, in charge of anything privileged.

The core rule

The runtime owns file I/O. Neither the parser nor the component reads the source file or files, or any other file, directly.

 runtime  →  reads only declared source files
 runtime  →  invokes the Source Adapter over the original bytes
runtime  →  calls parser(input, context)
runtime  →  passes parser's output as `data` to the component
runtime  →  renders the component

If a parser or component needs something beyond input / data and context.settings, that needs to be a capability the runtime explicitly grants — not a filesystem call or a bare fetch() inside generated code.

Requirements

Parser and component code MUST NOT be given unrestricted filesystem access.
The Source Adapter MUST receive only the declared original bytes and runtime-scoped context; it must not discover additional files.
The runtime MUST read and adapt the original source again when opening or regenerating an MView; a normalized cache cannot be the source of truth.
For a directory source, the runtime MUST read only the files declared in source.files and MUST prevent escapes from source.path through absolute paths, .. segments, or symbolic links.
The runtime MUST NOT automatically extend the selection with other files present in the directory.
Parser and component code MUST NOT perform arbitrary network requests (fetch, XHR, WebSocket) without the runtime granting explicit, scoped permission.
The runtime MUST catch parser errors and render errors separately, and present the user with a controlled error state rather than crashing the host application.
The runtime MUST offer a way to regenerate the parser or component independently after a failure.

Execution strategies (non-normative)

The spec does not mandate how a runtime isolates parser/component execution — only the guarantees above. Reasonable approaches, in increasing order of isolation:

Compile with Vite/esbuild and load as a module in the host process, relying on the contract (no fs/network APIs passed in) rather than hard sandboxing.
Execute inside an iframe with a restrictive sandbox attribute.
Execute inside a Web Worker with no DOM or filesystem access, message-passing data in.
Precompile at MView-creation time and treat the compiled artifact as the thing that ships, re-running codegen (not the compiled output) when regeneration is requested.

Pick the strategy that matches your host environment's trust model — a browser-based tool and a desktop app with local file access have different constraints. The invariant that must hold regardless of strategy: a compromised or buggy parser/component cannot read or write files the user didn't explicitly expose to it.

Regeneration

Because the adapter, parser, and component can change independently, a runtime should expose regeneration as three distinct actions, not one:

Regenerate Source Adapter — when the physical format, encoding, or decoder needed to read the source changed.
Regenerate Parser — when the source shape changed (e.g. a renamed column or the selected files in a directory) but the visual design is still correct.
Regenerate Component — when the data model is fine but the presentation needs to change.
Regenerate Full MView — start over from the declared source.

Modelo de seguridad

Qué pueden y no pueden hacer parsers y componentes, y por qué el runtime es dueño de la E/S de archivos.

Modelo de seguridad

El código de parser y componente puede ser generado por un LLM y volver a ejecutarse automáticamente cuando cambia una fuente. La especificación trata ese código como no confiable por defecto y deja al runtime, no al parser ni al componente, a cargo de todo lo privilegiado.

La regla central

El runtime es dueño de la E/S de archivos. Ni el parser ni el componente leen directamente el archivo o los archivos fuente ni ningún otro archivo.

 runtime  →  lee solo los archivos fuente declarados
 runtime  →  invoca el Source Adapter sobre los bytes originales
runtime  →  llama a parser(input, context)
runtime  →  pasa la salida del parser como `data` al componente
runtime  →  renderiza el componente

Si un parser o componente necesita algo más allá de input / data y context.settings, eso debe ser una capacidad que el runtime conceda explícitamente: no una llamada al filesystem ni un fetch() directo dentro del código generado.

Requisitos

El código del parser y del componente NO DEBE recibir acceso irrestricto al filesystem.
El Source Adapter DEBE recibir únicamente los bytes originales declarados y el contexto acotado por el runtime; no debe descubrir archivos adicionales.
El runtime DEBE volver a leer y adaptar la fuente original al abrir o regenerar una MView; una caché normalizada no puede ser la fuente de verdad.
Para una fuente de directorio, el runtime DEBE leer únicamente los archivos declarados en source.files y DEBE impedir escapes de source.path mediante rutas absolutas, segmentos .. o enlaces simbólicos.
El runtime NO DEBE ampliar automáticamente la selección con otros archivos presentes en el directorio.
El código del parser y del componente NO DEBE realizar solicitudes de red arbitrarias (fetch, XHR, WebSocket) sin que el runtime conceda permiso explícito y acotado.
El runtime DEBE capturar errores del parser y errores de render por separado, y presentar al usuario un estado de error controlado en lugar de romper la aplicación host.
El runtime DEBE ofrecer una forma de regenerar el parser o el componente de manera independiente después de una falla.

Estrategias de ejecución (no normativas)

La especificación no exige cómo un runtime aísla la ejecución de parser/componente; solo exige las garantías anteriores. Enfoques razonables, de menor a mayor aislamiento:

Compilar con Vite/esbuild y cargar como módulo en el proceso host, confiando en el contrato (sin entregar APIs de fs/red) en lugar de usar un sandbox fuerte.
Ejecutar dentro de un iframe con un atributo sandbox restrictivo.
Ejecutar dentro de un Web Worker sin acceso al DOM ni al filesystem, pasando data por mensajes.
Precompilar al momento de creación de la MView y tratar el artefacto compilado como lo distribuido, reejecutando codegen (no la salida compilada) cuando se solicite regeneración.

Elige la estrategia que calce con el modelo de confianza de tu entorno host: una herramienta basada en navegador y una app desktop con acceso a archivos locales tienen restricciones distintas. La invariante que debe mantenerse sin importar la estrategia: un parser/componente comprometido o defectuoso no puede leer ni escribir archivos que el usuario no expuso explícitamente.

Regeneración

Como adapter, parser y componente pueden cambiar de manera independiente, un runtime debería exponer la regeneración como acciones separadas:

Regenerar Source Adapter — cuando cambió el formato físico, la codificación o el decoder necesario para leer la fuente.
Regenerar parser — cuando cambió la forma de la fuente (por ejemplo, una columna renombrada o la selección de archivos de un directorio) pero el diseño visual sigue siendo correcto.
Regenerar componente — cuando el modelo de datos está bien, pero la presentación debe cambiar.
Regenerar MView completa — partir de nuevo desde la fuente declarada.