phishtriage

PhishTriage — política de privacidad

Esta es una traducción al español de la política de privacidad de PhishTriage. La versión jurídicamente vinculante es la versión en inglés, disponible en phishtriage.com/privacy. En caso de discrepancia entre la traducción y el texto en inglés, prevalece el texto en inglés.

Fecha de entrada en vigor: 4 de octubre de 2026 Versión: 1.10 Se aplica a: la extensión de navegador PhishTriage (Chrome, Edge, Firefox, Brave, Safari) en su versión 1.1.0 y posteriores, y los servicios de backend predeterminados en https://api.phishtriage.com y —solo con la protección de archivos activada— https://filescan.phishtriage.com.

Esta línea terminaba antes en Brave, mientras que la sección de protección de archivos que aparece más abajo trataba a Safari como una plataforma a la que esa función no llega. Una versión que distribuimos faltaba en la lista de versiones que cubre esta política, así que ahora figura aquí, con las dos formas en que se diferencia: la versión para Safari no tiene protección de archivos ni política de administrador. Safari no implementa ni las API de descargas que necesita la primera ni el almacenamiento administrado a través del cual se entrega la segunda, así que cada frase de este documento sobre la protección de archivos, y cada frase sobre lo que un administrador puede configurar en una flota administrada, describe las otras cuatro versiones y no esta.

Un segundo cliente llega al mismo backend, y hasta la versión 1.5 ninguna versión de este documento lo decía. api.phishtriage.com también atiende al filtro de mensajes de PhishTriage para iOS, que envía mensajes de texto para obtener un veredicto. No es la extensión del navegador, y nada de la extensión puede leer tus mensajes en ninguna plataforma. Pero es el mismo proxy, la misma ruta de análisis y el mismo operador, y una vía completa por la que circula contenido no estaba descrita en ninguna parte. Ahora se describe aquí, en Mensajes de texto. Esa sección cubre el filtro de mensajes y no pretende ser una política completa de la aplicación para iOS.

En resumen

Este párrafo ofrecía antes «un número para recordar: activeTab como único permiso obligatorio». El manifiesto del paquete que se descarga para revisarlo dice otra cosa, así que esta es la lista real.

Obligatorios en la instalación: activeTab, storage, scripting y, desde la versión 1.1.0 de la extensión, alarms, que permite que la extensión se active sola para volver a preguntar por una inscripción a la que el backend aún no ha respondido (consulta ID seudónimo), además del acceso a cinco hosts de correo (mail.google.com, outlook.office.com, outlook.office365.com, outlook.live.com, outlook.cloud.microsoft), que la extensión declara como patrones de coincidencia estáticos del script de contenido y que tu navegador, por lo tanto, concede cuando la instalas, nombrándolos en el aviso de instalación. El quinto, la dirección web más reciente de Outlook, es nuevo en la versión 1.1.0 de la extensión, así que la actualización a la 1.1.0 lo solicita: Chrome y Edge mantienen la extensión desactivada hasta que lo aceptas. Hasta la versión 1.8, este párrafo enumeraba cuatro hosts.

Opcionales, se solicitan solo cuando activas la función que los necesita y se pueden revocar desde la configuración de extensiones de tu navegador: chrome://extensions → PhishTriage → Detalles → Permisos en Chrome, Edge y Brave, about:addons → PhishTriage → Permisos en Firefox: webNavigation para la función Background protection, downloads para la protección de archivos y <all_urls> para cualquiera de las dos: ambas funciones lo piden, y activar solo una de ellas basta para que se te pida acceso a todos los sitios. Con ninguna de las dos activadas, nunca se solicita acceso a hosts más allá de los cinco hosts de correo anteriores. Hasta la versión 1.9, este párrafo llamaba threat monitoring a Background protection.

Quiénes somos

PhishTriage está operado por el equipo de PhishTriage. Para consultas de privacidad, solicitudes de eliminación de datos o cualquier otro asunto que cubra este documento, escribe a privacy@phishtriage.com.

El responsable del tratamiento (a efectos del Reglamento general de protección de datos, o RGPD —GDPR en inglés—, y del RGPD del Reino Unido) es el equipo de PhishTriage. Si tu organización ha implementado la extensión con un proxy de alojamiento propio (consulta «Alojamiento propio» más abajo), el responsable del tratamiento es tu organización, no nosotros, y este documento solo describe el comportamiento del lado del cliente; pide la política correspondiente a tu equipo de TI o a tu delegado de protección de datos.

Qué recopila la extensión y cuándo

Cuando haces clic en el botón Analyze (análisis a petición)

Hacer clic en el botón Analyze de la ventana emergente, del panel lateral o de la barra de herramientas de Gmail o de Outlook Web es lo que hace que se lea la página o el mensaje que tienes delante y se envíe para obtener un veredicto. Cuando haces clic, la extensión lee la pestaña —mediante el permiso activeTab en una página normal, y mediante el script de contenido ya cargado en los cinco hosts de correo, que no necesita activeTab— y envía al proxy configurado (de forma predeterminada api.phishtriage.com) una solicitud que contiene:

La solicitud también lleva tu ID seudónimo (se explica más abajo) y, si has registrado o vinculado una cuenta, el ID de tu extensión. El proxy pasa este contenido a un modelo y devuelve un veredicto estructurado (puntuación de riesgo, IOC —indicadores de compromiso— y acciones recomendadas). Qué modelo se usa, y en el hardware de quién, se explica en Dónde se realiza el análisis.

Este párrafo decía antes «el proxy reenvía una versión depurada de este contenido a la API de Claude de Anthropic para su análisis», y ambas mitades necesitan corrección. La primera mitad es el enrutamiento: Anthropic ya no es lo primero que se consulta y a menudo no se consulta en absoluto. La segunda mitad es la palabra depurada, que llevaba una implicación que no puede sostener. Da a entender que quitamos algo por tu bien. Lo que nombra en realidad es un paso que elimina marcadores de inyección de prompts —[INST], <|…|>, delimitadores de turno de Claude, etiquetas <system> de tipo XML y líneas que empiezan como una instrucción («IGNORE ALL PREVIOUS…»)— antes de que un modelo lea el contenido, además de los límites de longitud indicados más arriba. Existe para impedir que un correo hostil dé órdenes al analista. Elimina esos patrones y, cuando una línea empieza como uno de ellos, se lleva consigo el resto de esa línea. También se hacen otros tres cambios menores. En el cuerpo de un correo, se colapsan las largas series de caracteres invisibles que los boletines ponen tras su línea de vista previa para que la vista previa de la bandeja de entrada no muestre el cuerpo; nadie que lea el correo las ve. En los campos que se muestran en una sola línea, como el remitente, el asunto, los enlaces y los nombres de los archivos adjuntos, un salto de línea pasa a ser un espacio. Esos dos cambios están en lo que lee el modelo y en la solicitud que guardamos. El tercero se hace solo en la copia que lee el modelo, no en lo que guardamos: cuando el mensaje contiene cualquiera de los dos encabezados que ponemos sobre nuestros propios hallazgos para el modelo, «Facts about the message» y «Precomputed technical signals», esa copia lo marca con «(quoted)», para que el texto del mensaje no pueda hacerse pasar por el nuestro. No se elimina nada por tratarse de ti: ninguna dirección, ninguna URL y ningún nombre se quita por motivos de privacidad. Lo que llega al modelo es lo que se enumera arriba, menos los marcadores de inyección y ese relleno, con esos saltos de línea como espacios y esos encabezados marcados.

Si no haces clic en el botón Analyze, no se lee ni se envía ningún texto de página para un veredicto de ese botón. La función Background protection y la opción Send full URLs (enviar las URL completas) de la sección Advanced (opciones avanzadas) aún pueden enviar el nombre de host o la URL actual para obtener un veredicto de amenaza, y la protección de archivos puede procesar las descargas, como se describe más abajo.

El botón Analyze no es lo único que envía, y esta sección decía antes que sí lo era. Además de las verificaciones de visitas que acabamos de mencionar, otras tres cosas envían, y cada una tiene su propia sección más abajo. Con la protección de archivos activada, cada archivo que descargas se lee en tu dispositivo y se envía una huella de él —con su nombre, su tamaño y los motivos de nuestro veredicto—, y con la opción Deep scan every file (análisis profundo de cada archivo) activada se envía el propio archivo; nada de eso espera a que hagas clic en un botón. Desde la versión 1.1.0 de la extensión, un archivo que una página construye dentro del navegador es la excepción: en su caso, la huella y el archivo se envían solo cuando una persona inició esa descarga (consulta la sección de protección de archivos). La captura de pruebas, que está activada salvo que la desactives, envía una captura de pantalla y el HTML cuando un análisis con el botón Analyze da como resultado phishing o sospechoso: de la página, en una página web, y solo del mensaje analizado en los hosts de correo. Y desde la versión 1.7, los dos botones que hay bajo un veredicto, Looks safe to me y Looks dangerous, envían tu respuesta cuando haces clic en uno; consulta Tus correcciones a un veredicto. Hasta la versión 1.7, este párrafo nombraba dos cosas, porque esos botones no enviaban nada. La frase anterior decía «nada de la página sale de tu dispositivo», que se escribió antes de que se lanzara la protección de archivos y dejó de ser cierta cuando esta llegó: un archivo blob: que construye una página es algo que está en la página se mire como se mire.

A esa frase le seguía antes otra, «la extensión no se ejecuta en páginas en las que no le has pedido que lo haga», que nunca fue cierta en el caso de los hosts de correo y tampoco lo es en el de la protección de archivos. El código que se ejecuta no es lo mismo que los datos que salen, y la versión honesta de la mitad que se ejecuta es:

Cuando activas el seguimiento de visitas a URL o a dominios

Estas funciones están desactivadas de forma predeterminada para ti. En la ventana emergente son el interruptor Background protection (seguimiento de dominios) y, en la sección Advanced, la opción Send full URLs (seguimiento de URL). Si activas cualquiera de las dos allí o desde la página de bienvenida en la primera instalación, Chrome (o tu navegador) te pide permiso para «leer tu historial de navegación» (webNavigation) y para «leer y cambiar todos tus datos en los sitios web que visitas» (<all_urls>). Puedes rechazar la solicitud, en cuyo caso el interruptor vuelve a desactivarse.

