Общедоступные URL, упомянутые в базе данных часовых поясов IANA: перепись сломанных ссылок

База данных часовых поясов IANA описывает, как меняются местное время в разных уголках мира. Менее очевидно, но в блоках комментариев к этой базе также указано, откуда взяты эти правила. Исходный код хранится по адресу https://github.com/eggert/tz.

В ходе исследования этих ссылок был поставлен практический вопрос: из всех общедоступных URL, указанных в комментариях, сколько из них до сих пор функционируют? Каждый такой URL был собран, проверен, а при необходимости восстановлен — сначала с помощью прокси, позволяющего обойти распространённые блокировки ботов, а затем с использованием API Wayback, если живой хост больше не существовал. Код, таблицы результатов исследования и процесс восстановления данных для 1,327 URL опубликованы по адресу https://github.com/sixthextinction/tzdata-citation-census.

Этот «кроличий нор» был открыт в 2008 году волонтером Патрисом Скаттолином. Он пытался восстановить точную дату введения изменений по летнему времени в Марокко в 2008 году (фон: https://en.wikipedia.org/wiki/Daylight_saving_time_in_Morocco), читая современный отчет на сайте https://www.avmaroc.com/actualite/heure-dete-comment-a127896.html и сталкиваясь с неоднозначностью перевода с французского на английский. Запись, которую он оставил, типична для данного сборника: в ней упоминается указ № 2–08–224, и признается, что официальный текст в то время не мог быть найден в интернете.

Исторические базы данных полны подобных записей — номера указов, газетные публикации, URL-адреса статей, даты и объяснения того, почему один источник оказался более достоверным, чем другой. Более важный вопрос заключается в том, сколько из этих публичных URL-адресов по-прежнему функционируют спустя годы.

Что же на самом деле такое tzdata?

База данных часовых поясов IANA — это набор текстовых файлов, поддерживаемый волонтерами. Операционные системы и среды выполнения программ обращаются к ней, когда им нужно время по местному времени в определенном часовом поясе. Конечные пользователи редко открывают эти файлы, однако почти каждая дистрибуция Linux и среда программирования включают их в свои пакеты. Каждый раз, когда та или иная юрисдикция меняет время, база данных должна получить обновление, иначе все зависящие от нее приложения будут показывать неверное местное время.

Волонтеры могут следовать руководству по внесению исправлений, размещенному по адресу https://data.iana.org/time-zones/tz-how-to.html, при предложении изменений.

Сами правила могут быть краткими. Изменение времени из-за летнего времени в Марокко в 2008 году представлено двумя строками простого текста в файле africa:

# Rule NAME FROM TO - IN ON AT SAVE LETTER/S
Rule Morocco 2008 only - Jun 1 0:00 1:00 -
Rule Morocco 2008 only - Sep 1 0:00 0 -

Эти строки определяют моменты смены времени 1 июня и 1 сентября, которые должны соблюдаться устройствами по всему миру.

В примечаниях, расположенных рядом, хранится история создания. Содержатели документируют доказательства: номера указов, государственные ведомости, официальные заявления министерств, статьи из газет или информацию от того, кто предоставил сведения, обычно указывая дату добавления записи.

Иногда источники противоречат друг другу. Содержатели иногда фиксируют эти противоречия и указывают, какой стороне они доверяют. В 2006 году Пол Эггерт отказался от дат из атласа в пользу Национального бюро метрологии Австрии (https://www.bev.gv.at/):

# From Paul Eggert (2006-03-22): Shanks & Pottenger give 1918-06-16 and
# 1945-11-18, but the Austrian Federal Office of Metrology and
# Surveying (BEV) gives 1918-09-16 and for Vienna gives the "alleged"
# date of 1945-04-12 with no time. For the 1980-04-06 transition
# Shanks & Pottenger give 02:00, the BEV 00:00. Go with the BEV,
# and guess 02:00 for 1945-04-12.

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

Что происходит, когда вы действительно проверяете указанные цитаты?

Каждый URL был извлечен из блоков комментариев в девяти исходных файлах tzdata. В ходе этого обзора было найдено шестнадцатьсот девять блоков комментариев, содержащих триста пятьдесят два упоминания URL; в итоге выделилось триста двадцать семь уникальных адресов, принадлежащих шестистам двадцати трем хостам. Блоки, в которых упоминались только книги, постановления или письма без URL, не входили в обзор.

Каждый адрес проверялся с помощью обычного HTTP-запроса типа GET, стандартного заголовка Identity браузера (как описано в документации MDN User-Agent) и жесткого таймаута, чтобы хосты, застрявшие в работе, не могли замедлить процесс сбора данных.

В результате первоначального обзора были получены данные для 663 URL. Остальные 664 URL не сработали по разным причинам, поэтому они были тщательно классифицированы: код 404 не является эквивалентом действующей страницы, отклоняющей автоматизированные запросы.

Среди неудачных случаев:

• 433 ресурса невозможно было получить напрямую, но это удалось сделать через прокси. 178 ресурсов отклонили прямой запрос (в основном с кодом ошибки HTTP 403, некоторые — 429). Ещё 255 ресурсов не открылись из-за проблем с домашней сетью, DNS, истечения времени или ошибок TLS, а не из-за прямого блокирования ботов. Обе группы ресурсов были попробованы снова с использованием инструмента Bright Data’s Web Unlocker, и они были восстановлены.
• 123 ресурса действительно исчезли. Они возвращали коды ошибки HTTP 404 или 410. После проверки в архиве Internet Archive’s Wayback Machine у всех, кроме двух, была найдена полная архивированная копия — 121 ресурс был восстановлен.
• 108 ресурсов остались нерешёнными (57 ресурсов не были найдены в архиве, 39 продолжали отказываться открываться с помощью инструмента Web Unlocker, а 12 возвращали код ошибки HTTP 500). У 18 ресурсов из этой группы, все из которых находились на портале dof.gob.mx в Мексике, были обнаружены проблемы с сертификатами — скорее всего, это была ошибка конфигурации хоста, а не удалённая страница, но эти ресурсы находились вне рамок действия переписи.

Исчезнувший сайт — это неудача в его сохранении. Сайт, работающий в реальном времени и отклоняющий автоматизированные запросы типа GET, — это проблема с доступом. Оба случая мешают простому скроллингу; они говорят о разном том, существуют ли ещё доказательства.

Одних только цифр недостаточно для понимания ситуации. К 663 случаям прямого успешного доступа относятся государственные порталы, архивы газет и личные страницы, которые до сих пор отвечают на запросы. 433 случая восстановления через прокси показывают, насколько часто так называемые «сломанные» ссылки на самом деле являются следствием политик против автоматизации. 121 случай использования функции Wayback показывает, насколько часто Интернет-архив уже содержал пригодный к использованию снимок страницы — за исключением двух случаев 404/410, когда даже в архиве ничего не было. Именно разделение этих категорий позволяет интерпретировать данные так, чтобы их можно было использовать при повторных измерениях.

Почему ссылка вообще может быть заблокирована?

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

Это затрудняет массовую проверку старых цитат. URL-адрес, который работал, когда его вставил администратор, может по-прежнему быть активным, но отклонять простой автоматизированный запрос спустя годы.

В корпусе данных часто встречаются официальные ведомости и юридические базы данных — dre.pt из Португалии, resmigazete.gov.tr из Турции, юридический новостной портал nevo.co.il из Израиля и подобные ресурсы. Администраторы активно использовали их, но некоторые из этих страниц по-прежнему невозможно получить напрямую.

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

Действительно ли это проблема с tzdata?

Не в первую очередь. Эксперимент измеряет, насколько хорошо сохранились внешние источники, зарегистрированные в долговечном историческом наборе данных.

tzdata не может сохранять материалы, на которые она ссылается. Правила хранятся в системе контроля версий и распространяются по всему миру внутри операционных систем, но ссылаемые страницы остаются на независимых веб-сайтах, государственных порталах и архивах газет.

Проблемы с доступом — это не новость. Уже в записке об изменении времени в Египте в 2014 году указывалось, что страница с объявлением кабинета министров (http://www.cabinet.gov.eg/Media/CabinetMeetingsDetails.aspx?id=347) не может быть загружена из-за пределов страны. Проблемы с геофенсингом существовали ещё задолго до этой переписи.

Как на самом деле выглядел процесс восстановления?

Процесс восстановления выполнялся в несколько этапов, чтобы способы сбоев оставались разными.

Попытки применить каждый метод к каждому URL — напрямую, через прокси, затем из архива — приведут к завышению количества «восстановленных» страниц при одновременном размытии категорий. Статус 404 отличается от временной блокировки. Снимок из архива также не совпадает с той страницей, которую читал администратор; это копия с какого-то более позднего или раннего момента.

Один из этапов предусматривал использование только прямых запросов с точным записыванием статуса HTTP. URL-адреса, возвращавшие коды 404 или 410, направлялись на отдельный этап с ограничением частоты запросов к API доступности Internet Archive. URL-адреса, у которых истек срок или произошла блокировка, на этом этапе не отправлялись в архив.

Концептуально:

async function checkCitation(url) {
  const direct = await get(url); // one plain GET, no tricks
  if (isOk(direct)) return { status: "live", via: "direct" };

  if (direct.status === 404 || direct.status === 410) {
    const archived = await wayback(url); // only for confirmed-dead
    if (archived.hit) return { status: "recovered", via: "wayback" };
  }

  return { status: "unresolved" };
}

Этап прокси-загрузки представлял собой следующую стадию обработки. Он направлен на URL-адреса, которые невозможно было получить при прямой загрузке из-за блокировок или проблем с доступностью, а не на те URL-адреса, которые уже выдавали коды 404 или 410. Блокированные URL-адреса пытались загрузить снова в качестве обычных запросов GET с помощью инструмента Bright Data’s Web Unlocker, действующего как нативный прокси HTTPS:

import { ProxyAgent, fetch as proxyFetch } from "undici";

const AUTH = process.env.BRIGHT_DATA_UNLOCKER_AUTH; // format like USER:PASS

const dispatcher = new ProxyAgent({
  uri: `@brd.superproxy.io:44445`">http://${AUTH}@brd.superproxy.io:44445`,
  requestTls: { rejectUnauthorized: false },
  proxyTls: { rejectUnauthorized: false },
});

const res = await proxyFetch(url, {
  dispatcher,
  headers: { "User-Agent": UA, Accept: "*/*" },
  redirect: "follow",
});

Этот путь не является результатом отображения в браузере — это просто HTTP-запрос, направленный через Web Unlocker. Учетные данные должны находиться в файле .env:

BRIGHT_DATA_UNLOCKER_AUTH=brd-customer-XXXXX-zone-web_unlocker:PASSWORD
BRIGHT_DATA_UNLOCKER_PROXY_HOST=brd.superproxy.io
BRIGHT_DATA_UNLOCKER_PROXY_PORT=44445

Разделение этапов позволяет в итоговой таблице отличать прямые запросы, восстановление данных через прокси, восстановление из архива и нерешенные ссылки.

С методологической точки зрения наличие инструмента разблокировки важно, поскольку оно позволяет отличить случаи, когда «страница всё ещё существует за препятствием», от случаев, когда «страница исчезла». Без такого различия наивный скрейпер будет завышать показатели повреждённых ссылок. Аналогичным образом, отправка только ответов 404/410 в Wayback помогает избежать перегрузки API архива хостами, которые лишь блокировали ботов, что исказило бы статистику восстановления и привело к исчерпанию лимитов на запросы низкой ценности.

Что можно сделать с источниками после их получения?

Здесь ключевым вопросом является доступность: можно ли всё ещё получить указанный URL, и если нет, можно ли восстановить документ в другом месте?

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

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

Что же на самом деле остается, если архив этого не содержит?

Сто восемь URL-адресов цитат остались нерешёнными — примерно 8 процентов от 1 327 уникальных URL-адресов; это небольшой процент, но в сумме это целая куча неустранимых проблем с происхождением данных. Хотя доля невелика, каждый URL когда-то поддерживал конкретное правило часового пояса.

Эти правила всё ещё сохраняются в tzdata. Однако отсутствуют некоторые или все внешние страницы по этим адресам.

Из 108 случаев у 57 были возвращены ошибки 404 или 410 без записей о доступности через Wayback. У тридцати девяти случаев по-прежнему возникали проблемы через прокси (восемнадцать из них связаны с ошибками сертификатов Мексики). У двенадцати случаев возникали другие HTTP-ошибки, которые не подлежали повторной попытке обработки и не отправлялись в Wayback.

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

Ограничения использования цитат в качестве средства сохранения

Исторические наборы данных и страницы, на которые они ссылаются, обладают асимметричными свойствами сохранения.

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

У цитируемых материалов нет такой гарантии. Они могут находиться по одному URL у одной организации. Если эта организация переезжает, удаляет контент, меняет условия доступа или прекращает предоставление сервиса, цитата становится трудно или невозможно восстановить. Такой сценарий часто называют «порчей ссылок».

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

Таким образом, этот анализ скорее демонстрирует, насколько можно доверять внешним URL в качестве исторических источников, чем является критикой tzdata. Большинство ссылок можно было восстановить в той или иной форме. Однако небольшой, но значимый процент ссылок не удалось восстановить. В базе данных по-прежнему хранятся правила, установленные этими источниками; в 108 случаях URL уже невозможно восстановить.

Повторение этого анализа год спустя, вероятно, приведет к смещению некоторых URL между категориями из-за изменений на сайтах в части протокола TLS, правил CDN или политик роботов. Важным показателем является не фиксированный процент, а скорость, с которой ссылки переходят из категории «прямое использование возможно» в категорию «требуется прокси» или «только архив», а также количество ссылок, оставшихся нерешенными и не поддающихся автоматической обработке.

Для тех, кто работает с другими долговечными наборами данных — данными локалей CLDR, выгрузками геонимов, инструментами для сбора законодательной информации — применяется тот же алгоритм оценки. Составьте список всех публичных URL в комментариях или полях происхождения, классифицируйте сбои по семантике HTTP, восстанавливайте данные с помощью инструмента разблокировки только в том случае, если сбой связан с политикой доступа, и обращайтесь к архиву только тогда, когда источник указывает на исчезновение ресурса. Опубликуйте статистику по контейнерам рядом с исходным списком URL, чтобы последующие читатели могли повторить ту же процедуру, вместо того чтобы полагаться на один-единственный процентный показатель.