Privacidad y manejo de datos

El producto de ofuscación de AfterPack maneja tu código y los datos de tu cuenta como se describe a continuación. Las cookies y los análisis de este sitio se cubren por separado, en la Política de privacidad.

Un build local no envía nada

Un build local ejecuta AfterPack como un binario nativo en tu máquina. Nada sale de tu sistema de archivos, así que las secciones sobre la nube que siguen no le aplican. La única llamada de red que hace un build local es el informe de telemetría descrito abajo, que se dispara solo cuando un build reporta un diagnóstico de nivel de error (un build rechazado o parcial), no lleva código fuente, y se puede desactivar.

Un build en la nube ofusca en memoria y no conserva nada

Cuando un build Pro envía código fuente a api.afterpack.dev para ser ofuscado, se procesa solo en memoria, durante la duración de esa única solicitud, y luego se descarta:

• La solicitud se ejecuta dentro de un isolate de Cloudflare Worker en sandbox que se destruye al terminar la solicitud. Nada sobrevive más allá de la respuesta.
• Los registros nunca llevan código fuente. Las líneas de log llevan un id de build, cantidad de archivos, totales de bytes, códigos de diagnóstico y la ruta de un archivo que falló. Nunca llevan el contenido de los archivos, nombres de identificadores ni valores de constantes.

Esto se cumple igual si llamas a la API directamente, a través de la CLI con AFTERPACK_key definida, o a través de un plugin de framework. Todos hablan el protocolo descrito en la referencia de la API en la nube.

Se almacena un artefacto: el Protection Map, descrito abajo, escrito después de que termina la ofuscación. El código fuente que subes para ofuscar sigue desapareciendo al final de la solicitud.

Qué llevan y qué no llevan los registros

Las métricas agregadas (conteos de solicitudes por día, bytes medidos por espacio de trabajo, tiempos de build) se guardan como contadores y no contienen código.

La telemetría está activada de forma predeterminada, y solo informa los diagnósticos de nivel de error de un build

El cliente puede informar diagnósticos de build anónimos para que los errores del motor se encuentren y se corrijan. Está activada a menos que la desactives. Un build limpio no tiene nada que informar:

• Solo un build que emite un diagnóstico error o critical envía algo. Un build limpio no envía nada en absoluto: ningún ping periódico, ningún tiempo de fase, ninguna estadística de uso para un build que simplemente funcionó.
• Desactívala con AFTERPACK_telemetry_enabled=false, --telemetry.enabled=false en la CLI, o telemetry: { enabled: false } en la configuración de tu integración. Esa es toda la superficie.
• Se ejecuta igual en CI. Ninguna verificación de TTY o CI cambia el valor predeterminado ni omite el informe; el payload simplemente registra ci: true, leído de la misma variable CI que tu pipeline ya define.
• Nunca hay un prompt. El primer build después de instalar imprime un aviso único (qué se recopila, qué no, cómo desactivarlo) y continúa. Nunca se bloquea esperando una respuesta. El estado (un id de instalación aleatorio que rota cada 30 días, y si el aviso ya se imprimió) vive en ~/.afterpack/telemetry.json.
• Las ejecuciones de prueba están exentas. NODE_ENV=test y el propio marcador VITEST de Vitest desactivan la telemetría.

Qué se recopila, cuando un build informa un diagnóstico de nivel de error

• El código del diagnóstico que falló, su severidad y el rango de desplazamiento en bytes, más una lista corta de campos tipados elegidos según el tipo de diagnóstico, nunca su mensaje de texto libre
• Las versiones del motor, del cliente y de Node, el sistema operativo/arquitectura, y el framework detectado
• Si el build se ejecutó en CI
• El nivel de complejidad: un preset con nombre, o custom para un valor directo de complexity
• La cantidad de archivos y la duración del build, agrupadas en rangos (5-20, 1-5s) en vez de exactas; un número exacto permite identificar un proyecto concreto
• Un id de instalación aleatorio que rota cada 30 días, nunca derivado de tu máquina o proyecto

