Permissions Policy, capacidades del navegador y privacidad

BotBrowser puede repetir un recorrido autorizado con un contexto declarado y observar el resultado visible. No escribe ni despliega la política, concede permisos, crea dispositivos ni prueba un registro remoto. Permissions Policy limita qué documentos pueden usar determinadas capacidades del navegador. La respuesta superior fija el máximo y allow del iframe delega una función a un origin hijo. Es un límite de capacidad, no un permiso del usuario, una garantía de dispositivo ni una prueba de que terminó una operación. Esta guía sigue la especificación W3C y MDN.

TL;DR

Usa la lista mínima de funciones y origins, comprueba el origin final tras redirects, alinea header y allow, y compara un fixture propio de control y candidato. Un frame permitido aún puede carecer de API, contexto seguro, activación, permiso, dispositivo o confirmación de la aplicación. BotBrowser puede repetir un recorrido autorizado y observar su resultado visible; no escribe ni despliega la política, concede permisos, crea dispositivos ni prueba un registro remoto.

Contents

• Qué controla la política
• Separar las puertas de capacidad
• Distinguir políticas relacionadas
• Usar un fixture reproducible
• Conclusión práctica

Qué controla la política

Permissions-Policy: geolocation=(self "https://widget.example") permite que la página y el widget intenten geolocalización. El iframe aún necesita allow="geolocation" y todos los ancestros deben conservar la delegación. Un redirect a otro esquema, host o puerto puede invalidar el origin final. Los valores predeterminados dependen de la función.

No uses allow="*" por comodidad: delega la función a cualquier origin que ocupe el contenedor, incluso un redirect inesperado. Mantén una allowlist explícita, registra quién posee el header y el markup, y elimina las entradas cuando termine la integración. Un hijo no puede recuperar una función eliminada por un ancestro.

La elegibilidad de política no es el estado de permiso. navigator.permissions puede mostrar prompt o granted mientras el frame está bloqueado. También puede haber denegación, timeout, dispositivo ausente o error específico del navegador. Registra la primera puerta que falla.

Separar las puertas de capacidad

Puerta	Evidencia	Lo que no demuestra
Origin y contexto final	URL, esquema, puerto y contexto seguro	Que exista la API
Capacidad de API	Comprobación estrecha de la interfaz	Que la solicitud sea permitida
Permissions Policy	Header, allow, ancestros y origin hijo	Consentimiento o dispositivo
Decisión del usuario/plataforma	Permiso, ajuste administrador y dispositivo	Que la aplicación aceptó datos
Resultado de aplicación	Estado visible o confirmación propia con timeout	Que se guardó un registro remoto

Pide al frame hijo que informe su propio origin y estado mediante una página de prueba propia. Usa permisos sintéticos y estables; no recojas coordenadas, medios, credenciales ni contenido de cuentas.

Distinguir políticas relacionadas

CSP controla scripts, conexiones, recursos y frames. COOP configura relaciones entre contextos superiores. COEP establece condiciones para recursos cross-origin. Ninguno delega cámara o geolocalización, y Permissions Policy no crea aislamiento cross-origin ni satisface CORS/CORP.

Comprueba red y CSP, después origin final y COOP/COEP si aplica, luego la cadena de Permissions Policy y solo al final solicita la función mediada por el usuario. Error de red, bloqueo de política, rechazo y error de aplicación tienen propietarios distintos. Ningún header sustituye autorización del servidor, consentimiento, validación o controles del dispositivo.

Usar un fixture reproducible

Sirve /fixtures/permissions-policy/control.html y candidate.html en un host propio. Mantén iguales ruta, frame, botón y marcador; solo candidate recibe el header propuesto. Tras un clic explícito, el hijo muestra policy=blocked o policy=allowed. Son marcadores de la aplicación, no evidencia del navegador por sí solos: comprueba también el Permissions-Policy entregado, allow del iframe y el origin final del hijo.

import { test, expect } from '@playwright/test';
const cases = [
  { name: 'control', url: 'https://qa.example.test/fixtures/permissions-policy/control.html', expected: 'blocked' },
  { name: 'candidate', url: 'https://qa.example.test/fixtures/permissions-policy/candidate.html', expected: 'allowed' },
];
for (const scenario of cases) {
  test(`Permissions Policy ${scenario.name}`, async ({ page }) => {
    let response;
    try {
      response = await page.goto(scenario.url, { waitUntil: 'domcontentloaded', timeout: 8000 });
    } catch (error) {
      throw new Error(`NETWORK_ERROR antes de la aserción: ${error.message}`);
    }
    expect(response?.ok(), `Respuesta HTTP de ${scenario.name}`).toBeTruthy();
    await page.getByRole('button', { name: 'Request location' }).click();
    await expect(page.getByTestId('policy-result')).toHaveText(new RegExp(`^${scenario.expected}$`), { timeout: 5000 });
  });
}

DNS, certificado, HTTP y rutas ausentes deben seguir siendo NETWORK_ERROR, nunca un blocked que pase. Un timeout solo indica que el fixture no produjo evidencia a tiempo. Cierra el context y elimina datos temporales. El fixture prueba únicamente el navegador y la ruta declarados.

La gestión de privacidad debe usar permisos sintéticos y datos temporales, sin coordenadas, medios, cookies ni contenido de cuentas. Asigna el primer fallo a su responsable: red y header a infraestructura, cadena de política al dueño del embed, rechazo del usuario al flujo de consentimiento y errores posteriores al equipo de aplicación. Conserva el header y markup anteriores para rollback y repite la misma ruta, permisos y aserción después del cambio para mantener la reproducibilidad.

Conclusión práctica

El contrato de embed debe nombrar origins, función, propósito, acción, alternativa y responsable. Repite el fixture tras cambiar host, redirect, navegador o frame anidado. Conserva solo valores de política, origins, versión, marcadores y resultados visibles.

BotBrowser puede repetir un recorrido autorizado con un browser context declarado. No puede cambiar Permissions-Policy, modificar origins, conceder permisos, proporcionar dispositivos, sobrescribir CSP/COOP/COEP, reparar respuestas de proveedores ni demostrar una operación remota. La respuesta entregada y los registros del servicio son la autoridad. Consulta la guía CSP y la guía de aislamiento cross-origin.

Fuentes

• W3C: Permissions Policy
• MDN: Permissions Policy
• MDN: iframe allow
• MDN: CSP
• MDN: COOP
• MDN: COEP
• BotBrowser: funciones avanzadas

Equipo BotBrowser