Resumen

  • El RFC 1945, publicado en mayo de 1996, permitió que el campo Referer comunicara al servidor de destino la URI de la página donde se obtuvo el enlace. Enumeró listas de vínculos entrantes, registros y reparación de enlaces, y advirtió en el mismo apartado de que la fuente podía ser privada.
  • El RFC 2068 de enero de 1997 conservó el campo, reconoció que «Referer» estaba mal escrito y explicó cómo podía revelar la URI de un documento privado. Una dirección tecleada carecía de página de origen; el fragmento de la URI se excluía del valor.
  • La Recomendación Candidata del W3C fechada el 26 de enero de 2017 describió políticas para enviar una URL entera, solamente el origen del sitio o ninguna referencia. El texto documenta una decisión de diseño de esa fecha, no la difusión efectiva de cada opción entre navegadores.

Un recibo para quien recibía el clic

El RFC 1945, especificación de HTTP/1.0 publicada en mayo de 1996, ofrecía al servidor una pista del recorrido del visitante. Cuando el navegador seguía un enlace, podía añadir a la petición el campo Referer con la URI de la página de partida. El destinatario podía entonces producir listas de páginas que lo enlazaban, registrar las visitas, optimizar la caché o rastrear direcciones antiguas o mal escritas. No eran funciones imaginarias: el estándar las nombraba una por una.

Supongamos que un archivo digital cambia de sitio un documento. Siguen llegando peticiones por enlaces viejos. Si cada una indica la página desde la que se pulsó, el archivo puede encontrar al dueño del vínculo equivocado y corregir la ruta. La persona que administra el destino obtiene una pequeña vista del mapa del Web sin tener acceso al servidor de origen. Referer era una lista de retornos fabricada con las propias visitas.

Desde el principio el campo tenía límites. El texto de 1996 decía que no debía enviarse si la dirección de destino no procedía de una fuente con URI, como cuando alguien la escribía en el teclado. Tampoco debía incluirse el fragmento de la dirección. Una URL tecleada y un clic desde un documento no cuentan la misma historia al servidor de llegada. El estándar no autorizaba a inventar una página anterior.

La advertencia sobre privacidad estaba junto al beneficio. La fuente de un enlace podía ser información privada o revelar la ubicación de otra fuente reservada. Los autores recomendaban con fuerza que la persona pudiera elegir si el navegador enviaba Referer; mencionaban incluso un interruptor entre navegar abiertamente y hacerlo de manera anónima. En 1996 ya estaban escritos los dos lados de la cuenta: arreglar enlaces era útil y mandar la dirección de salida podía costar demasiado.

El error ortográfico sobrevivió a la revisión

El RFC 2068, especificación de HTTP/1.1 publicada en enero de 1997, hizo explícita la errata. El nombre del campo era Referer, aunque la palabra correcta en inglés sería “referrer”. La secuencia que circulaba entre clientes y servidores no cambió. El campo seguía sirviendo para construir listas de vínculos inversos, registrar visitas y localizar enlaces defectuosos. También permanecieron las reglas sobre las direcciones tecleadas y los fragmentos.

La errata invita a la broma fácil, pero distrae del movimiento más importante. El servidor de llegada recibía información sobre una página que pertenecía a otro sitio. Le interesaba conocer el origen para mantener sus enlaces y estudiar su audiencia. Ese interés no le decía cuánto detalle de la página ajena necesitaba conocer. Una copia completa de la URL podía llevar un camino interno que no hacía falta para saber que la visita venía de cierta institución.

La parte del RFC 2068 dedicada a seguridad hizo más nítido el problema. El campo permitía estudiar patrones de lectura y trazar enlaces inversos. Aunque se quitaran nombres u otros datos personales explícitos, la URI podía señalar un documento privado. Una ruta de perfil, un expediente reservado o un parámetro de sesión pueden hacer identificable el contexto por sí solos. La filtración ocurre en el encabezado de la petición, no en el texto visible del vínculo.

Los RFC describen las reglas del mecanismo, no una medición de todos los navegadores de su época. Su registro basta para localizar la tensión original. El servidor destinatario quería saber de dónde provenía una visita; el sitio de partida y su lector podían querer ocultar la dirección precisa de salida. El mismo campo hacía ambas cosas.

