dxdt.blog: занимательный интернет-журнал

На сайте Ватиканской апостольской библиотеки опубликовано большое количество старых манускриптов, в неплохо оцифрованном виде. Например, текст “Начал” Евклида, датируемый девятым веком. Конечно, девятый век нашей эры, но, как считается, это самый старый из известных подробный текст, в который не было внесено позднейших (относительно Евклида) изменений и дополнений. Посмотрим на фрагмент (обычно цитируют страницу с теоремой Пифагора, поэтому выберем другую – книга первая, Предложение 29 ):

Интересно, что даже если вы вдруг знаете древнегреческий (какой-нибудь подходящий диалект), то уже просто читать эти манускрипты не так-то легко, если, конечно, вы не занимались библиотечным делом веков двенадцать назад. Посмотрите на способ записи – он существенно отличается от знакомого по современным книгам “печатного” древнегреческого. Многим вообще покажется, что это не греческий текст, поскольку тут весьма сложно разглядеть буквы, знакомые, хотя бы, из школьной программы по математике. Вот фрагмент покрупнее:

То есть, для того, чтобы начать читать первоисточники, потребуется совершить экскурс в палеографию. Так, данный манускрипт не только использует алфавит, начертания букв которого не очень-то похожи на αβγ, но и насыщен специальными лигатурами и сокращениями, которые использовали при записи древнегреческого в соответствующий период (в данном случае – 9-10 вв., как я понимаю; Евклид был древним уже тогда).

Посмотрим, как выглядит “перевод” на более “привычный” древнегреческий. Я попробовал приписать соответствующий текст в режиме, близком к “буква под буквой”, насколько позволяют особенности исходника – потому что, например, ει схлопнуто в одну лигатуру. (В Предложении 29 речь про накрест лежащие углы, образуемые прямой, падающей на параллельные прямые, поэтому, как минимум, одно слово нетрудно узнать.)

Здесь на поле указан номер предложения: ΚΘ, под чертой, что имеет числовое значение 29.

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

Слово γωνίας (“углы”) здесь разделено между строками, пришлось дорисовать чёрточку. Обратите внимание, что не только λ выглядит необычно (про π уже можно не напоминать), но и ν слишком похожа на μ (спасает только хвостик справа, который, кстати, длинен не во всех случаях).

Для записи древнегреческого использовались самые разные начертания букв – это лишь один небольшой пример. Говорят, что если построить достаточно мощную “систему с машинным обучением” и загрузить в неё некоторые старые манускрипты, написанные на древнегреческом, – а не на латыни, как можно подумать, – то эффект окажется достойным самых смелых эсхатологических предсказаний. Скорее всего, это выдумки.

Ещё один короткий комментарий на тему форм английских слов и скрытого расслоения смыслов, полностью исчезающего при переходах между языками. В английском языке у слова antenna (антенна; в британском – aerial) две формы множественного числа: antennae и antennas. Форма antennae – кажется естественной, а вот antennas – для “литературного взгляда” смотрится несколько странно, но, тем не менее, тоже верная форма. Почему? Дело в том, что если речь идёт об антеннах для приёма радиосигнала, то использование формы antennas – сразу выдаёт в вас разбирающегося в вопросе человека, потому что antennae – это, с точки зрения радиоинженера, да и продвинутого филолога, усы на голове насекомого (но, впрочем, эту форму допустимо использовать и в электромагнитном контексте, вряд ли кто-то осудит строго).

Один из оксфордских словарей (Oxford Advanced Learner’s Dictionary) относит слово miaow к уровню C1 (это высокий уровень владения языком). Казалось бы, здесь miaow – это “мяу!”, а именно – подражание разговору котов. Почему же C1? Потому, что только на высоком уровне освоения языка обязательно узнавать подобные слова. Естественно, слово cat, в значении “кошка”, тот же словарь относит к начальному уровню A1. Но попробуйте показать начинающему изучать английский (как иностранный) слово miaow – скорее всего, с пониманием возникнут трудности; а вот на уровне C1 – трудностей возникать не должно.

