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

(Продолжаем рассматривать занимательные знаки в манускриптах.) В Unicode есть лигатура ϗ, обозначающая древнегреческий союз καί и совпадающая по свойствам и значению со всем знакомым знаком “амперсанд” (& – происходит от латинского et). Занятно, что в старых (9 – 12 века) манускриптах сокращённое древнегреческое καί нередко выглядит похожим на S (но, согласно справочникам, встречаются и весьма экзотические варианты, например, очень близкие по начертанию к @ – такой вариант, похоже, был почему-то популярен в 14 веке, но это вряд ли связано с распространением Интернета). Вот на картинке ниже “скриншот” из манускрипта Venetus A десятого века, который содержит текст Илиады (на этот знаменитый манускрипт традиционно ссылаются, когда нужно привести пример достаточно старого и полного текста Илиады).

(Сокращения καί отмечены стрелкой, штрих “акцента” – тоже входит в обозначение.) Но сам знак ϗ происходит из приписывания к каппе (“κ”) сокращённой записи для “αι” (она как раз похожа на растянутую s): то есть, сокращению в ϗ подвергается не слово целиком, а только часть.

Вот сейчас кругом рассказывают о том, что некоторый ИИ, в качестве автоматической говорилки, заменит всех подряд “высококвалифицированных специалистов”. Это занятно. Возьмём в качестве примера задачу реализации шифра на языке высокого уровня. Какой подразумевается целевой процесс, когда “всех заменили”? Предполагается, что задачу для ИИ в вольной форме ставит человек, который увидел название шифра и эталонные тестовые примеры, предложенные разработчиками шифра. Как этот человек проверяет реализацию, выполненную силами ИИ? Правильно: передаёт в получившийся код тестовые примеры и сравнивает результат.

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

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

• Gitea и омоглифы не в ту сторону
• Poison-расширение и SCT-метки в Certificate Transparency
• “Начала” Евклида, палеография и особенности чтения манускриптов

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

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

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

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

Предположим, что некоторые интернет-измерения, проводимые с использованием веба, полностью основаны на уникальном имени хоста, которое генерируется под каждый запрос. Это очень удобный способ создания информативного маркера, переходящего между протоколами. Имя нетрудно встроить, например, в адрес источника файла изображения, ссылка на которое входит в состав кода веб-страницы. Почему подходит именно имя хоста? Потому что оно же будет использоваться клиентом и в DNS, и в HTTP. А вот часть URL, соответствующая адресу документа, уже в DNS не ходит. Другими словами: используем в браузере (условный) URL https://123dio.cba.example.net/an-img.gif, где полезные данные кодируются в части 123dio.cba. Строка 123dio.cba.example.net отправится и в DNS, где будет узнана специальным сервером, и в HTTP, а вот an-img.gif – в DNS не попадёт, а поступит только на веб-сервер, отвечающий под 123dio.cba.example.net. Соответственно, насыщение HTTP-запросов полезной информацией, которую мы хотим видеть и в DNS, должно происходить через имена хостов.

Однако возникает неприятная проблема с HTTPS: дело в том, что для установления соединения с браузером сервер под “странным” именем 123dio.cba.example.net должен предъявить TLS-сертификат, валидный для этого имени, но имя-то каждый раз разное, поэтому сертификатов не напасёшься (если их выпускать через тот или иной УЦ, признаваемый браузерами). Использование открытого HTTP тут не рассматриваем – такие условия: хотя бы потому, что страница-носитель загружается по HTTPS. Что можно сделать? А можно, например, совсем отказаться от установления TLS-соединения на стороне сервера и при этом не потерять полезных данных. Нам не требуется реально обрабатывать HTTP-запрос и возвращать файл изображения, нам нужно только зафиксировать на сервере имя хоста, а это имя в HTTPS/TLS передаётся клиентом в начальном сообщении, да ещё и в открытом виде (это как раз и есть SNI TLS). Так что серверный сертификат тут просто не нужен: сервер записывает имя хоста из SNI и – прерывает соединение с тем или иным кодом ошибки TLS.

(Дополнение – 30/04/2023: в комментариях справедливо указывают на wildcard-сертификат для имён вида *.example.net. Однако тут такой сертификат не сработает, поскольку для DNS-части измерений важны кодирующие имена минимум в двух уровнях, то есть, *.*.example.com, а wildcard-сертификат закрывает только один уровень. Несколько уровней – входят в качестве требования в изначальную задачу, оставшуюся здесь за скобками.)

На картинках ниже – замок Fichet 787 с “рычажным” механизмом (источник фото: Toool Blackbag).