El nombre del sitio y la página no son lo mismo

Una URL completa puede contener mucho más que un dominio. La ruta puede identificar un perfil o un espacio de trabajo. La cadena de consulta puede incluir un identificador de sesión. Cuando el navegador envía esa dirección como Referer, el servidor de destino aprende parte de la página que el lector acaba de dejar. El enlace visible podía ofrecer un libro, una noticia o una imagen; el encabezado añadido revelaba contexto del origen.

Esta información llega al operador que puede guardarla en sus registros. El autor de la página fuente conoce la estructura de sus propias direcciones y puede saber qué partes son sensibles. La persona que pulsa el enlace quiere llegar al destino. El interruptor del usuario sugerido en 1996 atendía el problema de forma general. Una política asociada a la página permitiría graduar la respuesta según el contenido que se deja atrás.

Las alternativas no son intercambiables. Enviar toda la URL ayuda a encontrar el vínculo exacto. Enviar solo el origen —esquema, servidor y puerto— informa de qué sitio procede la visita sin copiar la ruta individual. No enviar referencia elimina también esa atribución general. El valor para el registro del destino disminuye a medida que aumenta la reserva del origen.

La página de salida toma la decisión

La Recomendación Candidata «Referrer Policy» del W3C, fechada el 26 de enero de 2017, abrió con un ejemplo preciso. Una página de perfil en una red social enlaza al sitio de un grupo musical. El grupo puede recibir visitas y saber que proceden de la red sin obtener la URL del perfil que identifica a la persona. Otro ejemplo presenta una aplicación cuya dirección contiene un identificador de sesión o una URL que da acceso por sí misma. En esos casos, la dirección de origen se parece a una credencial.

La propuesta define políticas con resultados distintos. no-referrer suprime el campo. same-origin permite la URL completa dentro del mismo origen y ninguna hacia otro. origin transmite el nombre del origen sin ruta ni parámetros; strict-origin evita enviarlo cuando se sale de un contexto protegido hacia uno menos confiable. Otras opciones combinan tratamientos para destinos internos y externos. La pregunta dejó de ser un simple sí o no. Importaba qué fracción de la URL salía y hacia qué servidor.

La orden podía darse en un encabezado de respuesta Referrer-Policy, en un elemento meta, en atributos de ciertos elementos o mediante noreferrer en un enlace. El nombre de la política está bien escrito; el campo de petición gobernado por ella sigue llamándose Referer. El Web arregló la ortografía de la instrucción nueva mientras dejaba intacta la palabra antigua que los sistemas ya intercambiaban.

El documento de 2017 era una Recomendación Candidata en esa fecha. Explica cómo deberían comportarse las distintas políticas. Para establecer cuándo llegó cada una a los navegadores haría falta un registro fechado de implementaciones. La especificación sí muestra el cambio conceptual: la página que podía revelar su propio contexto obtenía una herramienta para decidir cuánta dirección acompañaba a las peticiones salientes.

La utilidad del vínculo inverso tiene precio

Conocer la procedencia de un clic ayuda al destinatario a reparar enlaces y entender cómo encuentran los lectores un documento. El RFC de 1996 tenía razones prácticas para ofrecerlo. Su advertencia sobre privacidad estaba igualmente bien situada. Si la URI de origen señala una página reservada, el recibo que simplifica la tarea del destinatario copia información del otro lado del enlace.

La política posterior llevó la decisión hacia el origen. Un sitio podía mostrar su dominio y retener la ruta de un perfil, o callar por completo. El receptor perdería parte del detalle de su lista de vínculos entrantes. Ese es el coste real de no difundir una dirección privada. El mantenimiento de un sitio no confiere a su dueño un derecho permanente a saber la página exacta que dejó cada visitante.

La falta de una letra en Referer se recuerda bien. La separación más trascendente fue otra: saber qué sitio envió una visita no exige siempre saber qué persona y qué página concreta la enviaron. El enlace de vuelta se convierte en una decisión sobre información cuando su dirección puede decir demasiado.

Fuentes