Procesar PDFs en el navegador sin bloquear la interfaz: Web Workers y datos locales

Procesar un PDF puede requerir lectura binaria, renderizado de páginas, OCR, detección de datos y reconstrucción del archivo. Si todo ocurre en el hilo principal, la interacción puede deteriorarse en equipos lentos o con documentos complejos. En PriviTools movemos las tareas pesadas a Web Workers para que la interfaz pueda seguir respondiendo mientras el navegador trabaja.
No significa que todos los documentos se procesen en el mismo tiempo ni que una interfaz nunca pueda bloquearse. El rendimiento depende del archivo, la memoria disponible, el navegador y el dispositivo. Este artículo describe la arquitectura y sus límites verificables.
Qué aporta un Web Worker
Un Web Worker ejecuta JavaScript fuera del hilo que pinta la interfaz. Se comunica con la página mediante mensajes; no puede manipular directamente el DOM. Es útil para ejecutar trabajo de CPU o E/S local sin dejar la pantalla ocupada con un cálculo largo. MDN documenta el modelo y sus restricciones.
Para evitar copias innecesarias de datos grandes, los ArrayBuffer pueden transferirse entre el
hilo principal y un Worker. Tras la transferencia, el propietario original deja de usar ese
buffer; no se debe interpretar como una garantía de coste cero en todas las operaciones. MDN
explica los objetos transferibles.
Cómo se reparte el trabajo en PriviTools
La implementación usa Workers para tres familias de trabajo:
- Operaciones de PDF.
pdf-worker.tsrecibe una operación y delega en la biblioteca local de PDF. Los progresos vuelven al hilo principal como mensajes. - Censura automática.
auto-redact-worker.tsrecibe elArrayBufferdel archivo y las zonas aprobadas. El Worker devuelve una copia procesada y los avances por página. - Funciones de IA locales. Los Workers de PriviMind cargan los modelos configurados en el navegador y comunican su progreso y resultados a la interfaz.
La imagen de cabecera representa este flujo: interfaz, Workers aislados y mensajes de vuelta. No es un diagrama de rendimiento ni una promesa de que cada operación se ejecute sin espera.
Seguridad de los Workers
Un Worker no dispone de document. Para evitar regresiones, las pruebas del proyecto verifican
que los módulos que se ejecutan en Worker no dependan de APIs exclusivas del DOM y que dispongan
de una ruta con OffscreenCanvas para la rasterización. También validan que el motor PDF cargue
el build de navegador y conserve un worker real en vez de caer a un modo simulado.
Estas pruebas no sustituyen las pruebas de compatibilidad en todos los navegadores. Son una red de seguridad concreta contra fallos que ya pueden reproducirse en el código.
Qué comprobamos sobre el archivo
La prueba de privacidad genera un PDF con datos canario y vigila las solicitudes del navegador. Falla si un canario aparece en una URL o cuerpo de petición, si un cuerpo grande se envía a un tercero o si aparece un origen no aprobado. El conjunto permitido incluye recursos de la propia página y, cuando están habilitados, servicios de analítica o publicidad; la prueba no afirma que no exista tráfico de esos servicios. Afirma que el contenido del documento no apareció en las solicitudes vigiladas durante el flujo probado.
La prueba de censura descarga la copia resultante y busca los canarios en tres capas: bytes crudos, texto extraíble y metadatos. También verifica que el flujo encuentre los datos de prueba antes de calificarse como correcto. Esto es evidencia automatizada de un conjunto de casos, no una afirmación de detección perfecta para todos los formatos, idiomas o tipos de dato.
Límites que siguen siendo responsabilidad del usuario
- Revisa los hallazgos antes de censurar: la detección automática puede omitir o marcar datos incorrectamente.
- Prueba la copia descargada, no sólo la vista previa.
- Considera la memoria disponible: documentos grandes o con muchas imágenes pueden requerir más recursos que el equipo tenga libres.
- Verifica el resultado en los navegadores que forman parte de tu flujo de trabajo.
- No confundas procesamiento local con cumplimiento automático de RGPD, HIPAA u otra norma.
Para un flujo de redacción, el paso técnico se complementa con la guía de cómo censurar un PDF sin dejar el texto debajo y con una revisión de metadatos antes de compartirlo.
Cómo reproducir la evidencia
Las pruebas que respaldan estas afirmaciones viven junto al producto: privacy-no-exfiltration,
redaction-effectiveness y worker-safety. Para reproducirlas se necesita el entorno de prueba
del proyecto y los navegadores configurados. Al cambiar un Worker, una dependencia de PDF o la
política de red, se deben ejecutar de nuevo; la evidencia envejece con el código.
La idea central no es prometer latencia cero o privacidad matemática. Es hacer explícitas las fronteras: qué proceso se delega, qué se transfiere, qué se comprueba y qué sigue necesitando una revisión humana.
Cómo detectamos y retiramos variantes SEO huérfanas
Cómo censurar un PDF de forma irreversible: el rectángulo negro no basta