Volver al Blog
Plataforma

Origin Private File System: handles, workers y límites de privacidad

Comprende el aislamiento por origen de OPFS, los handles, el acceso desde workers, la cuota y la validación que protege la privacidad.

BotBrowser Team

Documentación

Quieres la documentación estructurada de Plataforma?

Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.

Origin Private File System (OPFS) ofrece a cada origen web un área de archivos privada administrada por el navegador para los datos de la aplicación. No es la carpeta de descargas visible para el usuario y está sujeta a las políticas de almacenamiento del navegador. Un handle identifica una entrada dentro de esa área; no es una ruta universal ni autoriza el acceso desde otro origen. BotBrowser puede repetir un flujo de página autorizado y registrar resultados visibles, pero no puede eludir las comprobaciones de origen, conceder cuota ni garantizar la durabilidad en todos los dispositivos.

Dos orígenes tienen áreas de archivos privadas separadas; cada worker accede solo a los archivos de su propio origen.

Qué aísla OPFS

navigator.storage.getDirectory() devuelve el directorio raíz privado del origen. Los archivos y directorios creados debajo quedan asociados al origen y al perfil del navegador. Una página en https://a.example no puede resolver un handle creado por https://b.example, aunque ambas aplicaciones utilicen el mismo nombre de archivo. Los archivos privados también son distintos de los archivos que el usuario elige mediante un selector. La guía de OPFS de MDN describe este modelo y la vida útil administrada por el navegador.

Los handles son capacidades dentro de ese límite. FileSystemFileHandle identifica una entrada de archivo y FileSystemDirectoryHandle, un directorio. Se puede guardar un handle en IndexedDB para volver a abrirlo, pero la aplicación debe contemplar una entrada ausente, un registro renombrado o un perfil borrado. Trátalo como estado opaco de la aplicación, no como una ruta para mostrar o enviar a un servidor.

El límite corresponde al origen, no a una cuenta. Varias personas del mismo origen pueden compartir un perfil, y una persona puede tener varios perfiles. No conviertas el éxito al buscar un handle en una señal de identidad. Su ausencia puede significar primer uso, eliminación, limpieza del navegador, otro perfil o una migración de la aplicación.

Handles y acceso desde workers

Los workers pueden acceder a la raíz de OPFS, lo que permite realizar análisis e indexación fuera del hilo de interfaz. El worker sigue perteneciendo al mismo origen y perfil; no se convierte en un servicio de archivos entre orígenes. Los workers dedicados pueden usar handles de acceso síncrono en contextos compatibles; los métodos asíncronos son la opción de referencia más portable. Detecta la capacidad en el contexto real y ofrece una alternativa.

Define un protocolo explícito para los handles. La página puede enviar una orden limitada al worker, que devuelve un estado o un resultado derivado. No envíes credenciales, archivos completos ni un canal de mensajes ilimitado si basta con una operación pequeña. Valida el origen del mensaje y el nombre de la operación; cierra el worker cuando termine la tarea.

La escritura concurrente requiere una regla de la aplicación. Un worker y una pestaña pueden tener el mismo handle; el navegador no decide qué actualización funcional prevalece. Usa una revisión, un bloqueo controlado por la aplicación o un formato transaccional. Escribe un registro completo, actualízalo o ciérralo según la API y publica la nueva revisión. Si el worker termina durante una escritura puede quedar un registro incompleto: la recuperación debe distinguir entre «no iniciada», «confirmada» y «resultado desconocido tras la interrupción».

Resultados de cuota y persistencia

OPFS consume la cuota de almacenamiento del navegador. navigator.storage.estimate() ofrece una estimación, no una promesa de capacidad, y otra pestaña u origen puede cambiar el espacio disponible. Una escritura puede fallar por cuota, permisos o políticas, o por un error propio de la implementación. La interfaz debe conservar la entrada del usuario e indicar el siguiente paso, sin afirmar que el archivo se guardó.

