Files

T

Sergio 02513b861f atuq: sct v1 — el navegador avisa cuando un sitio ya estable ejecuta código que nadie vio nunca

La unidad 6 del SDD 26, que es el diferenciador del §6 que no tiene ningún navegador. Cadena entera,
medida de punta a punta con un servidor HTTP real y seis cargas de página:

    servidor HTTP → filterResponseData → connectNative → /usr/lib/mozilla/native-messaging-hosts/
                  → puriy-costura --state → puriy-sct (TOFU + bitácora)

    carga 1-3 (mismo script)          fase=learning  eventos=0   insignia vacía
    carga 4   (mismo script)          fase=stable    eventos=0   insignia vacía
    carga 5   (mismo script, estable) fase=stable    eventos=0   insignia vacía   ← control
    carga 6   (script CAMBIADO)       fase=stable    eventos=1   insignia "1"
              EVENTO ext:…/app.js 0ff4771fb797→f7ccb9fedfbd +27B

La extensión NO hashea ni guarda nada: ve bytes y pregunta. El registro es `puriy-sct`, del otro lado
del cable — duplicarlo en JS habría sido un segundo registro que se desalinea del primero, y el
primero es el que está certificado sin red.

CINCO COSAS QUE SE MIDIERON EN VEZ DE SUPONERSE, y las cinco fallan calladas:

1. el manifiesto va en `/usr/lib/mozilla/native-messaging-hosts/` y NO en el appdir: la ruta sale de
   `XRESysNativeManifests`, un `/usr/lib/mozilla` COMPILADO dentro de Gecko;
2. **el manifiesto no puede llevar argumentos** — `NativeMessaging.sys.mjs` hace
   `command = manifest.path` y los únicos argumentos son `[ruta-del-manifiesto, id]`. Y sin `--state`
   el host corre en MEMORIA: cada arranque volvería a «aprendiendo» y nada alertaría nunca. De ahí el
   lanzador `bin/puriy-costura-host`, que además decide la ruta del estado — dónde vive el estado de
   un usuario es layout del FHS, o sea asunto de la distro y no del crate;
3. `filterResponseData` y el permiso `webRequestFilterResponse` SÍ están en nuestro `omni.ja`
   (se le preguntó al artefacto, no a la documentación de Mozilla);
4. los scripts `inline` NO se ven por esta vía —`filterResponseData` entrega el cuerpo de una
   PETICIÓN— y para v1 alcanza: el ataque que sct nombra es la sustitución en el CDN;
5. ⚠ **una carga de página puede producir dos peticiones del mismo documento, y una llega con
   `tabId = -1`.** La primera versión agrupaba por `(tabId, documento)` y contaba esa carga como DOS
   visitas. No es cosmético: inflar las visitas estabiliza el origen ANTES de conocer su código real,
   y entonces alerta por churn legítimo — el falso positivo que la spec de puriy-sct pide evitar por
   encima de todo. Ahora agrupa por documento (dos pestañas con la misma url cuentan UNA: es el error
   seguro, tarda más en proteger y no alerta de más) y el guardián VIGILA el invariante «una carga,
   una visita», así que si vuelve, falla ruidoso.

DOS CORRECCIONES DEL PROPIO §6.1, que decía «consulta al testigo antes de dejarla pasar»: el cable
del testigo es un POST con postcard, así que un JS no puede ser su cliente; y v1 OBSERVA Y AVISA, no
bloquea — es lo que puriy-sct dice de su propia v1, y poner un viaje entre procesos en el camino
crítico de cada script de cada página no es «más seguro», es un navegador que nadie usa.

EL AVISO SE MIDE, NO SE SUPONE: la extensión relee la insignia con `getBadgeText` después de ponerla,
y el guardián exige vacía en las cinco cargas sin novedad y "1" en la del script cambiado. Es la única
parte de la cadena que el usuario ve; dejarla en «se llamó a la API» era dejar sin medir el final.

CONTROL NEGATIVO: `--negative-control` borra el manifiesto y exige que NO haya veredicto — o sea que
el veredicto de la corrida positiva viene del host y no de la extensión inventándolo.

Y el aviso pasivo es decisión, no falta de tiempo: insignia y tooltip, no modal. Un modal por cada
despliegue de un sitio entrena a la gente a cerrarlo sin leer, y entonces el que importa también se
cierra.

