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

На всякий случай: я планирую в обозримом будущем сделать основным именем dxdt.PW – вместо dxdt.RU. Сейчас под dxdt.PW сайта нет (там пока нет A-записи). Замену имени я планирую делать так: заведу dxdt.pw на тот же IP-адрес, который сейчас показывает на веб-узел с dxdt.ru; настрою на этом же веб-сервере универсальный редирект на новое имя: dxdt.ru -> dxdt.pw; постараюсь поменять “титульные” ссылки внутри WordPress, которые сейчас ведут на домен в зоне .ru. После этого веб должен плавно и прозрачно переключиться на новый адрес, в том числе, в части RSS. Обратную зону и почту на dxdt.ru – пока планирую оставить как есть, они не особо важны: комментариев практически нету, рассылки никакие уже давно не ходят.

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

Сразу видно, что чётность нарушена. Монеты разложены по возрастанию года выпуска, слева направо: королева Виктория, король Эдуард VII, король Георг V (это не Николай Второй, это его брат, но двоюродный), король Георг VI, королева Елизавета II. Чётность поворотов профилей нарушена между Георгом V и Георгом VI. Почему?

Потому что между ними был король Эдуард VIII, но он быстро отрёкся от престола – настолько быстро, что и монеты с его профилем выпустить в массовое обращение не успели. Монеты периода Эдуарда VIII явно существуют, но это лишь экземпляры из тестового выпуска, так что они являются одними из самых редких монет в мире (поэтому на данной картинке и нет соотвествующего шиллинга). То есть, казалось бы, чётность сохраняется? Можно даже применить основы топологии и обнаружить, что один король пропущен? Но это не совсем так.

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

В продолжение предыдущей записки. Два подхода к аутентификации сервисов и приложений – по отпечатку (значению) открытого ключа и по TLS-сертификатам. Сравним эти подходы с точки зрения того, на какое звено оказывается завязана аутентификация на практике. Пример первого подхода, непосредственно по ключам, – классическая конфигурация SSH (но не только, конечно, можно посмотреть на WireGuard и другие протоколы). Пример второго подхода – TLS с двухсторонней аутентификацией (клиента и сервера, mTLS).

Предположим, что у нас клиент (приложение) обращается к серверу. И приложение обнаруживает сервер по имени, с использованием DNS. Пока что будем считать, что и в первом, и во втором случае, системные и сетевые настройки – типовые, а вариант с TLS использует системный список хорошо известных доверенных УЦ (случай с собственным выделенным УЦ разобран отдельно). Рассмотрим разные ситуации в рамках задачи подмены сервера. То есть, задача атакующего – получить подключения клиентов на свой сервер так, чтобы клиенты ничего не заметили. Клиенты здесь – это приложения.

Что получается с вариантом TLS. Клиент находит IP-адрес сервера через DNS, а проверяет подписи в сертификатах. Ни то, ни другое – не привязаны к серверу. Поэтому, – “внезапно!” – решение оказывается полностью завязано на защиту авторитативных серверов зоны, в которой размещены имена серверов, и DNS-резолвера. Почему? Потому, что если атакующий может подставить IP-адрес своего сервера в ответ DNS, то клиент станет подключаться по TLS к подставному серверу. При этом клиент проверяет только валидность серверного сертификата, то есть, подпись на сертификате должна сходиться к доверенному ключу удостоверяющего центра (УЦ). Но при типовых настройках в этом списке больше сотни УЦ, а контроль над авторитативными серверами DNS (даже над одним) позволяет выпустить сертификат для нужного имени в одном из этих УЦ, например, в Let’s Encrypt. Естественно, речь о системе, которая находится в глобально доступной DNS. Но, скажем, Let’s Encrypt и так повсеместно используется для внутренних имён разных API и тому подобных штук: посмотрите в CT-логи, если хотите убедиться лично.

Тут нужно заметить, что получение контроля над локальным DNS-резолвером атакуемой системы не позволяет выпустить сертификат от внешнего УЦ (потому что УЦ использует другой DNS-резолвер), но всё равно позволяет перенаправить клиентов: в теории, при отсутствии на подставном сервере валидного и доверенного сертификата, клиент обнаружит подмену средствами TLS. (Впрочем, на практике валидацию на клиенте вообще нередко отключают – insecureSkipVerify и тому подобные вещи, – это, понятно, сводит тут защиту примерно к нулю; как и использование самоподписанного серверного сертификата.)

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