En una flota administrada, estas dos funciones no las decides tú, y esta sección guardaba antes silencio sobre ello. Un administrador puede forzar la activación de cualquiera de las dos —o su desactivación— con las claves de política trackVisits y trackDomains, y un valor forzado prevalece sobre la ventana emergente: la configuración que guardas se lee de nuevo con el valor de la política por encima, así que desactivarla no cambia nada de lo que se envía. El seguimiento de URL forzado significa que la URL completa de cada navegación del marco principal, con la cadena de consulta incluida, va al proxy en cada página que cargas —y, desde la versión 1.1.0 de la extensión, también cada dirección a la que una página se desplaza sin cargar un documento nuevo, como se describe más abajo—. La ventana emergente sí te muestra cuándo ocurre esto: un control que ha establecido un administrador se dibuja con una insignia Managed (administrado) y no se puede cambiar, y un aviso en la parte superior de la sección ⚙ Settings lo indica. Desde la versión 1.1.0 de la extensión, forzar la activación de cualquiera de las dos no la inicia por sí solo: no se verifica ni se envía nada hasta que permites el permiso webNavigation del navegador, que la ventana emergente y la página de bienvenida de la instalación te piden que concedas. El documento revelaba esta anulación para la protección de archivos, para el análisis profundo y para la captura de pruebas, y antes de la versión 1.4 no la nombraba en ninguna parte para el seguimiento de visitas, que es el lugar en el que es más probable que una persona dé por sentado que el interruptor es suyo.

Con el seguimiento de visitas a dominios activado, cada vez que navegas a una página nueva, el nombre de host (por ejemplo, example.com) se envía al punto de conexión /visit del proxy con el tipo domain. La URL completa no se envía. Desde la versión 1.1.0 de la extensión, una página se verifica en cuanto el navegador empieza a mostrarla, en lugar de cuando termina de cargarse, así que también se verifica una página que nunca termina de cargarse.

De forma predeterminada, el nombre de host se envía en cada navegación. Una caché local opcional —desactivada de forma predeterminada y que se activa en la sección Advanced de la ventana emergente— recuerda las respuestas. Desde la versión 1.1.0 de la extensión, durante una hora no se vuelve a preguntar por un sitio que se ha considerado seguro. Por uno marcado como peligroso se vuelve a preguntar a los 15 minutos, y una nueva visita antes de ese plazo vuelve a mostrar la advertencia sin preguntar. Una verificación que no obtuvo respuesta no se guarda en la caché, así que la siguiente visita vuelve a preguntar. Hasta la versión 1.0.0 de la extensión, la caché limita esto a como máximo una vez por hora y dominio, sin importar cuántas páginas cargues en él, sea cual sea la respuesta.

