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

На 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 – проблемы с фальшивыми, но похожими на настоящие, деталями на фотоснимках.

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

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

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

Появилось открытое письмо, призывающее “приостановить эксперименты с большим искусственным интеллектом” (“Pause Giant AI Experiments”) и ввести регулирование, в том числе, “контроль и отслеживание” “мощных вычислительных средств” (“large pools of computational capability”). Занятно, что там в качестве основы шкалы используется GPT-4 – то есть, буквально, предлагается всем немедленно приостановить “обучение” систем, более мощных, чем GPT-4. Приостановить – как минимум, на шесть месяцев; но, как можно предположить по тону и смысловому содержанию письма, более точная интерпретация такая: приостановить до того момента, пока не введут нужные запреты на уровне правительств. Довольно показательный PR-шаг. Особенно, если взглянуть на него в исторической перспективе развития глобальной Сети, которая, несомненно, для разных там Chat GPT – имеет первоочередное значение.

На сайте есть страница “Избранное“, на которой я веду список избранных записок (удивительно, правда?). Посмотрел, как этот список пополнялся за десять лет (2012-2022), вот что получилось (год – количество записок):

• 2022 – 4
• 2021 – 3
• 2020 – 5
• 2019 – 5
• 2018 – 3
• 2017 – 8
• 2016 – 14
• 2015 – 10
• 2014 – 21
• 2013 – 14
• 2012 – 17

Несомненно, такие показатели связаны с тем, что в какой-то момент вообще уменьшилось количество публикуемых записок, но связь эта не самая прямая, так сказать: нельзя забывать о том, что и требования могли поменяться. Скажем, я считаю, что из публикаций за 2022 год очень и очень ценная записка – “О визире и слоне“. Соответственно, эта записка задаёт и канву для других избранных за 2022 год, и их оказывается мало. А вот к запискам из 2012 – требования несколько другие.