Промежуточный итог про TLS: даже при корректной реализации защита от подмены полностью завязана на стойкость DNS; защита никак не зависит от ключей на клиентах и серверах, а перехват DNS позволяет выпустить подменный сертификат от внешнего УЦ. То есть, даже если предполагается, что сертификат сервера должен быть от собственного, корпоративного УЦ, но в списке доверенных есть и ключи других УЦ, – а это часто так, – то сгодится сертификат от любого из этих УЦ. (Кстати, можно использовать не DNS, а локальную таблицу хостов. Это помогает частично, но тянет за собой другие риски.)

Теперь вариант с проверкой отпечатков ключей (SSH и прочие решения с key pinning). Значения допустимых ключей прямо задаются и на клиенте, и на сервере. Сейчас принято на клиенте сохранять серверный отпечаток при первом подключении. Но вообще известные отпечатки можно заранее настроить другими способами.

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

Конечно, в схеме аутентификации по ключам подменный сервер может точно так же принимать любой клиентский ключ, без проверки, как и в случае клиентских TLS-сертификатов, но ситуация всё же лучше: третья сторона уже не может предоставить валидный способ аутентификации клиента. Напомню, что в случае с mTLS можно выпустить валидный клиентский сертификат без участия реального клиента, если есть доступ к УЦ. Но это, ообычно, другой УЦ – именно для клиентских сертификатов, скорее всего, внутренний (но не обязательно).

Промежуточный итог про отпечатки ключей и SSH: из-за того, что тут проверяется конкретный ключ, никакая внешняя подмена не поможет, поэтому схема перестаёт зависеть только от надёжности DNS.

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

Использование mTLS с собственным УЦ тоже помогает, но отчасти: если клиенты используют не типовой системный список доверенных ключей УЦ, а верят только в ключ конкретного, внутреннего УЦ, который предназначен строго для данной системы, ограничен в выборе хостов, а сертификаты выпускает по запросам администратора, то перенаправление DNS уже не сработает. Но и такая система оказывается защищена на уровне защиты упомянутого УЦ: то есть, ситуация оказывается даже несколько проще, и если есть сетевое перенаправление, то для успешной подмены сервера нужно получить контроль над скриптами внутреннего УЦ (а не DNS). Если вы подумали, что внутренний УЦ будет защищён лучше, чем DNS – то, как бы, это не обязательно так на практике.

Естественно, применение ACL на уровне сетей, на уровне виртуализации, сильно затрудняет подмену через DNS. Если доступ наружу открыт только в направлении некоторых “собственных сетей”, то перенаправить соединение на внешний узел просто так не получится. Но, во-первых, ACL могут настраиваться с использованием DNS; во-вторых, если ACL выстраиваются с точностью до IP-адреса (не IP-префикса), то зачем же тогда вообще прописывать хостнеймы? Как бы там ни было, но на описанные разные подходы к аутентификации – ACL не влияют.

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

Посудите сами. Речь тут идёт о типовой схеме с SSH-ключами (в SSH тоже можно сделать “сертификаты”, но сейчас не об этом). Итак, в SSH имеем аутентификацию по отпечаткам ключей каждой стороны: сервер, фактически, проверяет отпечаток (то есть, значение – не важно) открытого ключа клиента; а клиент – отпечаток открытого ключа сервера. Стороны аутентифицируют каждая каждую напрямую, без помощи третьей доверенной стороны. Если ключ скомпрометирован, то его нужно непосредственно исключить по значению из списка доверенных. Например, удалить на сервере из authorized_keys.

При этом список доверенных ключей каждая сторона ведёт собственный (да, могут быть вспомогательные механизмы автоматического добавления снаружи и, также, внешней проверки, но штатный способ – собственная, локальная проверка). Включение в список доверенных ключей выполняется с участием администратора. На клиенте, нередко, добавление выполняется автоматизированно, при первом соединении (но не всегда так). Да, тут есть проблема, что многие администраторы и DevOps сейчас, подобно пользователям браузеров, начинают привыкать к игнорированию сообщений о добавлении новых отпечатков в доверенные. (Но действующую подмену, вообще говоря, в правильно настроенном SSH-клиенте проигнорировать сильно сложнее, чем в браузере.)