Con el seguimiento de visitas a URL activado, la URL completa (con la ruta, la cadena de consulta y todo lo que vaya después de un #, tal como lo informa tu navegador) se envía en cada navegación del marco principal, con el tipo url. Desde la versión 1.1.0 de la extensión también se envía cuando una página cambia su dirección sin cargar un documento nuevo (history.pushState, history.replaceState o un cambio después del #), una solicitud a la vez por página, con la última dirección a la que se ha desplazado. Hasta la versión 1.9, este párrafo no nombraba ni la parte posterior al # ni esos cambios. Esta es la opción más invasiva; la distribuimos desactivada de forma predeterminada por una razón. Actívala solo si quieres inteligencia de amenazas basada en la URL completa.

Ambos puntos de conexión responden con un veredicto de amenaza. Desde la versión 1.1.0 de la extensión, si el proxy marca una URL o un dominio como peligroso, la extensión sustituye la página por su propia página de advertencia, en la misma pestaña. El botón Go back to safety (volver a un lugar seguro) retrocede por el historial de la pestaña cuando se sabe que eso lleva más allá de la página marcada, y en caso contrario abre la página de nueva pestaña de tu navegador. Si eliges continuar al sitio, la página marcada se carga una sola vez, solo en esa pestaña: la extensión recuerda esa única dirección para esa única pestaña, en la memoria de sesión del navegador y nunca en disco, hasta que el navegador empieza a mostrar otra página en esa pestaña, la pestaña se cierra o pasan dos minutos, lo que ocurra primero. La dirección de la propia página de advertencia contiene la dirección marcada, así que la dirección marcada está en el historial de tu navegador, igual que ya lo estaba la propia página marcada. Hasta la versión 1.0.0 de la extensión, se dibuja una advertencia intersticial de página completa sobre la propia página marcada; puedes elegir volver atrás o continuar de todos modos.

Cuando activas la protección de archivos (acceso anticipado)

La protección de archivos está desactivada de forma predeterminada. Está disponible en Chrome, Edge, Brave (que ejecuta la versión para Chrome) y Firefox, y no en Safari, que no implementa las API de descargas que necesita. Al activarla se piden dos permisos a la vez: downloads y acceso a todos los sitios. Se necesitan ambos: la parte que detecta un archivo que una página construye dentro del navegador lee el contenido de la página, así que conceder solo downloads cubriría menos de lo que describe esta sección. Cuando un administrador ha forzado la activación de la protección de archivos, desde la versión 1.1.0 de la extensión no se ejecuta hasta que hayas permitido ambos, y la ventana emergente y la página de bienvenida de la instalación te lo piden.

De forma predeterminada, el archivo en sí permanece en tu dispositivo. Esta línea decía antes «ningún archivo ni ninguna parte de ningún archivo sale de tu dispositivo», y la segunda mitad no era cierta: uno de los motivos breves que enviamos con la huella nombra un archivo encontrado dentro de un archivo comprimido que descargaste, así que un poco de lo que hay en el archivo puede viajar con ella. Lo que se envía se expone dos párrafos más abajo. Cuando descargas un archivo que ha creado la página (una descarga blob: o data:, la forma que se usa para pasar archivos sin que los filtros de correo los detecten), la extensión lee sus bytes en la memoria de tu navegador, los verifica allí (¿es un ejecutable disfrazado de documento? ¿un archivo de Office que lleva una macro? ¿un ejecutable dentro de un archivo comprimido?) y te avisa o, en el modo de bloqueo, retiene la descarga y te pregunta antes. Esos bytes se descartan inmediatamente después de la verificación y la extensión nunca los escribe en ninguna parte.

Lo que se envía de forma predeterminada: una huella SHA-256 del archivo (un hash de 64 caracteres), su nombre de archivo y su tamaño, el veredicto de la propia extensión y los motivos breves de ese veredicto. La huella se compara con huellas de malware conocido. Un hash tiene 32 bytes y no se puede convertir de nuevo en tu archivo: nos permite reconocer un archivo que ya sabemos que es malicioso sin llegar a ver nunca el tuyo. Los motivos son en su mayoría frases fijas que escribió la extensión («runnable script (.js)», es decir, script ejecutable, y «Office document with an embedded macro», es decir, documento de Office con una macro incrustada), y algunos citan el nombre o la extensión del propio archivo, que se envían de todos modos. Uno de ellos cita algo que no se enviaría de todos modos: el nombre de un ejecutable encontrado dentro de un archivo comprimido que descargaste. Si descargas invoice.zip con payload-for-acme.exe dentro, ese nombre interior se envía con la huella, sin el archivo y sin un segundo interruptor. Los motivos faltaban en esta lista hasta la versión 1.4, y por eso la frase «ninguna parte de ningún archivo» de más arriba parecía cierta.

Desde la versión 1.1.0 de la extensión, de un archivo que construye una página solo se envía información cuando una persona inició la descarga. Eso significa tu propio clic en el enlace, o un clic que hace la página mientras tu clic sigue vigente; un navegador mantiene vigente un clic durante unos cinco segundos, así que se considera que una página cuya exportación tarda más que eso en prepararse ha iniciado la descarga por sí misma. Un archivo que una página guarda por sí sola se sigue verificando en tu dispositivo, se retiene en el modo de bloqueo y se te avisa de él, pero no se envía ni su huella ni el archivo. Las descargas normales no se ven afectadas. Hasta la versión 1.0.0 de la extensión no se hace esta distinción.

Cada verificación que llega al analizador de archivos deja un registro en nuestros sistemas, incluida la predeterminada, que no envía ningún archivo: la huella, el nombre del archivo (hasta 300 caracteres) y su tamaño, el veredicto, qué verificación lo dio, el motor del análisis profundo o el nombre de la firma de malware con la que coincidió cuando la hubo, tu pseudoId y el extensionId del dispositivo, cuándo se realizó y la fecha en que se eliminará. Recibe su fecha de eliminación cuando se escribe, igual que tus registros de análisis y de visita; la única excepción son las verificaciones de archivos hechas antes de que empezáramos a dar una fecha a cada registro, a las que se dieron 365 días (consulta Plazos de conservación). El botón Delete my scan history lo elimina. Un archivo que una página guarda por sí sola, que se verifica solo en tu dispositivo, no deja ningún registro aquí. Tu propio panel en el portal no lo muestra. En un equipo, la persona propietaria lo ve en la lista Scans (análisis) de la página Team (equipo) del portal, salvo en una organización que informa de forma agregada, donde esa lista no se muestra. Hasta la versión 1.9, este documento no describía este registro y decía que conservábamos «solo la huella y el veredicto».

Enviar un archivo propiamente dicho es una decisión aparte, archivo por archivo. Cuando una verificación no es concluyente, la advertencia puede ofrecer el botón Check it properly (analizarlo a fondo). Un archivo se sube solo si haces clic en ese botón, para ese único archivo. Nuestro propio analizador lo analiza en memoria en nuestro propio hardware, se devuelve el veredicto y el archivo no se almacena: conservamos solo el registro de la verificación descrito arriba.

A menos que actives la opción Deep scan every file. Esa opción está desactivada de forma predeterminada y cambia la regla anterior: con ella activada, cada archivo que descargas se nos envía para un análisis completo de malware en cuanto llega, y no solo los que tú pides. Cada archivo se sigue analizando en memoria y sigue sin almacenarse —conservamos el mismo registro de la verificación que antes—, pero el archivo en sí sale de tu dispositivo todas las veces, salvo, desde la versión 1.1.0 de la extensión, un archivo que una página construyó y guardó por sí sola, como se describe arriba. Existe para las personas y organizaciones que quieren que se verifique todo; si no es tu caso, déjala desactivada y no se sube nada a menos que lo pidas. Un administrador puede exigirla para una flota administrada mediante una política.

Las descargas normales (un enlace corriente, un archivo que envía un servidor) también están cubiertas, pero de otra forma: el navegador no entrega a una extensión los bytes de una descarga así, de modo que la extensión solicita la dirección del archivo por segunda vez para leerlo, lo verifica en memoria de la misma manera y lo descarta. Consecuencias prácticas, dichas con claridad: el archivo se transfiere dos veces, y un enlace de descarga de un solo uso puede fallar en esa segunda solicitud, en cuyo caso la verificación se limita al nombre y al tipo del archivo. La reputación de la URL se verifica en tu dispositivo, con una lista de amenazas que descarga la extensión; la dirección de lo que descargas no se envía a ninguna parte para consultarla.

Lo que esta función no hace: no lee los archivos que ya están en tu disco, no vigila tu carpeta de descargas y no puede detener una descarga normal antes de que se guarde: ninguna extensión de navegador puede. En esos casos avisa después de que el archivo llega y ofrece eliminarlo.

Qué guarda la extensión en tu propio dispositivo

Esta subsección era nueva en la versión 1.4. El documento describía lo que recibimos y nunca describía lo que se queda contigo, y nombraba exactamente una clave de almacenamiento —pseudoId— de un modo que se leía como si fuera toda la lista. Guardar estas copias en local no desencadena por sí mismo ninguna transmisión; cuando uno de los valores de la lista también se envía, la sección correspondiente más abajo lo dice. Esta lista se expone porque son datos sobre ti que existen por haber instalado PhishTriage, y porque las vías de eliminación que aparecen más abajo actúan sobre nuestros servidores y no pueden alcanzar el perfil de tu navegador.

Desde la versión 1.1.0 de la extensión, esta también guarda tres cosas en la memoria de sesión del navegador, que nunca se escribe en disco y desaparece cuando se cierra el navegador:

Tu configuración en sí reside en chrome.storage.sync, no en el almacenamiento local, lo que significa que tu navegador la copia en tu cuenta de Google o de Mozilla junto con el resto de tu perfil si tienes activada la sincronización del navegador. Son posiciones de interruptores, no contenido.

Guardar pruebas de páginas de phishing

Esta opción está activada a menos que la desactives. Se te muestra durante la configuración inicial y se encuentra en la ventana emergente, en la sección ⚙ Settings, donde puedes desactivarla en cualquier momento. Con ella desactivada, nunca ocurre nada de lo descrito en esta sección. Un administrador puede establecerla en un sentido o en otro para una flota administrada con la clave de política evidenceCapture.

Es una de las dos cosas de PhishTriage que están activadas antes de que toques nada, y por eso se describe aquí por completo en lugar de resumirse. La otra, desde la versión 1.7, es que tu respuesta a un veredicto se envía cuando haces clic en uno de los dos botones que hay bajo él; eso no envía nada hasta que haces clic, y tiene su propia sección más abajo. Hasta la versión 1.7, este párrafo llamaba a la captura de pruebas la única, lo que era cierto mientras esos botones no enviaban nada. Antes se describía como lo único que envía sin haberse activado antes, y esa es una afirmación distinta y falsa: la política de un administrador puede activar la función Background protection, la protección de archivos y la opción Deep scan every file en una flota administrada, digan lo que digan tus interruptores (desde la versión 1.1.0 de la extensión, las dos primeras esperan entonces hasta que concedes el permiso del navegador que cada una necesita), y el registro del dispositivo —descrito en ID seudónimo— se ejecuta solo en la instalación, antes de que exista una opción sobre la que tener opinión.

Un veredicto dice que una página o un mensaje era phishing. No lo demuestra ante el registrador de dominios, el proveedor de alojamiento o el proveedor de correo que realmente pueden actuar al respecto. Esta opción existe para producir algo sobre lo que puedan actuar.

Qué se captura en una página web. Dos cosas, y solo estas dos: una captura de pantalla de la parte visible de la pestaña (un JPEG: lo que viste, y lo que habría visto una víctima), y el HTML de la página tal como estaba en tu navegador (lo que la página es en realidad: el formulario que recoge la contraseña, la dirección a la que envía los datos, el código que carga). Lo que se captura en los hosts de correo es más limitado y se expone más abajo.

Cuándo. En el momento en que haces clic en Analyze, antes de que exista el veredicto, porque una captura de pantalla tomada más tarde sería de aquello a lo que la pestaña hubiera pasado, y adjuntar la página equivocada a una solicitud de retirada es peor que no adjuntar nada. Después, ambos se mantienen solo en la memoria de la extensión durante los pocos segundos que dura el análisis. Ninguno se escribe en disco, en el almacenamiento del navegador ni en ningún otro lugar de tu dispositivo.

Si se envía. Solo si ese análisis da como resultado phishing o sospechoso. Con cualquier otro veredicto, ambos se descartan y ninguno sale de tu dispositivo. No se captura nada en las páginas chrome://, en la tienda Chrome Web Store ni en las páginas de otras extensiones, porque el navegador no lo permite.

En los hosts de correo, el mensaje que analizaste y nada más a su alrededor. La vía del correo son cinco nombres de host, no una regla sobre el correo electrónico; esa fue la corrección más importante de la versión 1.4, por lo que se expone con detalle. La vía del correo son exactamente estos cinco hosts:

En esos cinco, nunca se toma una imagen de toda la pestaña. Sería de tu bandeja de entrada —la lista de mensajes, el correo de otras personas, tus carpetas y tu cuenta—, que es lo más sensible que esta función podría tomar y no ayuda en nada a denunciar el phishing. Si el veredicto da como resultado phishing o sospechoso, lo que recibimos en su lugar es el mensaje que analizaste, y nada más:

La dirección que el mensaje tiene en tu buzón no se envía con él. Si la extensión no encuentra el mensaje en la página, o no puede recortar la imagen a su tamaño, no envía nada en lugar de una imagen más amplia. Tu navegador deja que la extensión tome la imagen solo cuando abriste PhishTriage desde la barra de herramientas del navegador para esa pestaña, o cuando le has dado acceso a todos los sitios, que es lo que se pide al activar la función Background protection o la protección de archivos; hacer clic en el botón de PhishTriage dentro de Gmail u Outlook, por sí solo, no captura nada.

Hasta la versión 1.8, esta sección decía que en la vía del correo no se capturaba absolutamente nada. La versión 1.1.0 de la extensión es la primera que captura el mensaje, y la primera que verifica la dirección de la pestaña con la lista antes de tomar ninguna imagen, de modo que una página de uno de estos cinco hosts nunca se fotografía entera aunque la extensión no la haya reconocido como correo. Hasta la versión 1.8, la lista también tenía cuatro hosts y omitía outlook.cloud.microsoft, la dirección web más reciente de Outlook, así que el correo de Outlook que se leía allí quedaba comprendido en el párrafo siguiente como una página web normal.

El correo web en cualquier otro sitio se trata como una página web normal. La verificación es una comparación de nombres de host, no un juicio sobre si estás leyendo correo. Así que, si usas Yahoo Mail, Proton Mail, Fastmail, Zoho Mail, Roundcube o el Outlook Web Access propio de tu empleador en un dominio de empresa —cualquier cosa que no sea uno de los cinco hosts de arriba—, entonces hacer clic en el botón Analyze en un mensaje de allí equivale a hacer clic en el botón Analyze en una página web. Si el veredicto da como resultado phishing o sospechoso, recibimos:

Esta es la configuración con la que se distribuye. La captura de pruebas está activada a menos que la desactives, y «sospechoso» —la clase de veredicto que en otras partes de este documento se describe como el lugar donde viven los falsos positivos— basta para activarla. Nada de esto exige que hayas decidido activarla.

Para desactivarla: abre la ventana emergente de PhishTriage, haz clic en el botón ⚙ Settings y desactiva el interruptor Keep evidence of phishing. Con ella desactivada, nada de lo que se describe en esta sección ocurre en ninguna parte, en ningún host. Si lees el correo en un proveedor que no es uno de los cinco anteriores, ese interruptor es el que debes mirar.

Este párrafo decía antes «nunca se captura nada en la vía del correo», sin más, y la frase se escribió cuando Gmail y Outlook eran el único correo al que se había dirigido alguna vez el producto. Se leía como una promesa sobre el correo electrónico. Nunca fue más que una promesa sobre una lista de nombres de host, y lo que separa esas dos cosas es la bandeja de entrada de alguien. El esquema de políticas empresariales de la propia extensión ha descrito correctamente el comportamiento —«webmail on any other host counts as a web page», es decir, el correo web en cualquier otro host cuenta como una página web— mientras este documento lo negaba; estamos corrigiendo el documento, no el esquema.

Dos advertencias honestas. «Sospechoso» es donde viven los falsos positivos, así que con esta opción activada puedes subir una página que resulte ser perfectamente legítima; por eso las páginas sospechosas se conservan mucho menos tiempo, y por eso quien revisa una página y dice que no era phishing la elimina en el acto, aunque dentro de una organización esa revisión se rechaza mientras la ventana de actividad está reteniendo la información, que es su estado predeterminado; consulta la sección de plazos de conservación. Y el HTML normalmente no contiene lo que escribiste, porque los valores escritos viven en una propiedad y no en el marcado de la página, pero una página puede volver a escribirlos en el marcado, así que normalmente es la palabra honesta.

Cuánto tiempo se conserva. No según el plazo del historial de análisis que figura más abajo, que se refiere a tu propio historial de análisis. Las pruebas se refieren a un tercero y se conservan con su propio plazo, sea cual sea el que se aplique a tus análisis:

Quién puede verla, y cómo. Si analizas por tu cuenta, solo tú. Si tu cuenta pertenece a un equipo, entonces todas las personas de ese equipo: las mismas que ya pueden ver que se hizo el análisis.

Aparece en el portal, en su propia lista Phishing Evidence (pruebas de phishing) del panel, junto al análisis del que procede mientras ese análisis siga existiendo. La lista es lo que importa, porque las pruebas pueden sobrevivir al análisis del que proceden: una vez que la limpieza elimina el registro del análisis, la captura sigue ahí, y la lista es la forma de llegar a ella para verla, descargarla o eliminarla. Este párrafo decía antes que las pruebas eran visibles «en el análisis al que pertenecen», y durante la mitad más larga de la vida de una captura de 12 meses eso no se cumplía en nada en lo que pudieras hacer clic.

Salvo en una organización que informa de forma agregada, donde la lista no se muestra a nadie. El modo agregado es aquel en el que empieza toda organización. En él, una lista de capturas es actividad por persona como cualquier otra, así que el portal rechaza el acceso completo, no solo la visualización. Nadie, ni la persona propietaria ni la persona cuyo propio dispositivo hizo la captura, puede abrir la lista Phishing Evidence, descargar una captura de pantalla o el código fuente de su página, confirmar una captura, rechazarla ni eliminar una sola. Este documento reconocía solo la mitad referida a verla y dejaba «verla, descargarla o eliminarla» en pie junto a ella.

Quién puede eliminarla. Dentro de un equipo, confirmar o rechazar una captura es una acción de la persona propietaria, y solo donde la organización informa de forma atribuida; en el modo agregado, según el párrafo anterior, nadie puede. Lo que funciona en todos los modos es eliminar las tuyas: el botón Delete my scan history descrito en Plazos de conservación elimina todas las capturas almacenadas bajo tu cuenta, incluidas aquellas cuyo registro de análisis ya ha caducado, y ningún rol de la organización puede hacerte eso ni deshacerlo.

Ese botón se limita a tu cuenta, no a tu hardware. Este documento decía antes que eliminaba «todas las capturas realizadas en tus propios dispositivos», que es un conjunto distinto: una captura que tu dispositivo hizo antes de vincularlo a tu cuenta se escribió bajo la identidad anterior propia de ese dispositivo, y el botón no la alcanza. Es el mismo límite que la sección Plazos de conservación ya indica para los registros de análisis y de visita, y también se aplica a las capturas.

El código propio de la página nunca se ejecuta. El HTML almacenado de una página hostil se trata como hostil: nunca se renderiza en nuestro portal, solo se descarga como archivo inerte, y se sirve como texto sin formato para que abrir el enlace no pueda ejecutarlo. La captura de pantalla es una imagen y se verifica que lo sea antes de almacenarla: un archivo que no es realmente una imagen se rechaza.

Tus correcciones a un veredicto

Esta sección se agregó en la versión 1.7. Bajo cada veredicto, el panel lateral muestra dos botones, ✓ Looks safe to me (parece seguro) y ⚠ Looks dangerous (parece peligroso). Hasta la versión 1.6, guardaban tu respuesta en tu dispositivo y no enviaban nada. Ahora también nos envían tu respuesta, y eso es lo predeterminado. No se envía nada hasta que haces clic en uno de ellos: el clic es lo único que lo desencadena, y un veredicto al que no respondes no produce ningún informe.

En la ventana emergente no hay ningún interruptor para esto. Una organización puede desactivar el envío en su flota administrada con la clave de política feedbackUpload establecida en false, y entonces la respuesta se guarda solo en el dispositivo, como antes. La versión para Safari no tiene política de administrador (consulta el principio de este documento), así que allí no se puede desactivar de esa manera. Si no quieres que se envíe una corrección, no hagas clic en los botones.

Qué envía la extensión. Una pequeña solicitud a api.phishtriage.com por cada clic, que contiene:

Con la solicitud no se envía nada de la propia página ni del propio mensaje: ni texto, ni título, ni remitente, ni destinatario, ni asunto. Como toda solicitud de la extensión, también lleva la credencial de dispositivo con la que se registró la extensión, que es como sabemos de qué dispositivo y de qué cuenta procede un informe. Un dispositivo que no se ha registrado no puede enviar uno; lo rechazamos en lugar de conservar un informe que no se puede atribuir a nadie.

Un informe hecho sobre un correo nunca incluye la ubicación del mensaje. En Gmail y en los cuatro hosts de Outlook nombrados en Guardar pruebas de páginas de phishing, la dirección de tu navegador identifica tu buzón y el mensaje que tienes abierto, así que la extensión la omite del informe. Hasta la versión 1.8, este párrafo decía que la extensión leía outlook.cloud.microsoft como una página web normal y que, aun así, omitía allí la dirección; ahora es uno de los hosts de correo. Si de todos modos llegara un informe con una dirección de uno de esos cinco hosts, o con cualquier dirección procedente del complemento de Google Workspace, que no nos envía ninguna, descartaríamos la dirección antes de almacenar o reenviar nada. El correo web en cualquier otro host es una página web para la extensión, exactamente igual que para la captura de pruebas, así que un informe que hagas allí incluye la dirección de esa página. La copia que se guarda en tu dispositivo no es el informe: contiene la dirección completa dondequiera que hicieras clic en el botón (consulta Qué guarda la extensión en tu propio dispositivo).

Qué conservamos. Una fila por informe, en la base de datos que contiene tu historial de análisis:

La propia dirección nunca se almacena. Tu dirección IP tampoco: la dirección de la solicitud se usa solo en memoria, para limitar cuántos informes pueden llegar desde una misma dirección en una hora, y el dispositivo tiene un límite propio. El registro de la aplicación no deja constancia de los informes. Solo recibe una línea cuando algo sale mal con uno —una dirección descartada, una fila que no se pudo escribir— y, la primera vez tras un reinicio en que un informe lleva una dirección, una nota de que no hay ninguna clave configurada para el hash. Ninguna de esas líneas contiene la dirección, tu pseudoId ni tu dirección IP (consulta El registro de la aplicación). Un informe no se envía a ningún modelo ni a ningún tercero.

Cuánto tiempo. Con un plazo propio de 90 días, sea cual sea el que se aplique a tu historial de análisis: la limpieza de conservación elimina los informes más antiguos que eso, varias veces al día, y el botón Delete my scan history del portal elimina de una vez todos los informes almacenados bajo tu cuenta. El límite descrito en Plazos de conservación, para los registros que un dispositivo hizo antes de que lo vincularas a tu cuenta, se aplica también a los informes. Los plazos más largos de las pruebas no se les aplican. Hasta la versión 1.9, este párrafo ponía los informes en el mismo plazo de 90 días que tu historial de análisis, lo que equivalía a un único plazo mientras el historial de análisis tenía un solo plazo.

Quién puede verlo. Ninguna página del portal muestra un informe: ni a ti, ni a las personas propietarias de tu organización, ni a nadie. Solo nosotros leemos los informes, desde la base de datos. Una solicitud de acceso (consulta Tus derechos) devuelve los tuyos junto con el resto de tus registros.

Qué llega al centro de inteligencia. De forma predeterminada, nada. Reenviar informes al centro es un interruptor aparte de nuestro lado, desactivado en la configuración que se distribuye y, a la fecha de entrada en vigor indicada al principio de este documento, desactivado en el servicio alojado. Inteligencia de amenazas compartida describe el centro y exactamente lo que lleva un informe reenviado, y cada fila registra si su informe se reenvió.

Qué no recopila nunca la extensión

Dos de estas viñetas llevan ahora matices, y el encabezado debe leerse con ellos y no por encima de ellos. Cada una nombra algo concreto que la extensión no tiene mecanismo para obtener; ninguna es una promesa de que nada de ese tipo nos llegue nunca por otra vía, y cuando existe una vía, la viñeta lo dice.

Mensajes de texto (PhishTriage para iOS)

Esta sección era nueva en la versión 1.5. Cubre un canal que ninguna versión anterior mencionaba en absoluto —buscar «SMS» o «text message» en la versión 1.4 no devuelve nada, mientras que el backend tenía un punto de conexión para ellos todo el tiempo—. Nada de lo que contiene era un cambio de comportamiento. Cerró un hueco del documento, y el mayor de los que cerró esa versión.

Esto no es la extensión del navegador. Lo que sigue ocurre solo si instalaste la aplicación PhishTriage en iOS y activaste su filtro de mensajes. Si no lo has hecho, nada de esto te afecta. La extensión no puede leer mensajes en ninguna plataforma.

iOS decide qué mensajes llegan siquiera a ofrecerse al filtro. Una extensión de filtro de mensajes no recibe tu historial de mensajes y no puede ir a buscarlo; el sistema le entrega mensajes individuales de remitentes en los que todavía no confía, y esa regla es del sistema operativo, no nuestra. No podemos ampliarla.

Solo se nos envía un mensaje que contenga un enlace. Antes de cualquier solicitud de red, la aplicación busca un enlace en el mensaje. Un mensaje sin enlace, y un mensaje sin cuerpo, se permiten en el dispositivo y no se envía nada sobre ellos. La detección de enlaces es la del sistema y se inclina por encontrar uno.

Qué se envía, cuando se envía un mensaje:

Los tres llegan completos y se recortan por nuestra parte, al recibirlos —el remitente a 100 caracteres, el cuerpo a 2000 y la cadena de versión a 40— antes de que nada más los toque. Lo expresamos así a propósito: el teléfono envía el mensaje entero, de modo que esos límites acotan lo que conservamos y analizamos, no lo que sale de tu dispositivo. Una de las dos formas de solicitud que puede enviar nuestra propia aplicación lleva además un pequeño número entero de versión del propio formato. Describe el mensaje, no a ti.

Ese es todo el cuerpo de la solicitud. No lleva ninguno de los identificadores que se usan en el resto de este documento: ni pseudoId, ni ID de extensión, ni ID de dispositivo, ni cuenta. El filtro de mensajes no puede adjuntar ninguno —el mecanismo de diferimiento de Apple no lo transporta— y no inventamos un sustituto. Por ese motivo el punto de conexión no está autenticado, y en su lugar se limita la frecuencia de solicitudes por dirección IP. Esa es la matización honesta: tu dirección IP no está en el cuerpo, pero llega con la solicitud, como con toda solicitud HTTP, es lo que cuenta el límite de frecuencia y se escribe en el registro descrito más abajo.

Pero el mensaje todavía puede identificarte. Es la misma salvedad que lleva la vía del botón Analyze, y es igual de cierta aquí. Un mensaje de texto suele empezar con tu nombre; un aviso de entrega o una alerta del banco puede llevar una referencia de cuenta, un número de reserva o una dirección. No buscamos nada de eso y nada de eso se almacena, pero está en el cuerpo, y el cuerpo se envía.

No todos los mensajes que recibimos llegan a un modelo. De nuestro lado, primero responde un paso de palabras clave y lista de bloqueo, y las URL que haya en el mensaje se comparan con nuestra lista de bloqueo. Solo se entrega a un modelo un mensaje que ese paso no puede decidir, y entonces por la misma vía que todo lo demás, descrita en Dónde se realiza el análisis, con el mismo orden y las mismas condiciones.

Qué se almacena: ningún registro del mensaje. Este es el único lugar de este documento en el que esa es la respuesta. A diferencia de los registros de triaje y de visita descritos más abajo, una verificación de SMS no escribe ninguno: ni el remitente, ni el cuerpo, ni el veredicto, ni la acción devuelta. No hay ningún historial de mensajes en el portal, y el botón Delete my scan history no tiene nada que eliminar aquí porque no se escribió nada.

Qué se registra, que es la excepción del párrafo anterior. Una solicitud que llega al controlador del punto de conexión produce una línea en el mismo registro operativo descrito en El registro de la aplicación, con la misma duración, es decir, que nada en la aplicación la elimina. Esa línea lleva tu dirección IP sin procesar, la versión de la aplicación, un hash truncado del remitente (los primeros 12 caracteres hexadecimales de un SHA-256 sin sal; la advertencia expuesta para los registros de triaje se aplica aquí exactamente igual), si el mensaje contenía un enlace, en cuál de las dos formas de solicitud llegó, qué paso lo decidió, el veredicto y la acción, y cuánto tardó. El cuerpo del mensaje no se registra, y el remitente no aparece en claro.

Lo que no podemos ofrecerte aquí, dicho con claridad. Todas las vías de acceso y eliminación de este documento funcionan a partir de un pseudoId o de un extensionId, y una solicitud de SMS no lleva ninguno de los dos. Así que no hay ningún registro que devolverte ni ninguno que eliminar —porque no se escribió ninguno— y la línea de registro descrita arriba solo está vinculada a la dirección IP de la que procedía. Decimos «la línea de registro» y no «el único rastro» a propósito: lo que un proveedor de modelos hace con un mensaje que le enviamos para su análisis se rige por sus condiciones, no por esta frase. Si quieres que se borre la línea de registro, escribe a privacy@phishtriage.com; la borramos a mano, como el resto del registro. Preferimos decir esto a insinuar un remedio que no existe.

Dónde se realiza el análisis

Esta sección es nueva en la versión 1.5. Existe porque la afirmación a la que sustituye era errónea en una dirección que no favorece a nadie: la política decía que tu contenido va a Anthropic de forma habitual, y ya no es así como funciona el enrutamiento.

El orden. Todo lo que necesita un modelo —un análisis que iniciaste con el botón Analyze, o un mensaje de texto que superó los dos pasos anteriores— se ofrece a los backends en un orden fijo, y el primero que devuelve una respuesta utilizable es el que responde:

  1. Un modelo que alojamos nosotros mismos. Una máquina que operamos, en nuestra propia red, en lugar de un servicio de modelos que compramos. Es el primero al que se consulta.
  2. Un servicio de modelos de terceros. No forma parte de la vía en ninguna implementación que operemos a la fecha de entrada en vigor de esta versión. Se nombra en Terceros encargados del tratamiento, que dice exactamente qué lo pondría ahí.
  3. La API de Claude de Anthropic. El último recurso, y el único de los tres que no tiene nada detrás a lo que recurrir, por lo que su fallo no se transmite: la solicitud termina sin veredicto. Su respuesta se verifica de todos modos. Un campo opcional mal formado se descarta, y una respuesta que no coincide con la forma que exige el resto del sistema se trata como un fallo en lugar de usarse.

Las condiciones. Un nivel se consulta solo si está configurado, no se ha desactivado y a la solicitud aún le queda tiempo en su presupuesto; un nivel que no está configurado simplemente no está en el orden. Un nivel al que se consulta y falla pasa la solicitud al siguiente, y «falla» es deliberadamente amplio: inaccesible, demasiado lento, un error, un límite de frecuencia, una salida que no podemos interpretar o un veredicto que no coincide con la forma que exige el resto del sistema. En cualquiera de esos casos, el siguiente nivel recibe el mismo contenido.

Una cosa puede ir antes que el orden, y solo donde se usa nuestro centro de inteligencia: un análisis cuyos enlaces, dominio del remitente o hashes de archivos adjuntos el centro ya tiene como maliciosos, y marcados como aptos para que se actúe sobre ellos de forma automática, se responde a partir de eso y no se ofrece a ningún modelo (Inteligencia de amenazas compartida, desde la versión 1.7). En el servicio alojado, a la fecha de entrada en vigor indicada al principio de este documento, el centro no está en uso.

Se puede consultar dos veces a un nivel sobre un correo. Cuando un nivel anterior a Anthropic —nuestro propio modelo o el servicio de terceros— califica un correo de phishing o sospechoso, nombra como la marca suplantada el propio nombre de dominio del remitente (el «Acme» de acme.com) y ninguna de nuestras verificaciones deterministas encontró ningún problema en el mensaje, corresponde una segunda solicitud a ese mismo nivel. No corresponde en unos pocos casos más acotados: cuando el remitente está en un dominio de correo gratuito o de alojamiento compartido; cuando no podemos afirmar con certeza el dominio del remitente, como cuando el campo del remitente es lo bastante largo como para que se haya podido cortar; o cuando ese dominio lleva el nombre de una de unas pocas organizaciones de las que mantenemos una lista revisada de sus propios dominios y no es un dominio que contemos como suyo (anthropic.co en lugar de anthropic.com). La segunda solicitud lleva el mismo contenido más una breve instrucción agregada que indica el dominio del remitente y pide una señal concreta de engaño o una respuesta reconsiderada. Cuando queda demasiado poco tiempo para hacerla, se omite y se usa la primera respuesta; en caso contrario, se usa la segunda respuesta si es utilizable, y la primera si no. Va solo al nivel que acaba de responder, nunca más allá y nunca a Anthropic, así que no agrega ningún destinatario: es una segunda copia del mismo contenido para el mismo. Si ese nivel es el servicio de terceros, ese servicio recibe tu contenido dos veces.

Por qué aquí no hay ninguna frase que diga que tu contenido permanece en nuestro hardware. Porque sería falsa justo los días en que importa. El recurso alternativo existe porque el primer nivel falla, y cuando falla tu contenido sigue adelante: ese es todo el sentido de tener uno. En la semana del 17 de agosto de 2026, un parámetro de muestreo que rechaza el modelo que alojamos nosotros mismos envió todos los análisis a Anthropic hasta que se encontró y se corrigió. No ponemos aquí ninguna proporción ni duración: cualquier cifra que imprimiéramos sería la medición de un solo momento, y el enrutamiento es una regla, no una proporción. Con lo que sí puedes contar es con el orden y las condiciones de arriba.

Anthropic sigue siendo un encargado del tratamiento. «Con menos frecuencia» no significa «nunca». Una versión de esta política que eliminara a Anthropic sería errónea la primera hora en que la máquina local funcionara mal, y funcionó mal esa semana. Su entrada en Terceros encargados del tratamiento sigue vigente.

No te decimos en qué país está esa máquina, y es deliberado. La declaración sobre Estonia en Terceros encargados del tratamiento trata del host de PostgreSQL y siempre ha tratado solo de esa máquina. No es una declaración sobre el servidor de modelos, y un borrador de esta sección la reutilizó por error antes de que la revisión lo detectara. Nombraremos aquí una ubicación cuando podamos afirmarla con tanta precisión como la de la base de datos, y no antes.

Esta página tiene fecha, y el enrutamiento no. Qué niveles están configurados es una propiedad del servicio en ejecución y puede cambiar sin que cambie este documento. Por eso todo lo anterior está escrito como una regla más una declaración de la disposición vigente a la fecha de entrada en vigor indicada arriba, no como una afirmación sobre este instante. Donde ambas puedan divergir, la parte en la que puedes confiar es la regla.

Lo que no cambia con el enrutamiento. Responda el nivel que responda, el contenido enviado es el contenido enumerado arriba y se devuelve el mismo veredicto. De los análisis hechos con el botón Analyze se almacena el mismo registro; las verificaciones de SMS no almacenan ningún registro, como se indica en Mensajes de texto.

Qué dice ahora el registro sobre el enrutamiento. Desde la versión 1.6, un registro de triaje almacenado, y la línea de registro que se escribe con él, anotan qué nivel respondió y, cuando un nivel anterior falló primero, por qué: un motivo de una lista fija, como un tiempo de espera agotado, un error o una salida que no pudimos interpretar. Si, para poder leer la respuesta que conservamos, tuvimos que volver a ponerle comas que le faltaban, lo cual ocurre solo en un nivel anterior a Anthropic, el registro y la línea anotan cuántas. Cuando correspondía una segunda solicitud al nivel que respondió, como se describe arriba, también anotan cómo fue (respondió, se omitió por falta de tiempo o un motivo de la misma lista fija), el veredicto de la primera respuesta y si el veredicto conservado es distinto. Todos ellos son palabras de listas fijas o un recuento, y ninguno lleva nada de tu contenido. Este párrafo decía antes que un registro de triaje almacenado no anota qué backend produjo el veredicto, por lo que no podíamos decirte después cuál de ellos procesó un análisis concreto tuyo, y tú tampoco podías saberlo. La primera mitad ya no es cierta: una solicitud de acceso, descrita en Tus derechos, lo devuelve con el resto del registro. La segunda mitad sigue siéndolo, porque nada de lo que puedes abrir en la extensión o en el portal lo muestra.

Qué almacena el backend y durante cuánto tiempo

El proxy de api.phishtriage.com (Node/Express; su código fuente no es público hoy) registra cada solicitud de triaje y cada ping de visita en una base de datos PostgreSQL alojada en hardware que poseemos y operamos; consulta Terceros encargados del tratamiento, más abajo, para ver el panorama completo del almacenamiento. Campos almacenados por registro:

Registros de cuenta e identidad

Esta subsección era nueva en la versión 1.2. Los tipos de registro anteriores se habían presentado como todo el panorama del almacenamiento, y no lo son: son los registros de actividad. El plano de control que hay debajo de ellos se agregó cuando el producto incorporó cuentas, equipos y planes, y es donde realmente vive una dirección de correo electrónico. En el orden del esquema (migrations/ en el repositorio del proxy):

Una organización puede incorporarte sin preguntarte, y hasta la versión 1.4 este documento nunca lo decía. Describía dos vías de entrada a un equipo —una invitación que aceptas y un token de inscripción que un administrador envía a un dispositivo— y hay una tercera. Si una organización ha acreditado que es propietaria de un dominio de correo electrónico, la siguiente vez que alguien inicie sesión en el portal con una dirección de Google verificada de ese dominio, esa cuenta pasa a ser miembro de esa organización. No hay invitación, ni solicitud de confirmación, ni aviso al iniciar sesión; ocurre durante un inicio de sesión que se ve igual que cualquier otro. Desde ese momento, las personas propietarias de la organización pueden ver los análisis de esa cuenta y sus pruebas de phishing en los mismos términos que los de cualquier otro miembro, sujeto al modo de informes descrito en Guardar pruebas de páginas de phishing.

Tres límites son reales y conviene decirlos. Una cuenta que ya está en una organización nunca se traslada a otra. Solo se atribuye la actividad a partir del instante en que la organización pasó a los informes por persona, así que unirte no expone retroactivamente lo que hiciste antes. Y el portal te dice en qué organización estás, cuándo te uniste y qué dominio te puso allí, precisamente porque esta es la única pertenencia sobre la que no se pregunta a nadie. Si prefieres que no ocurra, no inicies sesión en el portal con una dirección de ese dominio: la extensión analiza perfectamente bien sin una cuenta.

Un dominio se puede acreditar de dos maneras, y solo una de ellas es visible para ti. La primera es un registro DNS TXT que publica la organización. La segunda identifica a la organización por el inquilino de tu proveedor de identidad —hoy, la declaración (claim) hd de Google Workspace— y no exige que la organización publique nada en absoluto. Por eso, revisar los registros DNS de tu dominio no es una forma de descartar esto.

Volvemos al inventario de registros:

El registro de la aplicación

Aparte de la base de datos, el proxy escribe una línea de registro operativo al procesar una solicitud. Aquí importan seis tipos de línea. El tercero faltaba en esta lista hasta la versión 1.5, porque el canal al que pertenece faltaba en este documento, el cuarto llegó con los botones de informe en la versión 1.7, y los dos últimos se agregaron al servicio el 3 de octubre de 2026 y a esta lista en la versión 1.10:

Otras líneas tratan de un dispositivo o de una cuenta y no de un análisis. Llevan su extensionId, pseudoId o ID de cuenta y nada de tus análisis: un dispositivo que presenta una credencial que ya no aceptamos, una cuenta cuyas credenciales de dispositivo revocamos, una cuenta que se une a una organización por un dominio acreditado, una acción del portal rechazada por falta de un rol y un dispositivo que lleva a su organización por encima del número de licencias que incluye su plan, registrado con el número de licencias y el plan cuando el dispositivo se registra o envía un token de inscripción tardío.

El analizador de archivos de filescan.phishtriage.com, un servicio nuestro aparte, guarda un registro propio si usas la protección de archivos: una línea por cada solicitud que procesa, con la solicitud, su estado, cuánto tardó y los primeros ocho caracteres del extensionId del dispositivo y, para una verificación de archivo, el veredicto, qué verificación lo dio, si se ofreció un análisis profundo, la firma de malware con la que coincidió un análisis profundo y los primeros 60 caracteres del nombre del archivo. No lleva tu dirección IP ni el archivo. Hasta la versión 1.9, este documento no lo mencionaba.

En este sentido era falsa la frase «no conocemos tu dirección IP», que figuraba al principio de este documento hasta la versión 1.2. El hash es real, y es lo que conserva la base de datos; no es lo que conserva el registro.

La limpieza de conservación que se describe a continuación elimina filas de la base de datos. No toca estos registros: nada en ninguna de las dos aplicaciones los elimina, así que su duración es la que les dé la administración de los registros por parte del operador. Una solicitud de eliminación que nombre tu extensionId los cubre, incluidas las líneas que llevan solo el pseudoId o el ID de cuenta al que pertenece ese extensionId; los borramos a mano. Una línea de SMS no tiene ningún extensionId que nombrar: Mensajes de texto dice qué significa eso para una solicitud. Tampoco lo tiene una línea de capacidad, que nombra una dirección con hash y nada más sobre nadie.

Plazos de conservación

Los registros de pruebas son la excepción a todo lo de esta sección: se conservan con el plazo aparte, según el veredicto, expuesto arriba, y la limpieza del historial de análisis no los toca. Como pueden sobrevivir al análisis del que proceden, tienen su propia lista en el portal —consulta Quién puede verla más arriba—, de modo que una captura sigue siendo accesible, y se puede eliminar individualmente, durante todo el tiempo que se conserva. A menos que tu organización informe de forma agregada, que es el modo en el que empieza toda organización: allí la lista no se muestra a nadie y el botón de todo el historial que aparece más abajo es la única vía.

Los registros de triaje, de visita y de verificación de archivos se eliminan automáticamente. A cada uno se le da su fecha de eliminación cuando se escribe, a partir del plazo vigente en ese momento para la cuenta bajo la que se escribe:

Cambiar un plazo cambia solo la fecha de eliminación de los registros escritos después del cambio: un plazo más corto no elimina antes los registros más antiguos, y uno más largo no los conserva más tiempo. Así que un registro de análisis o de visita escrito antes del cambio a 365 días conserva los 90 días que se le dieron. Los registros de verificación de archivos no tenían fecha de eliminación hasta que empezamos a dar una a cada registro, poco antes de que la versión 1.10 entrara en vigor: a los realizados antes de entonces se les dieron 365 días desde que se hizo cada uno, y a los realizados entre entonces y el cambio a 365 días se les dieron 90. Varias veces al día, una limpieza de conservación elimina todos los registros que han superado su fecha de eliminación, así que un registro puede sobrevivir a su fecha unas horas.

Los informes que envías con los botones bajo un veredicto no siguen estos plazos: la misma limpieza elimina cada uno a los 90 días de recibirlo, sea cual sea el plazo que se aplique a tus análisis.

Cuando tú o la persona propietaria de un equipo cambian un plazo, guardamos un registro de quién lo cambió, de qué a qué y cuándo y, si es un cambio de tu propio plazo, el plazo del equipo en ese momento. No contiene contenido de análisis, y ni la limpieza ni el botón Delete my scan history lo eliminan.

El valor predeterminado se configura en el servidor (RETENTION_DAYS); los proxies de alojamiento propio eligen el suyo o no establecen ninguno, en cuyo caso los registros sin plazo elegido se conservan hasta que se eliminan a mano, y esta política no se aplica a esa implementación. Hasta la versión 1.9, esta sección describía un único plazo de conservación de 90 días para todos los registros de triaje y de visita y para todos los informes, y no mencionaba los registros de verificación de archivos, que nada eliminaba.

Independientemente de la limpieza:

ID seudónimo

Tu instalación se identifica con una cadena aleatoria a la que llamamos «pseudoId». Se almacena en chrome.storage.local bajo la clave pseudoId y se envía con cada solicitud de triaje y de visita. Según si te has registrado o no, es una de dos cosas:

Ninguna de las dos formas se deriva de tu correo electrónico, tu dirección IP, el ID de tu hardware, una huella digital del dispositivo ni ningún otro identificador. Ambas son números aleatorios nuevos. Tratamos el ID como una clave de correlación, no como prueba de quién eres: existe para que el uso repetido desde la misma instalación se pueda vincular en el servidor (para la caché, o para mostrarte un historial por dispositivo en el portal), no para identificarte como persona.

Cuándo ocurre el registro, corregido. Esta sección decía antes «el registro es una acción explícita; no ocurre al instalar». Ocurre lo contrario, y así es desde que el registro dejó de ser un botón: se ejecuta automáticamente a partir del evento de instalación del navegador, y de nuevo antes del primer análisis de una sesión si ese intento no tuvo éxito. No hay ningún control de registro en la ventana emergente. Así que, en una red que funcione, el ID generado por el dispositivo de arriba existe solo hasta que se completa la primera llamada a /register, y toda instalación tiene una identidad generada por el servidor antes de que hayas hecho nada con la extensión.

El registro no es la creación de una cuenta ni implica ninguna cuenta tuya. Lo que envía es el pseudoId actual, en qué navegador estás, una etiqueta vacía y —solo en una flota donde un administrador ha enviado uno mediante una política— un token de inscripción que vincula el dispositivo a esa organización. Ninguna dirección de correo electrónico, y nada de lo que escribes. Si falla, falla en silencio y se reintenta más tarde: un dispositivo sin registrar sigue analizando.

Desde la versión 1.1.0 de la extensión, esta también envía un token de inscripción, y nada más, a /devices/enrol, con la credencial propia del dispositivo, siempre que tiene uno sobre el que el backend aún no ha dado una respuesta definitiva. Eso incluye un token que un administrador envía a un dispositivo que ya está instalado, o que el administrador cambia; un token que el registro llevó pero que no unió el dispositivo a una organización; y, una vez, un token ya establecido por política cuando un dispositivo se actualiza a la versión 1.1.0. Vuelve a enviar el mismo token solo hasta que el backend le ha dado una respuesta definitiva: tras una solicitud que se quedó sin respuesta —el backend ocupado, caído o inaccesible— espera, más tiempo después de cada fallo, y lo intenta de nuevo. Lo que guarda sobre eso en tu dispositivo se enumera en Qué guarda la extensión en tu propio dispositivo.

Antes derivábamos el identificador de quien se había registrado a partir de un hash de su dirección de correo electrónico. Ya no lo hacemos, y esa derivación se ha eliminado: un valor calculado a partir de una dirección de correo electrónico no es genuinamente seudónimo, porque cualquiera que tenga la dirección puede volver a calcularlo.

La fila de cuenta de la ventana emergente puede descartar esa identidad. Este documento llamaba antes Unregister a ese control, que no es una palabra de la interfaz: el botón dice Leave team cuando tu dispositivo pertenece a una organización y Sign out cuando has iniciado sesión por tu cuenta, y aparece solo en esos dos casos. Cualquiera de los dos borra extensionId, pseudoId, la organización y los tokens almacenados, y desde la versión 1.1.0 de la extensión también el registro de inscripción, y después se registra de nuevo de inmediato, así que acabas con una identidad nueva generada por el servidor, en lugar de ninguna. Desde el punto de vista del backend, eres una instalación distinta; tus registros antiguos se quedan donde están y ya no se pueden alcanzar desde este dispositivo.

Cuándo un mismo ID abarca varios dispositivos, corregido. Este párrafo decía antes que vincularse a un equipo «mediante un código de invitación» sobrescribía tu pseudoId con el de la persona propietaria del equipo, y que esa era la única forma en que un mismo ID llegaba a más de un dispositivo. Todo eso es ahora erróneo. Ya no hay ningún campo de código de invitación en la extensión —escribir allí un código inscribía un dispositivo en el equipo sin ninguna persona asociada, así que se eliminó—, y un dispositivo ahora se une a un equipo desde el portal, donde un administrador puede ver qué se asocia a quién.

Lo que ocurre en realidad: cuando inicias sesión, o cuando un administrador vincula tu dispositivo desde el portal, tu pseudoId local se sustituye por el ID de esa cuenta. Nunca es un ID de organización —esos son un espacio de nombres aparte— y, cuando un administrador vincula un dispositivo desde el portal, el ID que toma es el de la cuenta a la que lo vinculó, que puede no ser la tuya. La ventana emergente lo vuelve a leer del servidor cada vez que la abres. Así que cada dispositivo en el que inicias sesión lleva el mismo ID y las solicitudes de todos ellos se vinculan en el servidor; eso es lo que convierte varios dispositivos en un solo historial, y es igual de cierto en un inicio de sesión personal que en uno de equipo. Una instalación en la que nunca se ha iniciado sesión conserva un ID exclusivo suyo.

Inteligencia de amenazas compartida

Esta sección se agregó en la versión 1.7 y describe un destino para tus datos que ninguna versión anterior a la 1.7 mencionaba. Está escrita antes de que la función se active y no después, que es el único orden que da valor a la divulgación.

Operamos un centro de inteligencia interno: un servicio nuestro que recopila indicadores —URL de enlaces, dominios, hosts, hashes de archivos— de nuestros propios análisis y de socios, para que una página que un cliente denuncia pueda reconocerse al instante para todos los demás. No es un tercero. Tampoco es este proxy, y ese es el sentido de esta sección: es un tercer destino, junto a los dos hosts nombrados en Terceros encargados del tratamiento, y los datos derivados de tus análisis pueden llegar a él.

Todos los flujos descritos a continuación están desactivados en la configuración que se distribuye y, a la fecha de entrada en vigor indicada al principio de este documento, todos están desactivados en el servicio alojado. Donde uno está activado, esto es exactamente lo que ocurre. Hasta la versión 1.9, este párrafo decía que cada uno seguiría desactivado en el servicio alojado hasta que una revisión fechada de este documento dijera otra cosa. Desde la versión 1.10, uno puede activarse sin otra revisión, así que esta sección está escrita para ser cierta tanto si está activado como si no. Toda afirmación de este documento según la cual el centro, un flujo hacia él o su configuración no se usa en el servicio alojado es una afirmación a la fecha de entrada en vigor, no una promesa de que siga siendo así.

Qué sale y qué no sale nunca

Solo valores derivados de un análisis, nunca su contenido:

Consultar al centro antes que a un modelo. El proxy también puede preguntar al centro por esas mismas URL de enlaces, dominios, hosts, dominio del remitente y hashes antes de que un modelo lea el mensaje, y espera la respuesta una fracción de segundo. Si el centro ya tiene uno de ellos como malicioso y marcado como apto para que se actúe sobre él de forma automática, esa respuesta pasa a ser el veredicto y no se consulta a ningún modelo; el registro de triaje y su línea de registro no nombran entonces ningún nivel como el que respondió. Cualquier otra respuesta, o ninguna a tiempo, no cambia nada, y el análisis va a un modelo como habría ido.

Una captura que confirma una persona propietaria. Cuando una persona propietaria de una organización confirma una captura de phishing (Guardar pruebas de páginas de phishing), la dirección de la página, recortada del mismo modo, y un hash de su HTML se envían como un hallazgo confirmado sobre esa página, y un rechazo posterior de la captura lo retira. Cuando se quitaría la ruta de la dirección, no se envía nada. Una captura de un mensaje de correo no tiene dirección de página, así que confirmarla no envía nada. La captura de pantalla y el HTML en sí nunca se envían. El hallazgo no lleva ningún seudónimo y se envía en nombre del propio proxy, no de la persona propietaria. Como todo lo que el proxy envía al centro, se archiva bajo la organización, con la hora (consulta Cuánto tiempo conserva el centro lo que recibe).

Lo que nunca sale del proxy hacia el centro: el cuerpo del mensaje, la línea de asunto, el HTML, los encabezados sin procesar, el destinatario, la dirección del remitente, los nombres de los archivos adjuntos, las capturas de pantalla, el código fuente de la página y cualquier cosa que hayas escrito. Esa misma lista se aplica en el código y la verifica una prueba automatizada que serializa una contribución construida a partir de un mensaje relleno con cada uno de esos elementos y los busca en sus bytes.

El seudónimo y su ámbito

Una contribución lleva una referencia de sujeto: un hash con clave que representa tu cuenta, calculado como HMAC(HMAC(secret, organisation), account). De ello se derivan tres consecuencias, y son la razón de que no sea un hash simple:

Tus correcciones, cuando el reenvío está activado

Lo que conservamos de un clic en el botón Looks safe to me o en el botón Looks dangerous se expone en Tus correcciones a un veredicto, y esa parte no depende del centro. Con el reenvío de informes activado, cada informe también se envía al centro como un informe sobre la página: tu respuesta, la dirección de la página recortada a su esquema, host y ruta (ninguna en absoluto para un informe hecho sobre un correo, ni cuando la ruta parece contener un token propio de cada destinatario), la hora que indicó tu dispositivo (la nuestra, si no indicó ninguna), qué tipo de cliente lo envió, un identificador aleatorio del propio informe y el seudónimo de arriba, archivado bajo tu organización; nada más sobre ti, y nada en absoluto para una cuenta sin organización. Se envía como un informe de peso bajo, marcado como motivo insuficiente por sí solo para bloquear la página, y el seudónimo que lleva sigue el plazo propio de 90 días del informe (más abajo).

Cuánto tiempo conserva el centro lo que recibe, y hasta dónde llega la eliminación

El centro conserva lo que se le da sin límite de tiempo, y suelta el seudónimo que lo vincula contigo cuando lo hace nuestro registro. Lo que conserva es lo que es un indicador: la propia URL del enlace, dominio, host o hash, con qué frecuencia se vio, las afirmaciones hechas sobre él y el veredicto alcanzado y, por cada observación, informe reenviado y hallazgo confirmado que envía el proxy, de qué organización procedía y cuándo. Lo que no conserva más allá de nuestro propio registro es el seudónimo que vincula una observación contigo. Cada contribución indica al centro cuántos días faltan para que se elimine aquí el registro del que procede —el análisis, en el caso de una contribución de un análisis, según el plazo descrito en Plazos de conservación; el informe, en el caso de un informe reenviado, según el plazo de 90 días de los informes— y, cuando se cumple ese plazo, el centro quita el seudónimo y conserva el resto. Eso ocurre dentro de un día desde la fecha en que se elimina nuestro registro, y más tarde solo si el proceso propio del centro no se está ejecutando. Una contribución hecha a partir de un registro que ya ha superado su fecha no lleva ningún seudónimo.

Lo que conserva el centro todavía puede apuntar a ti. La organización y la hora se conservan sin límite de tiempo. En una organización con un solo miembro, la organización identifica a ese miembro. En cualquier organización, podríamos cotejar la hora de una observación con nuestro registro de la aplicación, cuya línea de triaje lleva tu pseudoId y la hora de cada análisis, mientras ese registro se conserve (consulta El registro de la aplicación). Y una vez que el centro ha soltado el seudónimo de una observación, el botón Delete my scan history ya no la alcanza, porque ya nada en ella te nombra.

Conviene decir esto con claridad porque es el único lugar al que no llega nuestra propia limpieza de conservación: la limpieza elimina filas de nuestra base de datos y no puede eliminar una fila de la del centro. Hasta la versión 1.9, esta sección decía que las contribuciones llevaban una caducidad que establecíamos nosotros, igual al plazo de tu historial de análisis. El centro conserva el indicador en su lugar, y lo que termina con el plazo es el seudónimo.

El botón Delete my scan history también llega al centro. Cuando eliminas tu historial, el proxy pide al centro que borre todo lo registrado bajo tus seudónimos —una solicitud por cada organización bajo la que hayas contribuido alguna vez, incluidas aquellas que has dejado desde entonces— y el centro devuelve un recibo; conservamos su identificador y un hash de él con nuestro registro de la eliminación. El portal te muestra cuál de las tres cosas ocurrió, bajo el resultado de la eliminación: el borrado se confirmó (con el identificador del recibo), no había nada que borrar allí, o no se pudo confirmar por ahora. La tercera no es un fallo de tu eliminación: tus registros de aquí han desaparecido de cualquier manera, y esa frase significa que la copia compartida aún no se ha confirmado. No se archiva nada en el centro bajo tus seudónimos —ninguna contribución ni ningún informe reenviado— a menos que este borrado también esté activado.

Dos límites honestos. Un indicador que ya se agregó al propio juicio del centro sobre una URL —«varias personas han denunciado esta página»— no desaparece cuando desaparece el vínculo contigo; lo que se borra es la relación entre tú y la observación, y el recibo del centro lo dice con sus propias palabras. Y una afirmación que el centro ya ha distribuido a un consumidor posterior no se puede despublicar eliminando la fila que la produjo.

Qué puede enviar el analizador de archivos

El analizador de archivos de filescan.phishtriage.com también puede estar conectado al centro. A la fecha de entrada en vigor indicada al principio de este documento, no lo está. Cuando lo está, envía, por cada archivo que su análisis profundo detectó como malware, incluidos los archivos verificados antes de que se conectara y antes de que la versión 1.10 entrara en vigor, mientras se conserve el registro de la verificación: la huella SHA-256 del archivo, su tamaño, el nombre de la firma de malware con la que coincidió, cuándo se verificó el archivo y una referencia a su propio registro de esa verificación. Nunca el archivo, su nombre, tu cuenta, tu dispositivo ni un seudónimo. El centro descarta la referencia a nuestro registro cuando llega la fecha de eliminación de ese registro, según el plazo descrito en Plazos de conservación, y conserva la huella y el veredicto. No se envía un archivo cuyo registro ya ha superado su fecha. Cada uno se envía como una afirmación ponderada de modo que una sola detección baste para que el centro considere maliciosa la huella, y una huella que el centro considera maliciosa se puede transmitir a otros que usan las listas del centro, que es para lo que sirve la contribución.

La lista de bloqueo, que viaja en sentido contrario

El proxy también puede obtener una lista de bloqueo del centro, es decir, datos que nos llegan en lugar de datos que salen. No se envía nada sobre ti para obtenerla: es una lista firmada de nombres de host y URL, solicitada sin ningún parámetro derivado de la actividad de ninguna persona. Se menciona aquí para que esté completo, no porque revele nada.

Hay otras dos obtenciones parecidas. Cuando el analizador de archivos está conectado al centro, obtiene la lista firmada del centro con huellas de malware conocido, y un archivo cuya huella figura en ella se califica de malicioso sin que se envíe el archivo. Y desde la versión 1.1.0 de la extensión, cuando la política de un administrador nombra un centro y las claves que firman sus listas (intelHubUrl y intelRootJwks), la extensión, con la protección de archivos activada, pide a ese centro la lista de bloqueo de descargas cuando una descarga la necesita, y pide a nuestro proxy solo cuando el centro no le da nada. Tras una obtención que le da una lista, no vuelve a preguntar al centro durante una hora. En caso contrario, cuando la lista del centro está vacía o la última obtención falló o fue rechazada, vuelve a preguntar en la siguiente descarga, y así en cada descarga hasta que una obtención le da una lista. La solicitud no lleva nada sobre ti, pero va desde tu navegador directamente al centro, así que el centro ve tu dirección de red y, como cada solicitud sigue a una descarga, cuándo descargas, aunque no qué.

Terceros encargados del tratamiento

Anthropic: la API de Claude, y el último nivel del orden expuesto en Dónde se realiza el análisis. El contenido le llega cuando los niveles que la preceden no responden, lo cual es una condición y no una frecuencia. Deliberadamente no imprimimos aquí una proporción: sería la medición de un solo momento presentada como una propiedad del servicio, y la configuración errónea descrita en Dónde se realiza el análisis es lo que eso parece cuando ocurre en sentido contrario. Este párrafo empezaba antes con «cuando haces clic en Analyze, el proxy reenvía el contenido extraído a la API de Claude de Anthropic para su análisis»: incondicional, correcto en que Anthropic recibe contenido y erróneo en cuanto al enrutamiento. Anthropic actúa como encargado del tratamiento por cuenta nuestra según los términos de su API; según esos términos, Anthropic no usa las entradas de las solicitudes a la API para entrenar modelos. Consulta anthropic.com/legal/privacy para ver sus compromisos sobre el tratamiento de los datos.

Ollama: un servicio de modelos alojado de terceros (Ollama Cloud), nombrado aquí antes de usarse y no después. Es el nivel intermedio de ese mismo orden, y un nivel forma parte de la vía solo cuando está configurado, que es la regla expuesta en Dónde se realiza el análisis. A la fecha de entrada en vigor de esta versión, no está configurado en ninguna implementación que operemos. Esa es una afirmación a la fecha de entrada en vigor indicada arriba, no una permanente; la regla que perdura es la de la frase anterior: un nivel forma parte de la vía solo cuando está configurado.

Nombramos a un encargado del tratamiento que no se usa por dos razones, y creemos que la alternativa es peor. Activarlo no requiere código nuevo ni una versión nueva —tres valores de configuración y un reinicio—, de modo que la distancia entre «no forma parte de la vía» y «forma parte de la vía» es de minutos, mientras que la distancia entre editar este documento y que te llegue pasa por la revisión de una tienda. Y esta divulgación es lo que la activación debe esperar: la configuración de implementación dice con todas las letras que esta política debe nombrar a Ollama antes de que ese nivel lleve tráfico real. Una política que hay que reescribir el día en que alguien establece tres variables de entorno es una trampa, así que preferimos nombrar de más a un encargado del tratamiento que de menos. Si llega a recibir tráfico, lo que recibe es lo que habría recibido el nivel anterior —el contenido descrito en Qué recopila la extensión y cuándo y en Mensajes de texto— y nada adicional.

Los registros se almacenan en una base de datos PostgreSQL en hardware que poseemos y operamos, ubicado en Estonia. Esa frase trata del host de la base de datos y solo de él; consulta Dónde se realiza el análisis para saber por qué este documento no te dice dónde está el servidor de modelos. Desde que la producción pasó a PostgreSQL en agosto de 2026, ningún proveedor de almacenamiento de terceros ha conservado los registros descritos en Qué almacena el backend: no hay ningún proveedor de bases de datos administradas en la vía. Cloudflare, Inc. transporta el tráfico entre tu navegador y nuestro servidor (terminación TLS, túneles, protección contra DDoS) y es un encargado del tratamiento solo de los datos en tránsito; no almacena tus registros.

Hasta la versión 1.7, esta sección describía una excepción heredada: los registros creados antes de la migración de agosto de 2026 a nuestro propio hardware, los registros del período beta, anteriores al lanzamiento, permanecían en nuestro almacén de datos anterior en Elastic Cloud (Elasticsearch como servicio administrado, región europe-west3 de GCP, bajo el DPA de Elastic), fuera de la eliminación automática a los 90 días. Eliminamos ese proyecto de Elastic Cloud el 2 de octubre de 2026, y no conservamos ninguna exportación, instantánea ni copia. Lo que la propia Elastic conserva de un proyecto eliminado, como sus propias copias de seguridad, y durante cuánto tiempo, se rige por sus términos y por su acuerdo de tratamiento de datos con nosotros; ya no le enviamos nada. Los registros creados desde que la producción pasó a PostgreSQL en agosto de 2026 nunca se almacenaron allí.

Esta sección terminaba antes con «no usamos ningún otro encargado del tratamiento externo». Anthropic, Cloudflare y Elastic eran toda la lista cuando lo decía. Llegaron dos más con las cuentas y la facturación, y a ambos se llega desde el botón Log in de la ventana emergente:

Aparte de estos: ni estadísticas de uso, ni publicidad, ni SDK de telemetría, ni servicios de informe de errores, ni bibliotecas de huella digital del navegador. Esa es una afirmación sobre lo que hemos incorporado al producto, no una afirmación de que nunca se contacte con un tercero: las dependencias de Google del portal descritas arriba sí contactan con un tercero, en cada página.

Tres destinos reciben tus datos, y los tres son nuestros:

Los tres los operamos nosotros en el hardware descrito arriba; ninguno es un tercero. La política de administración de una organización puede dirigir los dos primeros a un servicio de alojamiento propio en su lugar, en cuyo caso describir ese servicio corresponde a tu organización, no a nosotros.

Una solicitud más, que la redacción anterior negaba. Esta lista se presentaba antes como «la extensión habla con dos hosts, ambos nuestros, y con nada más». Eso no es cierto desde que se lanzó la protección de archivos. Con la protección de archivos activada, una descarga normal tiene que obtenerse una segunda vez para poder inspeccionarse —el navegador no entrega a una extensión los bytes de una—, y esa segunda solicitud va a la dirección de la que procedía la propia descarga, que puede ser cualquier host de Internet, con tus cookies de ese sitio para que se pueda leer también un archivo protegido por un inicio de sesión. Lo que ve el sitio es una segunda solicitud del archivo que acaba de servirte: la solicitud no lleva ningún encabezado, identificador ni parámetro nuestro, y no dice nada sobre el resto de tu navegación. Los bytes no pasan de la memoria de tu navegador a menos que la sección de protección de archivos de arriba diga otra cosa. Con la protección de archivos desactivada, no ocurre.

Alojamiento propio

Las organizaciones pueden ejecutar su propio proxy y dirigir su flota hacia él enviando una política de administrador mediante el almacenamiento administrado empresarial (consulta el esquema managed-storage.json en el código fuente). Esta es deliberadamente la única forma de cambiar el backend: no hay ninguna opción que pueda cambiar quien usa la extensión, así que no se puede convencer a nadie de pegar la URL de un atacante y dirigir hacia ella su correo analizado. Cuando tu organización aloja ella misma el servicio, el resto de este documento sigue describiendo el comportamiento de la extensión, pero el comportamiento del backend se rige por la política de tu operador, no por la nuestra. Tu equipo de TI es el responsable del tratamiento de esos registros. No tenemos acceso a los datos de un proxy de alojamiento propio.

Tus derechos

Tienes, según la jurisdicción, derecho a:

Responderemos a las solicitudes en un plazo de 30 días. Si has usado la extensión en varios navegadores sin vincularlos, cada instalación tiene un pseudoId distinto y puede que tengas que solicitar la eliminación para cada una.

Cambios en esta política

Cuando hagamos un cambio sustancial —una nueva recopilación de datos, un nuevo encargado del tratamiento, un plazo de conservación más corto o más largo— actualizaremos la Versión y la Fecha de entrada en vigor al principio de este documento y, cuando sea razonable, mostraremos un aviso en la página de bienvenida que se abra la próxima vez que se inicie la extensión. El historial completo de revisiones de este documento se guarda en git; el repositorio no es público hoy, así que escribe a privacy@phishtriage.com para pedir una versión anterior y te la enviaremos. Este párrafo enlazaba antes el archivo directamente, lo que devolvía un error 404 a todo el mundo.

Versión 1.10, y cómo se te informó de ella. La versión 1.10 es un cambio sustancial. Alarga un plazo de conservación: en el servicio alojado, los registros de análisis, de visita y de verificación de archivos escritos después del cambio al nuevo valor predeterminado se conservan 365 días, mientras que los escritos antes conservan el plazo que se les dio, y ahora puedes elegir un plazo más corto, de 7 días como mínimo, y también puede hacerlo la persona propietaria de tu equipo. Describe, por primera vez, registros que ya conservábamos: los registros de verificación de archivos que el analizador de archivos ha escrito desde que se lanzó la protección de archivos, que nada eliminaba, y el registro propio del analizador de archivos. Agrega el registro que guardamos de cada cambio de un plazo de conservación, y las dos líneas de capacidad que lleva nuestro registro de la aplicación desde el 3 de octubre de 2026. Cambia lo que conserva el centro de inteligencia: indicadores, con la organización de la que procedía cada uno y cuándo, sin límite de tiempo, y el seudónimo que los vincula contigo solo mientras exista nuestro registro de él. Dice qué enviaría el analizador de archivos al centro si estuviera conectado, incluidas las verificaciones hechas antes de entonces. Permite que un flujo hacia el centro se active sin otra revisión de este documento, algo que este documento decía hasta la versión 1.9 que no ocurriría. Y describe qué cambia la versión 1.1.0 de la extensión respecto de la versión 1.0.0, y corrige varias frases en su sitio, cada una nombrando la versión que corrige.

No mostramos un aviso en la página de bienvenida de la extensión para la versión 1.10: ninguna versión de la extensión lo incluye. En su lugar, el panel del portal muestra un aviso único, una vez que se activa la opción de elegir el plazo de conservación: «You can now choose how long we keep your scans, from 7 days to 1 year.» (ahora puedes elegir cuánto tiempo conservamos tus análisis, de 7 días a 1 año). Se muestra a las personas que inician sesión en el portal y pueden elegir un plazo de hasta un año, o que establecen el plazo de su equipo. A un miembro de un equipo que conserva los análisis menos de un año no se le muestra, y el aviso no menciona el nuevo valor predeterminado ni ningún otro cambio. Si no inicias sesión en el portal, nada salvo este documento te informa de la versión 1.10.

Contacto

privacy@phishtriage.com

Para notificar problemas de seguridad (vulnerabilidades de la extensión o del proxy), escribe a security@phishtriage.com.