La persistencia se solicita, no se garantiza. navigator.storage.persist() puede devolver true o false según la política del navegador, la actividad, el dispositivo y las reglas de navegación privada. true describe el origen y perfil actuales; no promete una copia de seguridad, exportación ni supervivencia si el usuario borra los datos. Documenta la retención y ofrece una exportación explícita para datos importantes.

Usa las observaciones de cuota para planificar capacidad, nunca para crear una huella digital. Registra resultados generales, como saved, quota-full o storage-unavailable; evita conservar la capacidad exacta del dispositivo o una firma de almacenamiento duradera. Borra los datos de diagnóstico al acabar la prueba y conserva datos de cuenta en el servidor solo cuando el propósito del producto lo requiera.

Validación que protege la privacidad

Usa un origen de prueba y un perfil limpio con datos sintéticos. Crea un archivo pequeño, léelo desde el mismo origen e intenta la misma operación desde un segundo origen. El resultado esperado es funcional: el segundo origen no puede resolver el handle del primero. Esto no demuestra la identidad de nadie, el fabricante del navegador ni el comportamiento de todas las API de almacenamiento.

Prueba por separado los recorridos de página y worker: crea un archivo en una página, léelo desde un worker, termina el worker durante una escritura y vuelve a abrir el registro. Anota la familia y versión del navegador, la clase de origen, el estado del perfil, el resultado y la alternativa visible. No subas documentos reales ni recopiles listados completos de directorios. Tras actualizar el navegador, compara la misma fixture sin cambiar a la vez el perfil, la versión de la aplicación y la política de almacenamiento.

La especificación de File System Access API y el estándar de almacenamiento WHATWG definen interfaces y conceptos de almacenamiento, no resultados de negocio. Una llamada exitosa solo demuestra que la operación funcionó en ese contexto. La autorización del servidor, el cifrado, la retención y la recuperación siguen siendo responsabilidad de la aplicación.

Límite del producto y recuperación

Explica si un borrador permanece en este navegador, se exporta a un archivo elegido o se sube a una cuenta. Conserva el borrador local hasta que el usuario confirme la exportación o la carga. Ofrece una acción clara para borrar los archivos privados y mantén la página utilizable cuando OPFS no esté disponible. Una página propia de recuperación puede restaurar un registro de cuenta autorizado, pero no copiar en silencio archivos privados de otro origen.

Si un handle queda obsoleto, distingue un espacio vacío de un fallo de red. Para el primer uso, muestra la configuración; ante un fallo transitorio, ofrece reintentar; si se borró el perfil, ofrece recuperación o exportación. El texto de estado accesible debe explicar el resultado sin revelar el nombre privado del archivo ni el identificador de cuenta.

BotBrowser puede repetir un flujo OPFS autorizado en un perfil declarado y comparar resultados visibles entre versiones compatibles del navegador. No controla la cuota, la decisión de persistencia, el aislamiento por origen, la planificación de workers ni la retención del servidor. Considera la ejecución evidencia del recorrido probado y anota el navegador, perfil, versión de la aplicación y alternativa.

Fuentes y lecturas relacionadas

El siguiente paso seguro es ejecutar una fixture de dos orígenes, página y worker, con datos sintéticos y una alternativa explícita para cuota insuficiente o almacenamiento no disponible.

TL;DR

  • Los archivos OPFS pertenecen a un origen y perfil; un handle no es una ruta compartida ni una identidad.
  • Los workers comparten el origen, pero las escrituras concurrentes necesitan revisiones y recuperación.
  • Cuota y persistencia son condicionales; conserva la entrada y ofrece exportación o alternativa.

Contents

Conclusion

OPFS es un espacio limitado al origen, no una identidad entre sitios ni una copia de seguridad. Mantén opacos los handles y recuperables las escrituras de workers. Consulta partición del almacenamiento y Web Locks.

Sources

#OPFS#File System Access API#Workers#Privacidad Del Navegador

Lleva BotBrowser de la investigación a producción

Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.