Qué nunca se recopila, ni en telemetría ni de otra forma

• Código fuente o contenido de archivos
• Nombres de archivos y rutas de archivos en la telemetría. El log del lado del servidor de un build en la nube lleva una ruta, la del archivo que falló dentro del lote, como se describió arriba
• El texto del mensaje de diagnóstico, en ningún caso; solo su code estable
• Claves de API o credenciales
• Valores de constantes
• Las decisiones de codificación de cadenas
• Cualquier información que identifique al usuario más allá de lo que ya contiene tu cuenta

La telemetría tiene una forma fija.

Los Protection Maps de los builds en la nube se almacenan, y puedes desactivarlo

Un Protection Map es tu código fuente original, coloreado según cuánta transformación recibió cada token. En un build en la nube, AfterPack lo genera en el servidor que hizo la ofuscación y lo conserva, así que puedes abrir el mapa de cualquier build reciente desde el panel.

• Qué se almacena: los datos del mapa de cada build, tu código fuente original más las métricas por token detrás de los colores, compactados y comprimidos con gzip en Cloudflare R2, cifrados en reposo, más una fila de números de resumen para el panel. Tu salida ofuscada no se almacena.
• Delimitado a un proyecto, el proyecto al que está vinculada la clave del build.
• Legible solo por los miembros de ese espacio de trabajo. No es público, no está indexado, no tiene enlace para compartir.
• Retención: un año, y los últimos 500 builds por proyecto, lo que se cumpla primero. Un trabajo cada hora elimina lo que supere cualquiera de los dos límites. Para un proyecto que hace builds con frecuencia, el conteo es el límite que se alcanza primero. Esto limita cuántas copias de tu código fuente existen en un momento dado.
• Un mapa puede almacenarse parcial. Cuando un build tarda mucho, la captura se detiene antes que la ofuscación. El registro almacenado indica qué fragmentos se omitieron y por qué.
• Desactivarlo hace que los nuevos builds dejen de almacenar nada para ese proyecto. Los mapas ya almacenados caducan bajo la retención descrita arriba en vez de eliminarse de inmediato. Los builds locales no se ven afectados: el Protection Map que un build local escribe en .afterpack/ nunca sale de tu máquina.
• Qué se sigue registrando con esto desactivado: los números del build (cobertura, inflación, complejidad, tiempos), para que los gráficos del panel del proyecto sigan funcionando. Estos son agregados derivados de un build. No contienen código, y nada en ellos se puede leer de vuelta como código.

Subprocesadores

Un build en la nube involucra a estos procesadores. El código fuente pasa por Cloudflare solo en memoria mientras se ofusca; Cloudflare también es el único que llega a retener código fuente en reposo, como el Protection Map descrito arriba:

Residencia de datos

Las secciones anteriores responden si el código fuente se almacena. La residencia es la pregunta separada de dónde se procesa mientras una solicitud está activa, y dónde reside el mapa almacenado.

Ninguna de las dos está fijada a una región. Cloudflare enruta un build en la nube a una región cercana, y bajo failover o carga puede terminar en otra. No hay una región fija por solicitud, y el almacenamiento en R2 no está bloqueado a una región. Si necesitas una garantía firme de residencia, usa un build local. AfterPack se ejecuta enteramente en tu propia infraestructura, así que no surge ninguna pregunta de residencia.

DPA y cumplimiento

Un Acuerdo de Procesamiento de Datos (DPA) está disponible bajo solicitud. El DPA que firmas es el contrato legal y exigible, y remite a la lista de subprocesadores y al comportamiento de residencia descritos arriba.

Siguiente

• Referencia de la API en la nube: el protocolo de red al que aplican estas garantías.
• Modos de despliegue: local frente a nube, y qué envía cada uno.
• Protection Map: qué muestra el mapa almacenado, y dónde vive el interruptor por proyecto.
• Pro: qué obtienes en realidad al ejecutar en la nube.
• Espacios de trabajo y proyectos: quién puede leer qué, y cómo se delimita una clave.
• Panel: dónde se muestran un mapa almacenado y su registro de build.