Теперь TLS. Двусторонняя аутентификация: серверный и клиентский сертификаты. Тут обязательно участвует третья сторона: штатный способ аутентификации – проверка подписи на сертификатах ключей. Технически, можно сравнить отпечатки (key pinning и пр.), но это будет за рамками типовой схемы. Типовая же схема требует сравнения не отпечатка, а подписи, поставленной третьей стороной. Совсем другая история, по сравнению с SSH. Именно что от слова “совсем”. Тут уже нельзя “отключить ключ” клиента или сервера, просто удалив его из списка доверенных. А если нет способа внешней проверки статуса сертификата и способа отзыва сертификатов, то всякий действующий (по времени) сертификат с верной подписью удостоверяющего центра будет всегда принят стороной, проводящей проверку. Подпись известного удостоверяющего центра верна? Верна. Принимаем. Без вариантов.

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

В схеме SSH, чтобы подставить ключ на сервер – нужно прописать его значение в файл на сервере. В схеме с TLS-сертификатами – нужно подписать сертификат на стороне УЦ. На сервер, которому будет предъявлен валидный сертификат, даже не потребуется заходить.

Так что подходы к аутентификации в SSH и TLS (по сертификатам) – совершенно разные, нельзя их смешивать.

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

После бурной реакции тех, кто оказался в теме, хайп-сообщения “про решение силами ChatGPT” – удалены. Более подробный разбор, со скриншотами удалённых уже “твитов”, есть на сайте The Decoder (англ.). Журналисты издания задаются резонным вопросом: как так могло получиться, что ведущие AI-исследователи из OpenAI публикуют подобные “сильные утверждения”, даже не проведя минимальную проверку фактов? И действительно – как? Риторический вопрос.

Пишут, что в браузере Firefox внедряют встроенный “сервис VPN”, который будет доступен “только для браузера”. То есть, строго говоря, это не VPN на уровне операционной системы, а именно наложенная сеть, предназначенная для клиентов-браузеров, поддержка которой в браузер и встроена. И такая сеть служит транспортом для доступа к веб-ресурсам конкретно браузером.

Развитие в этом направлении давно ожидалось: это логичный шаг, а сходную систему внедряет Google для Chrome. В целом, то, что веб, с точки зрения доступа, будет замыкаться внутри браузера, стало понятно ещё тогда, когда браузеры получили собственный доступ к DNS, минуя операционную систему – сейчас это встроенная в браузеры поддержка доступа к DNS-резолверам через DNS-over-HTTPS/DNS-over-TLS.

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

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

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

The chap the cat the girl owned scratched screamed.

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

Это пример так называемого “центрального встраивания”, “центрального эмбеддинга” (а ещё точнее: center embedding – на английском). Лингвистическое явление, важность которого для парсинга языковых грамматик, – в том числе, и прежде всего, людьми, – определил Хомский.

Вернёмся к фразе ещё раз:

The chap the cat the girl owned scratched screamed.

Можно использовать фигурные скобки и переписать предложение так, что получится “код” на некотором условном языке “программирования”. Условном, но зато очень высокого уровня.

The chap {
	the cat {
		the girl {} owned 
	} scratched 
} screamed.

И это уже можно разобрать. Пошагово выписываем то, что за внутренними скобками:

The chap – screamed,
the cat – scratched,
the girl – owned (тут специально поставлены пустые скобки, чтобы наметить рекурсивный принцип, лежащий в основе встраивания).

Если, как говорится, своими словами, то пересказать можно так: “Парень вскричал, потому что его поцарапала кошка, принадлежавшая девушке” (или кот? nyet, “кот” – был бы tom). Owned (“была владеема”, если дословно) – относится к кошке, со стороны девушки. Если переставить слова, то получим: the girl owned the cat – “девушка владела котом/кошкой”. Казалось бы – эквивалентная конструкция. Но нет, не совсем, потому что парсинг разных записей будет разным. То есть, смысл, стоящий за {the cat the girl owned} и {the girl owned the cat}, может быть и одинаковый, но к этому смыслу ещё нужно привести текст, записанный разным способом. Это напоминает понимание логических формул, как “записей”, которое понимание даётся с трудом. Кроме того, наблюдаемый эффект очередной раз подчёркивает то, что в самом тексте смысла нет.

