datasette-referrer-policy 0.1: un plugin para un problema real

El 5 de mayo, Simon Willison publicó en su weblog una entrada breve pero ilustrativa: la demo pública de Datasette con datos de centrales eléctricas globales (global-power-plants) dejó de mostrar los tiles de OpenStreetMap correctamente. Lo que parecía un problema menor terminó siendo dos bugs distintos que, juntos, inutilizaban el mapa.

Este tipo de incidencias es más común de lo que parece: una decisión de privacidad razonable choca con una política legítima de un servicio externo, y el resultado es funcionalidad rota sin mensaje de error claro para el usuario.

Qué ocurrió exactamente

El primer problema era un CAPTCHA. Willison había integrado hace pocas semanas datasette-turnstile en el sitio. El CAPTCHA se activaba también para las peticiones `.json` que el plugin de mapas lanza en segundo plano para obtener los datos geoespaciales. Como esas peticiones no son HTML, el usuario nunca veía el reto y, por tanto, nunca podía resolverlo. Las peticiones quedaban bloqueadas en silencio. El fix consistió en excluir esas rutas de la lógica del CAPTCHA.

El segundo problema era estructural: Datasette envía por defecto la cabecera `Referrer-Policy: no-referrer` en todas sus respuestas HTTP. Es una decisión de privacidad coherente —evita filtrar la URL de origen en peticiones a terceros—, pero OpenStreetMap bloquea explícitamente las peticiones de tiles que llegan sin cabecera `Referer`. Su razonamiento también es legítimo: necesitan saber de qué dominio provienen las peticiones para aplicar sus condiciones de uso y detectar abusos.

La solución: un plugin específico

En lugar de cambiar el comportamiento global de Datasette —lo que habría afectado a cualquier instalación que actualice el framework—, Willison optó por crear datasette-referrer-policy 0.1, un plugin que permite configurar la política de referrer a nivel de instancia sin tocar el núcleo.

El enfoque tiene sentido desde el punto de vista de diseño de software: el comportamiento por defecto de Datasette sigue siendo el más privado posible, y quien necesite una política diferente —por ejemplo, para servir mapas con tiles de OpenStreetMap— puede instalar el plugin y ajustar la cabecera según sus necesidades (`strict-origin-when-cross-origin` sería la opción habitual en este caso).

Por qué importa más allá de Datasette

Este incidente es un buen recordatorio de algo que los equipos que despliegan herramientas con integraciones externas suelen subestimar: las cabeceras HTTP de seguridad y privacidad tienen efectos colaterales en servicios de terceros que dependen de esa información para funcionar correctamente.

No es un problema exclusivo de Datasette. Cualquier aplicación que use `Content-Security-Policy`, `Referrer-Policy` o `Permissions-Policy` de forma agresiva puede encontrar fricciones similares con APIs de mapas, widgets de pago, servicios de analítica o reproductores multimedia embebidos. La diferencia está en si el framework ofrece una vía de escape granular —como hace ahora Datasette con este plugin— o si obliga a bajar la guardia globalmente.

Para equipos que usan Datasette como capa de visualización de datos abiertos, este plugin es una pieza pequeña pero práctica. Para el resto, la historia sirve como checklist mental: antes de integrar tiles de OpenStreetMap (u otros servicios similares), vale la pena revisar qué cabeceras está enviando la aplicación y si alguna de ellas va a entrar en conflicto con los requisitos del proveedor.

---

En EP hemos visto situaciones parecidas en integraciones con MCP servers que llaman APIs externas con políticas de CORS o autenticación por origen. La solución de Willison —un plugin opt-in en lugar de cambiar el defecto— es exactamente el tipo de decisión de diseño que evita sorpresas desagradables a quien no necesita la funcionalidad.