Cómo prueba CookieHawk los sitios web

Método v1.0 · agosto de 2026 · versionado y abierto

Versión 1.2, revisada por última vez el 22 de agosto de 2026. Los textos se basan en el artículo 3-15 de la ley noruega de comunicaciones electrónicas, el RGPD y las orientaciones de la autoridad noruega de protección de datos, con control de calidad interno; no son un dictamen jurídico. Consultas: kontakt@cookiehawk.com.

1. Qué es la prueba

La prueba es un muestreo técnico automatizado, no una conclusión jurídica. Un contexto aislado de Chromium (Playwright), con idioma nb-NO, zona horaria Europe/Oslo y área visible de 1366 × 900, visita la página de inicio y hasta tres subpáginas públicas en cada estado. El país de la IP del tráfico lo determina el servidor del escáner (EEE). La prueba puede generar hasta 12 cargas de página. No inicia sesión ni rellena formularios.

2. Tres estados

1. Antes de elegir: se carga la página sin hacer clic. Todos los contactos y el almacenamiento se producen antes de que el visitante decida.
2. Después de «Rechazar todo»: un navegador nuevo y vacío. El escáner encuentra el banner, selecciona el rechazo en la primera capa cuando existe y continúa a las subpáginas.
3. Después de «Aceptar todo»: un navegador nuevo y vacío con aceptación. Sirve de referencia de lo que puede enviar el sitio.

Cada estado se ejecuta en un contexto de navegador independiente, por lo que no se arrastran cookies ni almacenamiento entre estados. La actividad se atribuye al estado según el momento real de envío de la solicitud respecto al clic.

3. Cuándo se considera confirmado «Rechazar todo»

El escáner prueba primero un botón de rechazo visible en la primera capa del banner. Si no existe, abre los ajustes y prueba el rechazo en la segunda capa. La ausencia del botón en la primera capa se comunica como observación independiente, pero no impide confirmar técnicamente el rechazo.

Se registra confirmación técnica cuando la API de la CMP (por ejemplo, Cookiebot, OneTrust, TCF, Usercentrics o Google Consent Mode) indica rechazo, cuando un clic en un botón conocido de CMP o de la segunda capa cierra el banner visible o, si el banner no era visible, cuando cambia una cookie o un valor de almacenamiento relacionado con el consentimiento. Si el clic se basa solo en heurística textual, se exige tanto el cierre del banner como un cambio de estado. Si la API de la CMP indica otro estado (por ejemplo, «granted»), no se confirma la elección. La fuerza probatoria varía y no demuestra por sí sola que se hayan rechazado todos los fines y proveedores. Los clics no confirmados no fundamentan observaciones «después del rechazo confirmado».

4. Qué registramos

• Solicitudes de red con nombre de host, método, tipo de recurso y fecha y hora. Las URL se guardan con un máximo de 300 caracteres; se enmascaran nombres de parámetros sensibles conocidos, correos, teléfonos, valores largos y determinados patrones de tokens. Otras partes de la ruta y la consulta pueden permanecer y contener datos personales. Se registran hasta 900 solicitudes por estado.
• Set-Cookie y nombres de cookies, dominio, ruta y duración declarada, pero no los valores de las cookies.
• Hasta 100 nombres de claves de localStorage/sessionStorage en la última página visitada.
• Señales de consentimiento observadas (estado de Consent Mode, presencia o ausencia de cadena TCF, API de la CMP).
• Iniciador técnico probable: si la llamada procede de un contenedor de Tag Manager, un plugin, un elemento integrado o el propio script, según la cadena de iniciadores del navegador.
• Si están activadas las capturas: una imagen final comprimida por estado, para aportar contexto.

5. Clasificación y prioridad

Los servicios se clasifican mediante una base de datos versionada de herramientas conocidas de seguimiento, analítica y publicidad, con categoría y fuente. La «prioridad técnica» puede ser muy alta, alta, media, baja o información e indica el seguimiento que merece una observación. Cada observación también tiene un nivel de confianza: alto, medio, bajo o no concluyente. La prioridad es una ordenación técnica y no determina la valoración jurídica. Contactar con un tercero no demuestra por sí solo que se hayan almacenado o consultado datos en el dispositivo ni que se hayan tratado datos personales.