Además: `rebrand.py` instala y CRUZA los manifiestos nativos (que el `path` exista y sea ejecutable
dentro del artefacto, y que sus `allowed_extensions` sean extensiones que de verdad empaquetamos), y
de paso se corrige el comentario del §4.ter que repetía la afirmación falsa sobre quién instala las
extensiones — lo mide `scripts/test-atuq-instalacion.py`: instala el escaneo de la carpeta.

`runtime = [..., "puriy-costura"]` en atuq.toml: sin eso la imagen llevaría manifiesto y extensión y
el host NO estaría, y la función se apagaría sola sin una línea de error. `yupana radio` confirma que
llega a las cuatro imágenes de escritorio.

⚠ Límite escrito en `fondo.js`, en el `lib.rs` del host y en los dos LEEME: se hashea el TEXTO ya
decodificado que entrega la extensión, no los bytes que sirvió el servidor. Vale para comparar dos
cargas nuestras; NO es comparable con el hash que publique un tercero sobre los bytes servidos, ni
con el de la v2, que engancha el script loader y ve los bytes reales.

Y una segunda cosa que el guardián encontró y que es del PRODUCTO, no del test: **la página que abre
el navegador al lanzarse puede no ser observada** — compite con la inicialización de la extensión, y
la carrera se gana o se pierde según la corrida. En uso real sólo afecta a esa primera página (después
la extensión ya está escuchando). Por eso las aserciones van sobre la SECUENCIA OBSERVADA y no sobre
un calendario: se exige que ninguna carga se observe dos veces, que la única que puede faltar sea la
del arranque, y que la secuencia aprender→estabilizar→no-alertar→alertar sea la correcta.

Sin regresiones: `test-atuq-politica.py` («guardianes: todos correctos», y sus cinco roturas siguen
matando el build con tres extensiones) y `test-atuq-inicio.py` (la home y la pestaña nueva siguen
siendo las nuestras) pasan sobre el artefacto final `b3:d3ced586`.

2026-09-10 01:57:07 +00:00

16 KiB

Raw Blame History

atuq — el envoltorio Gecko de la distro

atuq (quechua: zorro) es el navegador de la distro: un artefacto DERIVADO de firefox, no un fork de su fuente. El diseño completo está en docs/26-atuq-envoltorio-gecko.md.

Este directorio ES la fuente de atuq — recipes/atuq.toml lo declara con source.dir y takana lo hashea por CONTENIDO. Editar un fichero de acá mueve el ArtifactHash; no hay commit que pinear.

⚠ Y ESTE README también entra en el hash. O sea que escribir acá el resultado de una medición invalida el artefacto sobre el que se midió: el hash que un párrafo cita es siempre el PREDECESOR del vigente. Es esperable y no es deuda —el rebuild son 6 s mientras el firefox vigente esté sellado—, pero hay que saberlo antes de leer un hash de acá y pensar que el fichero quedó viejo. Los guardianes de scripts/test-atuq-*.py se NIEGAN a medir un artefacto que no sea el vigente (por eso el ciclo es: editar todo → resellar una vez → medir), y cada reselle deja 340 M más en el store: conviene juntar las ediciones en una.

Qué hay acá y dónde cae

Acá	En el artefacto	Qué hace
`prefs/autoconfig.js`	`defaults/pref/autoconfig.js`	Le dice a Gecko que lea `atuq.cfg`. Es el único gancho posible antes de que arranque el perfil.
`atuq.cfg`	`<appdir>/atuq.cfg`	Prefs de fábrica + carga la hoja de estilo del chrome.
`chrome/atuq.css`	`<appdir>/chrome/atuq.css`	El aspecto. Se registra como USER_SHEET desde `atuq.cfg` — el mismo nivel de cascada que `userChrome.css`, para que el usuario pueda pisarlo. (Decía AGENT_SHEET; el fichero nunca lo usó, y AGENT_SHEET además alcanzaría al contenido de las páginas.)
`distribution/policies.json`	`<appdir>/distribution/policies.json`	Política de fábrica: telemetría, updates, el MODO y la CONFIG de las extensiones (no su instalación — ver más abajo), los CONTENEDORES y la config de fábrica del proxy.
`extensions/inicio/`	`<appdir>/distribution/extensions/inicio@atuq.tawasuyu.xpi`	Página de inicio y pestaña nueva.
`extensions/proxy/`	`<appdir>/distribution/extensions/proxy@atuq.tawasuyu.xpi`	Proxy por contenedor (SDD 26 §6.8).
`extensions/sct/`	`<appdir>/distribution/extensions/sct@atuq.tawasuyu.xpi`	Transparencia de scripts (SDD 26 §6.1).
`native-messaging/*.json`	`/usr/lib/mozilla/native-messaging-hosts/`	El manifiesto del host nativo. Fuera del appdir — ver abajo.
`bin/puriy-costura-host`	`<appdir>/puriy-costura-host`	El lanzador del host: le pone el `--state` que el manifiesto no puede.

