Summary

  • El borrador Feature Policy publicado por el W3C en 2019 permitió a una página fijar límites para funciones como pantalla completa, geolocalización, cámara y micrófono.
  • El borrador Permissions Policy de septiembre de 2026 describe dos lugares para expresar esos límites: la cabecera HTTP de la página y el atributo allow de un iframe; el navegador combina ambos por herencia.

Una web invita a una empresa de mapas, un reproductor de vídeo y un formulario ajeno. A simple vista parecen muebles en una sola sala. El navegador los trata como habitaciones separadas. El mapa quiere ubicación; el reproductor, pantalla completa; el servicio de reuniones, cámara y micrófono. Ser invitado a la casa no equivale a recibir el manojo entero de llaves.

El primer borrador público Feature Policy, de abril de 2019, puso por escrito el reglamento de la casa. Una cabecera HTTP podía impedir una función para el documento y sus descendientes o limitarla a determinados orígenes. Sus ejemplos cerraban pantalla completa y geolocalización, y reservaban cámara y micrófono para un origen incrustado concreto. La norma del anfitrión viajaba con la respuesta que entregaba la página.

El borrador de septiembre de 2026 se llama Permissions Policy y reconoce que antes se llamó Feature Policy. La cabecera actual, Permissions-Policy, usa un diccionario estructurado. El ejemplo fullscreen=(), geolocation=() establece listas vacías: esas funciones quedan cerradas para el documento y las páginas que cuelgan de él. El encargado del local ha cerrado las puertas generales antes de repartir pases a los camerinos.

Ahora pensemos en una excepción deliberada. El anfitrión quiere que un mapa dentro de un iframe tenga la posibilidad de usar geolocalización. Escribe allow="geolocation" en ese marco. La cabecera general puede delimitar los orígenes admisibles, y el atributo selecciona el marco concreto. El ejemplo del W3C de 2026 muestra las dos piezas juntas: un origen incluido en la lista de la página y una invitación específica en el marco. Una habitación vecina no hereda la llave por contagio.

La herencia ordena el recorrido. Cada función tiene una lista permitida por defecto. El documento padre recibe una política declarada mediante la cabecera. El marco aporta una política de contenedor mediante allow. Al crear o navegar el documento hijo, el navegador calcula su estado inicial con esas reglas. Un hijo puede fijar sus propias condiciones dentro del espacio que heredó. No puede abrir una puerta que el padre ya cerró con candado.

Por eso incrustar un servicio era una decisión más profunda que dibujar un rectángulo. El contenido ajeno puede solicitar funciones capaces de cambiar lo que ve u oye una persona. El anfitrión necesita diferenciar entre alojar un reproductor y autorizarle todas las funciones disponibles en la página. La política convierte esa diferencia en una regla que el navegador entiende y aplica por marco.

El texto de 2026 también permite consultar la política efectiva desde un documento o un elemento iframe. Una aplicación puede saber si cuenta con geolocalización y mostrar un campo de dirección cuando no la tiene. Esa consulta mira la puerta de la política. El permiso que el visitante conceda después y la presencia real de un dispositivo son decisiones posteriores del mismo viaje.

El historial oficial del W3C llega hasta el borrador de septiembre de 2026. Durante esa evolución, las páginas incorporaron cada vez más piezas externas y los navegadores ofrecieron funciones cada vez más sensibles. El reglamento tuvo que aprender a decir dos cosas a la vez: qué permite el edificio y a qué habitación se entrega la llave.