Кратко

  • RFC 1945, опубликованный в мае 1996 года, описал Referer как поле, с помощью которого клиент сообщал серверу URI страницы с исходной ссылкой. Перечислены обратные ссылки, журналы и исправление неверных адресов. В том же разделе предупреждалось о возможном раскрытии частного документа.
  • RFC 2068 января 1997 года сохранил механизм и прямо назвал Referer ошибочным написанием слова «referrer». У адреса, введённого с клавиатуры, нет страницы-источника; фрагмент URI в поле не включается. Раздел безопасности раскрывал риск передачи URI частного документа.
  • Датированная 26 января 2017 года кандидатская рекомендация W3C описала политики для полной URL, только происхождения сайта или отсутствия ссылки на источник. Это описание правил на ту дату, а не подсчёт браузеров, где они работали.

Зачем принимающему серверу был нужен обратный адрес

Спецификация HTTP/1.0 RFC 1945, опубликованная в мае 1996 года, дала принимающему серверу полезную подсказку. Следуя ссылке, браузер мог включить в запрос поле Referer с URI страницы, где находился адрес назначения. Сервер мог составлять списки ведущих к нему страниц, вести журналы, оптимизировать кэширование и находить устаревшие или неправильно набранные ссылки. Документ перечислял именно такие задачи.

Представим библиотеку, перенёсшую документ. На чужих сайтах остались ссылки на старую страницу. Запрос с адресом страницы-источника показывает библиотеке, где нужно поправить указатель. Ей не требуется владеть чужим сайтом, чтобы увидеть небольшую часть карты входящих ссылок. В сети независимых издателей такой обратный адрес был практическим инструментом обслуживания.

Но у поля были границы. Если человек набрал адрес вручную, источника с собственной URI нет; RFC запрещал посылать Referer в таком случае. Фрагмент URI также исключался. Приход по ссылке и приход из адресной строки нельзя было выдавать за один и тот же путь. Серверу не следовало выдумывать предыдущий документ там, где его не было.

В том же разделе находилась цена удобства. Источник ссылки мог быть частным, а его адрес — раскрывать местонахождение иной закрытой информации. Авторы настоятельно рекомендовали дать пользователю выбор, отправлять ли поле, и приводили образ переключателя между открытым и анонимным просмотром. Риск был частью исходного описания в 1996 году, а не поздним возражением против полезного инструмента.

Опечатка пережила новую версию

Спецификация HTTP/1.1 RFC 2068 января 1997 года признала забавную вещь: Referer написано неправильно, по-английски должно быть «referrer». Имя поля, которое уже передавалось между клиентами и серверами, осталось. Сохранились обратные ссылки, журналы и поиск плохих адресов. Сохранилось правило не посылать источник для вручную введённой URL и исключать фрагмент.

Опечатка стала памятником раннему вебу, но важнее направление передачи. Запрос к новому серверу несёт адрес страницы, принадлежащей иногда другой организации. Серверу назначения удобно знать, откуда пришёл посетитель. Для исправления ссылки ему не обязательно знать путь к индивидуальному профилю человека или внутреннему рабочему документу. Название сайта и точное название комнаты внутри него — разные объёмы информации.

Раздел RFC 2068 о безопасности говорил прямо: Referer позволяет изучать модели чтения и строить обратные ссылки. Даже если отделить явные персональные сведения, URI может указывать на частный документ. Путь профиля, название закрытого дела или параметр сессии иногда рассказывают достаточно сами по себе. Утечка происходит в заголовке запроса, независимо от того, написано ли что-либо чувствительное в видимом тексте ссылки.

Эти RFC задают правила поля, а не статистику поведения каждого браузера того времени. Для понимания столкновения интересов этого достаточно. Сервер назначения хотел точную подсказку для ремонта сети ссылок; источник и читатель могли предпочесть не оставлять у него адрес закрытой страницы.

Имя сайта или номер комнаты

Полная URL содержит больше, чем домен. Путь может называть профиль, внутреннее пространство или документ. Параметры запроса могут содержать идентификатор сессии. Если браузер передаёт всё это в Referer, другой сервер узнаёт не только название сайта, но и конкретную страницу, которую покинул человек. Читатель нажал ссылку ради нового материала; прежний контекст уехал вместе с метаданными.

Получатель может сохранить поле в журнале. Источник лучше знает значение собственных путей и параметров. Он может определить, какой адрес раскрывает личность, а какой всего лишь обозначает публичную рубрику. Предложенный в 1996 году пользовательский переключатель решал проблему целиком для браузера. Политика отдельной страницы могла бы дать ответ, соответствующий именно этой странице.

Три уровня различаются экономически и технически. Полная URL помогает найти конкретную неверную ссылку. Только происхождение — схема, узел и порт — называет отправивший сайт, не раскрывая путь и строку запроса. Отсутствие поля скрывает даже этот сайт. Чем подробней бухгалтерия входящих ссылок у получателя, тем больше адресных деталей источника она забирает.

Правило задаётся перед отправкой

Кандидатская рекомендация W3C «Referrer Policy» от 26 января 2017 года начинает с ясного примера. Страница профиля в социальной сети ведёт на сайт музыкальной группы. Группа может узнать, что посетитель пришёл из социальной сети, не получив полный адрес профиля, способный назвать его владельца. Документ также приводит приложение с идентификатором сессии в URL и адрес, который сам даёт право доступа. В таком случае адрес почти превращается в ключ.

Текст описывает разные режимы. no-referrer убирает поле. same-origin посылает полную URL в пределах одного происхождения и не посылает её другому. origin передаёт схему, узел и порт без пути и параметров; strict-origin ограничивает передачу при переходе из защищённого контекста к менее надёжному адресу. Другие варианты комбинируют правила для внутренних и внешних запросов. Решение стало вопросом о том, какую часть адреса показать и кому.

Автор страницы мог задать выбор через заголовок ответа Referrer-Policy, элемент meta, атрибут некоторых элементов или отношение ссылки noreferrer. Новое название политики написано правильно; старое поле запроса осталось Referer. Исправили английское слово в новой инструкции, но не переписали имя уже работающего сообщения.

Документ W3C имел статус кандидатской рекомендации в 2017 году. Он определяет поведение политик, но не фиксирует дату их появления в каждом браузере. Для такого календаря нужен датированный журнал реализаций. Сам текст показывает перемену в устройстве контроля: страница, которая понимает смысл своего адреса, получила способ определить, сколько из него браузер может сообщить другим.

Обратная ссылка обходится информацией

Принимающий сервер действительно выигрывает от знания источника: исправляет ссылки, понимает, где читатели находят его документы, замечает старые адреса. RFC 1996 года точно называл эту пользу и сразу предупреждал о частной URI. Когда исходная страница закрыта, сервисная квитанция одновременно становится её адресом в чужом журнале.

Поздняя политика позволяет источнику назвать свой сайт, оставив путь профиля при себе, либо ничего не сообщать. Журнал получателя станет менее подробным. Именно столько стоит сокращение раскрытия. Обслуживание собственных страниц не даёт оператору общего права видеть точную комнату, которую только что покинул каждый пришедший посетитель.

Ошибочное написание Referer легко помнить. Главная перемена отделила два вопроса: какой сайт прислал визит и с какой именно страницы этого сайта вышел читатель. Один полезный обратный адрес больше не обязан отвечать на оба.

Источники