Quién instala las extensiones — y este README decía lo contrario

Las instala el ESCANEO de distribution/extensions/. ExtensionSettings de la política las FIJA y las CONFIGURA; instalarlas, no.

⚠ Esta sección decía justo lo contrario —que el sideloading desde la carpeta «ya no funciona» y que instalaba la política— y era falso. Los dos mecanismos apuntan a los MISMOS ficheros, así que ninguna observación del artefacto los distingue y la política parece ser la que instala. Para saberlo hay que romper uno por vez, y eso es lo que hace scripts/test-atuq-instalacion.py (tres escenarios, medidos el 2026-09-09 sobre atuq b3:fab2fbfb y repetidos sobre b3:9e16ac35):

escenario	qué se rompe	resultado
`as-is`	nada	las dos extensiones puestas; la home es la nuestra
`no-policy`	`policies.json` sin `ExtensionSettings`	siguen puestas y la home sigue siendo la nuestra ⇒ instala la carpeta
`policy-only`	los XPI mudados fuera de la carpeta, con la política apuntando a la ruta nueva	no aparecen y la home vuelve a `about:home` ⇒ `install_url` con `file://` no instala nada

En las tres corridas hay un CONTROL por construcción: una extensión sonda que vive en la carpeta y que ninguna política nombra. Si la sonda habla, el escaneo está vivo en esa corrida; una corrida muda se declara rota en vez de leerse como «no instaló».

Consecuencias prácticas para quien agregue una extensión:

el XPI tiene que quedar en distribution/extensions/ — es lo único que la instala;
la entrada en ExtensionSettings no es opcional por eso: es la que la deja normal_installed (el usuario la puede quitar) y la que le entrega su storage.managed por 3rdparty.Extensions;
extensions.autoDisableScopes = 0 en atuq.cfg es lo que evita que el escaneo las instale desactivadas;
el location que extensions.json le pone al complemento no dice de qué mecanismo salió: medido, los instalados por la carpeta también salen app-profile.

Una extensión nueva no cuesta nada, y su id tiene un solo dueño

extensions/<lo-que-sea>/ con un manifest.json adentro y ya: rebrand.py recorre el directorio, saca el id de browser_specific_settings.gecko.id —no de una constante suya— y escribe <id>.xpi. El icono lo inyecta desde branding/icons/atuq128.png, así que tampoco hay que copiarlo en cada extensión: la v0.4 tenía ese PNG duplicado byte a byte y con dos extensiones habrían sido tres copias que se desalinean en cuanto alguien actualice una sola.

Y después cruza los ids contra policies.json, en los dos sentidos: una extensión empaquetada que la política no declara, o una política que apunta a un XPI que no existe, matan el build. Lo mismo con la ruta: el install_url tiene que ser exactamente donde el XPI quedó escrito. Antes eso era una constante contra otra constante; ahora una de las dos se DERIVA del fichero real.

scripts/test-atuq-politica.py le pone delante las cinco formas conocidas de romper ese cruce y exige que las cinco maten el build (más un control con la política intacta, que tiene que pasar).

El proxy por contenedor (§6.8)

Tres piezas, y ninguna alcanza sola:

atuq.cfg prende los contenedores (privacy.userContext.enabled), que Firefox trae apagados;
policies.json los CREA con Containers.Default —el único mecanismo que los pone en un perfil NUEVO— y deja la config de fábrica del proxy en 3rdparty.Extensions, que es de dónde la extensión lee su storage.managed;
extensions/proxy/ los enruta con proxy.onRequest, que es lo único que ve el cookieStoreId de cada petición.

La config se escribe por nombre de contenedor y no por cookieStoreId: el id depende del orden en que se crearon, así que la misma configuración aplicada a otro perfil apuntaría a otro contenedor. Dos capas: storage.managed es la de fábrica (la distro) y storage.local la del usuario, que pisa por contenedor.

⚠ Es separación de tráfico, NO anonimato, y eso está escrito arriba de todo en la propia página de opciones, no en un pie de página. No toca la huella del navegador.