Итак, возвращаемся к разбору исходного упражнения: the girl owned the cat – “девушка владела кошкой”. И эта кошка поцарапала парня. Поцарапанный принадлежащей девушке кошкой парень – вскричал: screamed.

Эмбеддинг позволяет вложить отношения одно в другое, “подвесив” каждую половину пары в ожидании глагола, а все три смысловых пары – в ожидании возникновения структуры вложенности. Посудите сами: the chap – подвешивает “объект парень” (что “the chap” сделал, что – не сделал; что с ним произошло?), для разрешения нужен ответный элемент лексической конструкции, в данном случае – глагол screamed, но он стоит в самом конце, а вместо него парсер читает the cat. Тут парсер должен запомнить, что не хватает соединения для предыдущего “объекта” и продолжить разбирать фразу. Но третим пунктом опять идёт “подвешивание”: the girl. И только потом – начинаются “замыкающие” глаголы, которые нужно правильно подключить.

Реально ли такой же эффект получить на русском? Можно попробовать, но результат всегда будет лишь приблизительный, да и то, только если без запятых. Причина в том, что русский – не столь аналитический, как английский. Например:

“Парень кошкой девушке принадлежащей поцарапанный вскричал”.

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

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

Потому что если парень кошкой вскричал, то “поцарапанный” повисает полностью, уже ни на что не опираясь. А если всё же приклеить “поцарапанный” к парню, – ну, кошкой вскричал он, поцарапанный, – то что делать с “принадлежащей”?

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

Другой вариант на русском:

“Парень, кошка, – девушка владела, – поцарапала, вскричал”.

В каком-то смысле, этот вариант лучше. Естественно, на русском тут необходимы запятые, да ещё и тире, иначе предложение записано неверно. Кстати, если вам говорят, что “в английском запятые не нужны”, то это не так – ещё как нужны, но не в рассматриваемом предельном случае. Впрочем, теперь и этот русский вариант понять можно без запятых:

“Парень кошка девушка владела поцарапала вскричал”.

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

Более того, если использовать множественное число, то можно отказаться от артиклей the (для единственного – отказаться никак нельзя: получится сильно “неграмматический” вариант). Например, в подборке головоломок Quanta Magazine предлагалось раскодировать следующую, чисто рекурсивную, фразу:

Bulldogs bulldogs bulldogs fight fight fight.

Опять же, это грамматически корректное предложение на английском. Но понять, кто тут кого “борет” – непросто. (Весьма вольный перевод, в котором все “бульдоги” – это бульдоги из разных стай: «бульдоги, которые дерутся с дерущимися бульдогами, тоже нарвались на бульдогов, которые дерутся». Ну или что-то в этом роде: бульдоги – они такие.)

В разговорном языке подобные конструкции, – третьего уровня, – практически не встречаются. Тем не менее, вот более чем реальный пример «канцелярита» из документа под названием British road traffic act, 1972 (это что-то вроде дополнений к правилам дорожного движения, не важно) – вчитайтесь:

A person who, when riding a cycle, not being a motor vehicle, on a road or other public place, is unfit to ride through drink or drugs shall be guilty of an offence.

Всё понятно? Конечно. “Лицо, которое, когда едет на велосипеде, который не является транспортным средством, по дороге или по другому общедоступному пространству, не способно ехать из-за алкогольного или наркотического опьянения, должно быть признано совершившим правонарушение”. Всё верно, но – уф!

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

It’s ironic that I’m here, where the man the trophy I won is named after coached.
(Источник: Fred Karlsson, Multiple Center-embedding in Spoken English.)

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

Получается, что в ходе непростого декодирования подобных конструкций парсер вынужден “подвешивать” существительные до момента их “разрешения”, например, глаголами. При этом двойное подвешивание вообще не составляет проблемы в английском: the ball the cat dropped bounced. Совсем сложные случаи почему-то начинаются с трёх подвешиваний.