Замок в разрезе и ключ (фото: CC-BY-4.0 Jan-Willem, Toool Blackbag).

Фрагмент основной части механизма (фото: CC-BY-4.0 Jan-Willem, Toool Blackbag).

“Кодирующая” часть ключа содержит пазы, которые сдвигают внутренние рычажки (1), поворачивающие через зубчатое зацепление диски (зубчатые колёсики – 2), блокирующие вращение механизма: если углы, выставленные на ключе, соответствуют коду замка, то колёсики поворачиваются так, что прорези в них совпадают, образуется общая длинная прорезь, что и освобождает траверсу, делая возможным поворот. Занятно, что устройство, вообще-то, аналогично дисковому, например, замку, но здесь пакет дисков повёрнут относительно ключа, поэтому вместо “угловых бородок” получаются пазы, а для преобразования углов вращения служат рычажки (последние, кстати, можно считать “транслированным” вариантом цилиндров-штифтов в обычных “английских” замках – просто, прямолинейный подъём штифта здесь преобразуется в поворот).

Кстати, в продолжение Certificate Transparency. Регулярно приходится сталкиваться с вопросами или предположениями относительно того или иного TLS-сертификата, которые сопровождаются недостаточным количеством “иллюстративных” данных. (Эта записка – рекомендации для обычных пользователей.)

Предположим, что вы где-то встретили или обнаружили “подозрительный TLS-сертификат” и хотите получить комментарии специалиста про этот сертификат. Как поступить?

Прежде всего: необходимо сохранить сам файл сертификата непосредственно и полностью. Скриншот окна Windows с информацией “об издателе” и со сроками действия – никак не позволяет что-то содержательное сказать о сертификате: по этим данным даже нельзя судить о том, разные сертификаты вы просматриваете или один и тот же. Сохранить сертификат можно при помощи функции экспорта. К сожалению, реализации этой функции существенно различаются от приложения к приложению. Например, в браузере нужно кликнуть на “замочек в адресной строке” или на вкладку панели веб-разработчика, соответствующую настройкам безопасности сайта, или ещё куда-то, но логика данного действия общая – нужно найти, где сертификат сервера (веб-сайта) экспортируется в файл. Файл может иметь разные форматы (Base64, “двоичный”) и разные расширения в имени (.pem, .cer, .der, .bin, .cert и др.), но это, обычно, не важно – для специалиста это редко является проблемой. Главное – получить сам сертификат полностью в файле. Если функция экспорта позволяет сохранить “цепочку сертификатов” – тем лучше, сохраните цепочку. Основная причина, по которой нужен именно файл, в том, что сертификат содержит значение подписи, а это значение является доказательством того, что сертификат действительно был выпущен и подписан с использованием того или иного ключа. Кроме того – можно удобным способом просматривать все поля сертификата (серийный номер, расширения, ключ и пр.).

Если вам по каким-то причинам удаётся просмотреть только значения конкретных полей сертификата, то, во-первых, нужно сразу отметить, что ценной информации будет очень мало, и, во-вторых, попытаться сохранить серийный номер, отпечаток сертификата (значение хеш-функции для сертификата), имена, – то есть, название УЦ и имя, для которого сертификат выпущен (Issuer, Subject, Subject Alternative Name), – значение ключа (или отпечаток ключа; в сертификате публикуется открытый ключ) и тип криптосистемы, значение подписи с указанием на тип криптосистемы, сроки действия и сведения о цепочке сертификатов (серийные номера, имена, отпечатки), использованной для валидации.

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

На сайте ТЦИ (Технический Центр Интернет) опубликована моя статья о технологии Certificate Transparency (CT) и её роли в современном Интернете. Статья рассказывает не столько о базовых принципах построения CT (они достаточно широко известны), сколько об особенностях реального применения данной технологии – о проблемах, связанных с неверной интерпретацией значения меток в сертификатах, о полноте CT-логов.

Certificate Transparency […] лишь предоставляет инструмент для наблюдения за деятельностью УЦ, но никак не ограничивает эту деятельность на техническом уровне.

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

Кстати, даже в немецкой прессе современный Чарльз остался Charles (то есть, в английском варианте), а в самой Великобритании эпоха правления называется (new) Carolean era, однако Чарльз там всё равно король Чарльз (не Карл, естественно, хоть это, понятно, одно и то же имя, а в английском расщепить его на два представления довольно сложно, как бы ни хотелось). При этом подходящих исторических периодов, названия которых образуются от карлов (латинское влияние), в локальной англоязычной традиции есть два, и их предлагается не перепутать: Caroline/Carolean.

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

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

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

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

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

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

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

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

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