Fail closed. Un contenedor que TIENE proxy configurado y no se pudo honrar no sale directo: va a un destino cerrado (127.0.0.1:9) y el navegador muestra el error. Salir directo sería una fuga silenciosa, que es la peor forma de este fallo. Y proxyDNS viene prendido: sin él la consulta DNS sale por la línea que se quería evitar.

`sct` — transparencia de scripts (§6.1)

La joya del §6, y la primera pieza de atuq que habla con la suite. Qué hace: por cada carga de página, la extensión intercepta el cuerpo de cada <script src> con filterResponseData y se lo pasa al host nativo; el host —puriy-costura, que por dentro es puriy-sct— lo hashea con BLAKE3, aprende el conjunto de código estable de cada origen (TOFU) y avisa cuando un sitio ya estable ejecuta código que nadie vio nunca. Eso es el síntoma de un CDN envenenado, una cadena de suministro comprometida o un script dirigido a un usuario, y no lo tiene ningún navegador.

La extensión no hashea ni guarda nada. Ve bytes y hace preguntas; el registro es del núcleo del otro lado del cable. Duplicarlo en JS habría sido un segundo registro que se desalinea del primero, y el primero es el que está certificado sin red.

servidor HTTP → filterResponseData → connectNative → /usr/lib/mozilla/native-messaging-hosts/
              → puriy-costura --state → puriy-sct (TOFU + bitácora fork-proof)

Cinco cosas de esta cadena que no se pueden deducir, y por eso se midieron

El manifiesto va en /usr/lib/mozilla/native-messaging-hosts/, NO en el appdir. Gecko saca esa ruta de XRESysNativeManifests, que en Linux es un /usr/lib/mozilla compilado: el rebranding a atuq no lo mueve. Y nadie más en el corpus escribe ahí (comprobado sobre el store), así que la ruta es de atuq.
El manifiesto NO puede llevar argumentos. En omni.ja, modules/NativeMessaging.sys.mjs hace let command = hostInfo.manifest.path y le pasa sólo [ruta-del-manifiesto, id-de-la-extensión]. Como puriy-costura sin --state corre todo en memoria —y entonces cada arranque del navegador volvería a «aprendiendo» y nada alertaría nunca—, hace falta el lanzador bin/puriy-costura-host. Es la peor forma de fallo: la función existe, no falla, y no protege de nada.
filterResponseData y el permiso webRequestFilterResponse existen en NUESTRO build (están en omni.ja, chrome/toolkit/content/extensions/schemas/web_request.json). Se preguntó al artefacto antes de escribir la extensión, no a la documentación de Mozilla.
Los scripts inline no se ven por esta vía, y no es un agujero disimulado: filterResponseData entrega el cuerpo de una PETICIÓN, y un inline viaja dentro del HTML. El ataque que sct nombra es la sustitución en el CDN, o sea exactamente el caso <script src>. Los inline los ve la v2, con el gancho en el script loader de Gecko.
Una carga de página puede producir MÁS DE UNA petición del mismo documento, y una llega con tabId = -1. La primera versión agrupaba por (tabId, documento) y contaba esa carga como DOS visitas. No es cosmético: inflar las visitas estabiliza el origen antes de tiempo, y un origen estabilizado antes de conocer su código real alerta por churn legítimo — el falso positivo que la spec de puriy-sct pide evitar por encima de todo. Ahora se agrupa por documento, y scripts/test-atuq-sct.py vigila el invariante: una carga, una visita.

v1 observa y avisa; no bloquea — y eso es del diseño

El §6.1 escribió «consulta al testigo antes de dejarla pasar». La forma fuerte es la v2. Acá se observa y se avisa por dos razones: puriy-sct es explícito en que su v1 alerta y no bloquea (bloquear necesita antes la acción del usuario, que es su M1), y poner un viaje ida-y-vuelta entre procesos en el camino crítico de cada script de cada página no es «más seguro»: es un navegador que nadie usa.

El aviso es pasivo: una insignia en la barra con el número de scripts nuevos y, en el tooltip, sus nombres. No un modal — un modal por cada despliegue entrena a la gente a cerrarlo sin leer, y entonces el que importa también se cierra.

⚠ Y el límite que hay que decir primero: se hashea el TEXTO ya decodificado que la extensión entrega, no los bytes que sirvió el servidor. La detección vale —el TOFU compara lo mismo contra lo mismo—, pero ese hash no es comparable con el que publique un tercero sobre los bytes servidos.