Возможно, причина в том, что каждое подвешенное существительное потребляет некоторый важный ресурс парсера. Скорее всего, рассматривая примеры предложений выше, вы сами можете почувствовать это исчерпание ресурса, приводящее к “зависанию” “сознательного парсера”. То есть речь тут вовсе не про программу или LLM. Что это за ресурс? Возможно, специальная структурная лексическая память, а возможно, некий “модуль” “разрешения противоречий”. Предположим, данный модуль должен заранее занять некий объём доступных связей, чтобы потом собрать из них уже осмысленный, непротиворечивый вариант, присоединив понятия лексическими коннекторами одно к другому – так, как нужно. Однако, при разборе подобного эмбеддинга, вместо подключений смыслов происходит “тик, тик, тик” по уровням, и каждый “тик” – это подвешенный коннектор, который требует предварительного захвата кучи возможных связей для обеспечения своего “висения” против всего корпуса возможных смыслов.

Описанное переполнение в английском наступает раньше, и это переполнение – однонаправленное (слева направо). Вернёмся к исходному предложению: The chap the cat the girl owned scratched screamed – может, пацан-парень (the chap) тут – это тот, который принадлежит кошке и девушке (the cat the girl owned)? Мало ли – они могли его захватить. Но тогда не хватает союза (and?) и повисает царапанье (scratched).

Вспомогательные элементы, типа “который”, “где” и др. – они как бы есть в английском варианте, но там они “нулевые”, обозначены пустыми словами, и только если рассматривать текст во всей полноте, тут же возникают в построенной структуре. Это важный момент. И он, опять же, подтверждает, что в любом тексте, – как в тексте, – никакого смысла нет: смысл образуется в представлении читающего. Конечно же, можно добавить структурных элементов, типа who, what, that и пр., в английский текст. И получится знаменитый This Is the House That Jack Built:

This is the cat
That killed the rat that ate the malt
That lay in the house that Jack built.

Схема в чём-то похожая, но парсер уже не переполняющая.

(Это дополненная версия статьи, которую я ранее опубликовал на “Хабре”.)

Ars Technica пишет (англ.), что корпорация Deloitte пыталась сдать правительству Австралии некоторый отчёт по результатам исследования автоматизированной системы, используемой одним из министерств, но в тексте отчёта обнаружились ссылки на несуществующие публикации и вымышленные цитаты, приписанные вполне реально существующей сотруднице университета, профессору. Что, собственно, и вызвало подозрения. Естественно, текст был сгенерирован ИИ, в чём Deloitte и признались. Пример “успешного внедрения ИИ-инструментов”, чего уж там.

Теперь часть денег, выплаченных австралийским правительством за отчёт, сгенерированный ИИ, правительству вернут, а текст отчёта поправили, скорректировав “спорные моменты”. Подготовка отчёта, как заявлено, обошлась налогоплательщикам в $290000. То есть, смысл подобных отчётов тёмен, однако экономия на “генерировании ИИ”, видимо, очень существенная. Но никто из “людей в теме” не посмотрел результат. И понятно почему никто не посмотрел: какой экономический смысл в том, чтобы специалисты просматривали и корректировали “галлюцинации ИИ”? Смысла нет – эффективность тут же падает до нуля, и даже ниже, потому что это очень дорого, разбирать сгенерированный бред.

Опубликовал на “Хабре” небольшой обзор про монеты Великобритании и децимализацию (переход на 100-пенсовый фунт от старой системы из шиллингов).

Из записок, которые вышли на dxdt.ru в сентябре 2025, отдельно отмечу три:

• Квадратное уравнение на глиняной табличке
• Реплика: монеты и наличные деньги
• Понимание переменных float как записей алгоритмов

Один из сервисов RIPE NCC (это региональная регистратура IP) присылает мне раз в месяц по электронной почте письмо с некоторой простой статистикой, связанной с этим сервисом. Статистика там пустая. Так и должно быть: я свою часть этого сервиса давно отключил. Но вот сегодня данное письмо пришло с содержанием в формате HTML. И только в HTML. Да ещё и со ссылкой на внешний файл с изображением (<img>). Естественно, никакого смысла использовать HTML там нет.

До этого момента, много лет, приходило нормальное письмо, в text/plain. Видать, добрались и до систем RIPE NCC новые веяния. Печально. Скоро нужно ожидать перехода от BGP к построению маршрутов силами AI/LLM через парсинг HTML-страниц.