Ejemplos de criterios para evitar exageraciones: las señales de Consent Mode sin cookies con estado denegado (gcs=G100) se clasifican como información, no como observación prioritaria. Los elementos funcionales integrados (mapas, vídeo, chat) visibles para el visitante se valoran por lo que realmente almacenan, no solo por su categoría. Si el escáner no encuentra un banner pero observa servicios usados habitualmente para fines basados en el consentimiento, crea una observación independiente («no se encontró banner»). El resultado requiere revisión manual porque el banner puede depender de la ubicación o del momento, o puede haber fallado la detección.

6. Limitaciones conocidas

• El resultado corresponde a un momento, a la IP de salida/geolocalización indicada en el informe (servidor del escáner en el EEE; idioma y zona horaria no hacen que la prueba sea geográficamente noruega por sí solos) y a las páginas visitadas. Las pruebas A/B, el inicio de sesión, el idioma, los errores de red, las llamadas tardías y los límites de recursos del escáner pueden influir.
• La heurística reconoce textos de banner en noruego bokmål, nynorsk, sueco e inglés; otros idiomas pueden producir «no se encontró banner» aunque exista uno.
• Podemos observar algunas llamadas del cliente a endpoints de servidor conocidos (como Tag Manager del lado del servidor), pero no el tratamiento posterior detrás de un endpoint.
• Nuestro banner retiene herramientas de seguimiento conocidas que se cargan dinámicamente; el propietario debe marcar los scripts incluidos directamente en el HTML. Un banner no puede borrar cookies de terceros. Por eso verificamos cada sitio por separado.
• Los informes se generan automáticamente y pueden contener errores. Solo se indica revisión manual cuando está documentada; en caso contrario debe constar que no se ha revisado manualmente. Corregimos los errores verificados.

7. Datos, eliminación y derecho de respuesta

Los perfiles temporales del navegador y los artefactos sin procesar se eliminan tras el análisis. Los informes finales se conservan según el calendario de conservación (en noruego) y se comparten confidencialmente con quien solicitó la prueba. Los propietarios afectados y los proveedores citados pueden pedir correcciones o responder mediante kontakt@cookiehawk.com; respondemos en 5 días laborables.

8. Las cifras de la página de inicio

Las cifras de mercado solo se publican con un conjunto de datos congelado, versión del escáner, fecha, definiciones y cálculo documentado. Las cifras de inicio proceden de la calibración v7 (escáner cmp-scan 0.1.0, ejecutado el 21 de agosto de 2026 de 07:51 a 08:14, hora de Noruega; dagbladet.no se volvió a escanear ese día), congelada el 21 de agosto de 2026 en 60 archivos JSON con sumas sha256 y tabla por sitio (data/KALIBRERING-V7-FRYST.md). Se calculan automáticamente a partir de los archivos con estas definiciones:

• 59 probados: se intentaron 60 sitios noruegos (banca, medios, comercio electrónico, asociaciones, inmobiliarias, clínicas); uno (dominio IDN con error de certificado) no completó el estado «antes de elegir» y queda excluido de todos los recuentos.
• 50 con actividad antes de elegir: al menos una observación en el estado «antes de elegir» con prioridad técnica muy alta, alta o media (tipos pre_consent_tracker/pre_consent_cookies; no cuentan las cookies ambiguas ni los pings de Consent Mode sin cookies).
• 31 con actividad después del rechazo confirmado: el rechazo se confirmó técnicamente y al menos una observación de ese estado tenía prioridad muy alta, alta o media. Se pulsó el rechazo en 47 sitios y se confirmó en 44.
• 10 de 52 banners sin rechazo en la primera capa: 52 sitios tenían un banner de consentimiento reconocido; en 10 el escáner no encontró una opción de rechazo en la primera capa.
• 8 sin observaciones prioritarias: ninguna observación con prioridad muy alta, alta o media (puede haber baja/información).

La muestra no es representativa de todos los sitios noruegos. El conjunto de datos, con URL enmascaradas, y el script de cálculo pueden revisarse a petición.

Método v1.0 · escáner cmp-scan 0.1.0 · 22 de agosto de 2026 · Los cambios de las reglas de prueba se registran aquí.