scripts/test-atuq-sct.py mide la cadena entera con un servidor HTTP real y seis cargas de página, y trae dos controles: la quinta carga repite el MISMO script ya estable y no debe alertar, y --negative-control borra el manifiesto y exige que no haya veredicto — o sea que el veredicto de la corrida positiva viene del host y no de la extensión inventándolo.

Por qué el CSS no es `userChrome.css`

userChrome.css vive en el PERFIL del usuario y exige que el usuario prenda toolkit.legacyUserProfileCustomizations.stylesheets. Una distro no puede depender de eso: el navegador tiene que verse como atuq la primera vez que arranca, con un perfil recién creado. La vía que sí funciona a nivel de aplicación es el nsIStyleSheetService desde autoconfig, que es lo que hace atuq.cfg.

La marca

El arte viene de un tablero de identidad del operador (2026-09-05): un zorro en medallón con cenefa andina, sobre disco teal y anillo noche.

branding/icons/atuq{16,32,48,64,128,256}.png — el medallón recortado del tablero, con máscara circular y alfa, reducido con LANCZOS desde un master de 1024 px. Se generan una vez y se copian; no se dibujan en cada build.
La paleta del chrome se muestreó del propio medallón, tomando el color más frecuente de cada zona, en vez de estimarla a ojo: #c15728 el zorro, #1b6470 el disco, #04161d el anillo, #f5ecde los reflejos. Un token escrito «parecido» es cómo una identidad se desalinea de su logo en tres ediciones.
Del tablero se toman la forma y el color; los eslóganes NO — el operador los descartó explícitamente. brand.ftl lleva el nombre y nada más.

⚠ A 16 px el medallón pierde el detalle y queda como una mancha cálida redonda. Es intrínseco a un logo con cenefa, no un defecto del escalado: la salida sería un dibujo simplificado para ese tamaño, y eso lo decide quien dibujó el zorro.

El chrome se programa desde `atuq.cfg`, no abriendo `omni.ja`

Esto era un pendiente («el chrome de verdad dentro de omni.ja») y resultó ser dos cosas falsas. Medido con scripts/test-atuq-chrome.py sobre atuq b3:9e16ac35:

No hace falta entrar al zip para programar el chrome. atuq.cfg ya corre con privilegios —de ahí sale nsIStyleSheetService—, así que desde ahí se observa browser-delayed-startup-finished y se toca el gBrowser de CADA ventana. La sonda abre dos pestañas y las parte en dos, desde atuq.cfg, sin tocar omni.ja.

Y es la vía que hay que usar, no un atajo: re-empacar omni.ja pelea con el orden del jarlog del PGO —por eso el jarlog está aparcado—, así que cada función nueva del chrome que NO entre al zip es una que no compite con la optimización de arranque.
La vista dividida ya la trae el motor, y prendida. Firefox 154 lleva tabbrowser/tabsplitview.js (492 líneas), opentabs-splitview.mjs y split-view-footer.js dentro de browser/omni.ja, y defaults/preferences/firefox.js dice pref("browser.tabs.splitView.enabled", true). La sonda lo ejercita de verdad — gBrowser.addTabSplitView([t1, t2]) ⇒ activeSplitView puesta y splitViewBrowsers.length == 2 — así que no es «existe el fichero»: funciona en nuestro build. No hay nada que escribir acá.

⚠ Lo que esto NO dice: atuq todavía no lleva JS de chrome propio. Lo medido es el GANCHO, con la sonda inyectada por una capa de overlay que no viaja en el artefacto. Cuando haya una función que lo justifique, el fichero va en chrome/atuq.js y lo carga atuq.cfg igual que la hoja de estilo.

El control negativo de la sonda sale del propio motor: addTabSplitView documenta que si TODAS las pestañas están fijadas borra el wrapper y devuelve null. --negative-control las fija y exige eso.

Lo que TODAVÍA no está

La v2 de sct: el gancho en el script loader de Gecko, que es lo único que ve los scripts inline y lo único que puede BLOQUEAR. Eso sí es parche del árbol (§2.bis).
Los otros verbos del §6 sobre el host que ya está puesto: descargas al CAS (6.2), archivo con RAG (6.3), torrent (6.9), IA local en la barra lateral (6.7). (El §6.8 ya no tiene pendientes: que una petición hecha en «Banco» sale por el proxy de «Banco» está probado por scripts/test-atuq-ruteo.py, que abre las dos pestañas por sessionstore y mira a qué puerto llama el navegador. Trae control negativo.)

16 KiB Raw Blame History