Занятно, что moo (мычание коров) тот же словарь относит уже к уровню C2 (это максимально возможный, по данной шкале, уровень владения языком). Дети изучают, что “коровка говорит: му-у!”, в том числе, дети, для которых английский является родным и первым языком – moo. Это так. Но для тех, кто осваивает иностранный английский, конечно, moo может показаться незнакомым загадочным словом, поскольку для них и коровка могла говорить что-то другое, и сопоставить иностранное слово, записанное незнакомыми буквами, со знакомым звукоподражанием, в общем случае, не так-то просто. Кроме того, сортировка по шкале внутри одного языка должна происходить более или менее одинаковым способом для всех животных звукоподражаний, но с учётом того, что с коровой многие городские жители сталкиваются реже.

Теперь, что касается mew. Это слово здесь тоже означает “мяу”, но без восклицательного знака (даже, скорее, “миу”). Mew – как минимум, в британском английском, – тише и мягче, чем miaow (meow), поэтому может использоваться иначе.

На dxdt.ru много лет работает сервис, который позволяет отрисовывать предложения LaTeX, переданные в параметрах URL, в картинки GIF, тут же возвращаемые сервером – то есть, можно указать в коде страницы тег img и результат запроса картинки по URL из src отобразит формулу. Раньше это было очень актуально в вебе, сейчас – менее актуально: появились другие технологии для отображения формул на веб-страницах. Тем не менее, сервис продолжает использоваться, потому что на многих внешних сайтах и форумах указаны URL картинок. Я даже оставил для URL сервиса рисования LaTeX возможность использовать HTTP – без S. Это связано с тем, что старые ссылки, естественно, повсеместно используют http://, а HTTP-перенаправление, в теории, может помешать отображению картинки. Но, наверное, всё же придётся добавить перенаправление с заменой протокола на HTTPS и для этих URL. В принципе, современные браузеры могли бы автоматически пробовать подключиться по HTTPS, тем более, что в DNS присутствует соответствующая запись. Но есть сомнения насчёт вспомогательных сервисов, которые могут извлекать картинку по HTTP и потом куда-то её копировать локально – не факт, что они умеют в HTTPS.

Интересно, что иногда ссылку указывали даже с префиксом www., хотя, насколько я помню, он никогда не был основным адресом для сайта; видимо, вводили автоматически. Но с www. – несколько проще, там изначально перенаправление на dxdt.ru, как и сейчас, поэтому, если раньше работало, то должно сохраниться. Собственно, с префикса www. сейчас веб-сервер перенаправляет именно на https://.

Ещё о пресертификатах в Certificate Transparency (CT) и странных “свойствах”, которые возникают вокруг. TLS-сертификаты превращаются в пресертификаты после того, как добавлено специальное расширение Poison. Может показаться, что с этим расширением тоже связана проблема “курицы и яйца”, поскольку нарушать процесс валидации poison-расширение должно потому, что оно помечено как Critical (критическое), но имеет тип, неизвестный валидатору – неизвестные критические типы, согласно рекомендациям, должны приводить к тому, что сертификат считается невалидным (а вот расширения неизвестного типа, которые не помечены как критические, можно игнорировать). Если же валидатор знает тип poison-расширения, то флаг Critical уже не должен препятствовать валидации. Это так, однако проблемы тут нет: в том случае, когда валидатор распознал poison-расширение, он не должен принимать сертификат на правах валидного, так как, грубо говоря, видит, что это пресертификат (ну или можно интерпретировать иначе: наличие poison-расширения означает, что сертификат не должен использоваться так же, как и сертификат без Poison). В общем, всё же появляется неплохой шанс выстроить однозначный процесс валидации.

С пресертификатами связано множество весьма неочевидных аспектов. Так, единственный смысл в пресертификатах – это создание “костыля” для получения метки времени от сервиса CT-лога, чтобы включить эту метку в сертификат. Метка (она называется SCT) связана с конкретным пресертификатом и подписывается лог-сервисом. Но включается метка уже в сертификат, который от пресертификата отличается в некоторых деталях. Напрмер, сертификат не должен содержать poison-расширение. При валидации сертификата проверяется и SCT-метка (ну, если валидирующая сторона, – скажем, браузер, – хочет проверить метку). Понятно, что если подпись вычислена для другого набора данных (пресертификат), то она не сойдётся. Как же устроены процессы подписывания и проверки подписи SCT-метки? Они устроены непросто.

При вычислении подписи для пресертификата сервис CT-лога использует в качестве входных данных не весь сертификат, а только его “содержательную часть” (некоторое зафиксированное в структуре подмножество полей), из которой, к тому же, удаляется poison-расширение. Это, что называется, первый “сюрприз”: poison-расширение должно присутствовать в составе поступающего пресертификата не только потому, что оно и делает сертификат пресертификатом, но и потому, что иначе не сойдётся подпись УЦ на пресертификате, а подпись должен проверить сервис лога. Дописать какие-то данные в сертификат не выйдет. Однако поскольку в сертификате Poison удаляется, то и подпись в SCT нужна на данных без poison-расширения. Второй “сюрприз”: при проверке подписи SCT в сертификате – нужно восстановить содержательную часть пресертификата в точно таком виде, какой передавался в сервис CT-лога, но с учётом удаления Poison – то есть, нужно удалить “лишние” расширения (SCT-метки), а те расширения, которые останутся, должны совпасть с конфигурацией пресертифката. А поскольку такое преобразование снова удаляет из состава сертификата значение подписи, к данным сертификата, перед проверкой, вместе с другими служебными параметрами SCT, нужно присоединить отпечаток открытого ключа УЦ. Понятно, что то же самое делается и на стороне CT-лога, при формировании SCT. Так что общий алгоритм местами “макаронный”, но, тем не менее, используется. Не удивительно, что в новой версии CT пресертификатов нет.

Ракета в кубе:

Десять лет назад, в апреле 2013, я рассуждал о том, как бы перевести dxdt.ru на HTTPS в качестве основного протокола – процитирую ту краткую заметку полностью:

Можно бы перевести dxdt.ru целиком на HTTPS, но WordPress что-то не готов – генерирует для изображений небезопасные ссылки. Вообще, с HTTPS есть ещё одна проблема: поисковики. Я замечал, что Google умеет не только ходить по HTTPS, но и индексировать такие страницы, а вот насчёт “Яндекса” есть сомнения. В любом случае, ссылки для поисковиков станут другими, так как придётся их роботов перенаправлять с http на https, что ботов не порадует. Можно, конечно, вообще на другой домен всё перенести. Но это, думаю, перебор. Поэтому пока останемся на HTTP, хоть это и прошлый век.

HTTPS, конечно, тогда уже поддерживался на dxdt.ru, но без перенаправления и с сертификатом моего собственного УЦ. Уже в следующем, 2014, году я написал небольшой скрипт, который скорректировал все ссылки с указанием протокола прямо в дампе БД, что позволило победить эффекты WordPress, после чего HTTPS стал основным протоколом dxdt.ru. К проблемам с поисковиками такой переход не привёл, поскольку “Яндекс” тоже уже умел ходить по HTTPS, а сайты с безопасным протоколом чуть позже и ранжировать стали выше.

Сервис проверки настроек интернет-узлов ТЦИ теперь поддерживает TLS-сертификаты НУЦ и ТЦИ в качестве доверенных корневых сертификатов. То есть, теперь узлы, которые используют серверные сертификаты от этих корней, будут получать баллы рейтинга так же, как и с другими доверенными сертификатами.

Омоглифы – это символы, совпадающие по начертанию, но различные по значению (интерпретации). Например, Н, H и Η, а именно – заглавная кириллическая “н”, заглавная “h” английского алфавита и заглавная “η” греческого алфавита. Пришлось тут столкнуться с забавной “программной” интерпретацией данного явления. Пакет Gitea (это пакет для работы с исходным кодом в git, с веб-интерфейсом и прочими полезными функциями) при попытке посмотреть некий русскоязычный текстовый файл из репозитория на сервере – показывал мне в браузере предупреждение, что “This file contains ambiguous Unicode characters!” (“Этот файл содержит “неоднозначные” символы Unicode!”). И действительно, встроенный фильтр подсвечивал буквы вроде “a”, “T” и “о”, но не во всех случаях. Так, целиком подсвечивалось сочетание букв “То” из “То есть”. А в другом месте этого же текста подсвечивалась одинокая буква “а”, при помощи которой обозначался союз “а”.

Сперва показалось, что это действительно в текст прокрались “омоглифы”. Такое случается, особенно, когда используешь несколько раскладок клавиатуры: английская “C” прокрадывается и занимает место “С”, предположим. Однако попытка исправить эти буквы в исходном файле и отправить изменения к успеху не привела: выяснилось, что ничего-то там не меняется – буквы уже использованы кириллические, в файле всё записано верными буквами. Хитрость оказалась в том, что пакет Gitea, руководствуясь настройками “локали” в браузере (а у меня использовалась англоязычная), самостоятельно делал вывод, что данного пользователя могут ввести в заблуждение сочетания кириллических букв, похожие на английские слова, о чём и предупреждал. То есть, “То” в этом “То есть”, выглядит английским “to”, а “а” – неотличима от артикля. В общем, как говорится в тексте, содержащем исходную формулировку знаменитой, – но известной только специалистам, – проблемы Винни-Пуха: “зачем эта хта обязательно та, а жерка, как правило, эта?”. Кто бы мог подумать.

(Уточнение: под “словами” подразумеваются последовательности омоглифов, обособленные пробелами.)

Можно ли в вебе на стороне сервера определить, какой именно версии браузер устанавливает TLS-соединение, в самом начале этого соединения? Например, для того, чтобы выбрать сертификат от подходящего УЦ (см. ниже). Хитрость в том, что привычный способ, когда браузер определяется по HTTP-заголовку User-Agent, тут не подходит: на начальном этапе установления соединения никаких HTTP-заголовков ещё нет, а вот серверный сертификат передавать нужно. И речь не про выбор сертификата на основе перечня поддерживаемых криптосистем, как это делается при настройке параллельной работы ГОСТ-алгоритмов и “обычных” алгоритмов в TLS/HTTPS – эта задача как раз решается весьма просто. Вообще, проблема находится на другом уровне: строго говоря, узнавать нужно даже не столько браузер, сколько конкретную библиотеку, реализующую TLS (так, для Firefox это будет NSS), и конкретный профиль данной библиотеки. Вообще, сделать выбор иногда можно на основе анализа состава TLS-сообщений, но так как набор этих сообщений не велик, а сам перечень может изменяться, то и точность не велика. Тем не менее, конкретная разновидность браузеров могла бы сигналить серверу, что именно такой браузер подключается. Это реализуется через дополнение TLS-сообщений, но внедрение потребует доработки TLS-стека как на стороне сервера, так и на стороне браузера.

А вот что касается именно списка поддерживаемых УЦ, то в TLS уже есть встроенный механизм, в версии 1.3 он так и называется – “certificate_authorities”. Это расширение, которое клиент может включить в состав сообщения ClienHello (начальное сообщение TLS-соединения), а сервер может обработать и – выбрать нужный сертификат, в том числе, для одной и той же криптосистемы. Вот только распространённые браузеры данное расширение не поддерживают, а если бы и поддерживали, то туда пришлось бы вписывать слишком много имён УЦ, так как в типичный дистрибутив браузера их входят многие десятки. Так что доработка, как минимум, браузера – всё равно потребуется.

В марте 2023 года записок на dxdt.ru появилось достаточно для того, чтобы некоторые отметить отдельно в конце месяца:

Офтопик: цвет собак в “Илиаде” – немного про текст Гомера;
ИИ с перебором – роль перебора в практике ИИ;
Детектирование текстов, сгенерированных ИИ – философские аспекты, связанные с “искусственными” текстами;
Системы счисления и системное администрирование – значение нулей в интерпретации данных стандартными библиотеками;
Дорисовывание Луны смартфонами Samsung – проблемы с фальшивыми, но похожими на настоящие, деталями на фотоснимках.