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

Некоторые начинают о чём-то догадываться – в отношении “использования ИИ”. Вот The Register пишет (англ.), со ссылкой на исследование из Стэнфорда, что бред, генерируемый ИИ, не так уж полезен в рабочем процессе, поскольку и разбор наукообразной чепухи отнимает много времени, и доверие к источникам подобного резко падает. Для обозначения сгенерированного “с рабочими целями” LLM-текста применяют занятный красочный термин – workslop, от work+slop, что означает: “рабочие (служебные) помои”.

Вообще, проблему с тем, что информационное пространство кругом быстро замусоривается сгенерированным бредом, уже заметили очень многие: восклицания, “что в Интернете невозможно ничего найти” и “постоянно приходится продираться сквозь наукообразную чепуху высшего порядка, сгенерированную LLM” – слышны всё чаще. Приведу свежий пример: я недавно попытался найти какие-то внятные описания того, как должна выглядеть буква “O” (латинская) на реверсе монеты в один пенни Великобритании за такой-то период. Вместо ссылок на внятные разборы (которые, очевидно, всё ещё есть в доступе – это же одна из основ практического исторического метода) – поиск Google выдал сгенерированный ИИ/LLM “ответ”, в котором, с первых же слов, буквально, утверждалось (на английском), что “никакой буквы O на реверсе таких монет нет, поскольку там написано ONE PENNY”. Вот так. Да, ONE – написано, но вот буквы “O” – нет. Отличный пример того, куда ведёт всё это использование “прорывных технологий ИИ” тут и там, навязываемое “с высоких трибун”. Но ничего уже не поделать: например, тот же ресурс “Хабр”, как я обнаружил, нынче просто затоплен подобным сгенерированным потоком.

Да, конечно, тут можно уточнять, что, мол, в примере про монету, данная “поисковая” система имела в виду, что нет отдельной буквы “O”, как обозначения монетного двора, серии или чего-то подобного. Но это всё будет выдумка, тщетная попытка придать содержательности продукту синонимайзера-переростка – потому что исходная система ничего в виду не имела, а просто сгенерировала текст, который совсем не попал в запрос; и всё вместо того, чтобы хотя бы попытаться правильно ранжировать источники.

Что касается довольно шумной темы “белых списков” в “Интернете” (так называемом) – процитирую свою публикацию 2019 года:

Блокирование же трафика по IP-адресам несет немало побочных эффектов, что, впрочем, вряд ли способно предотвратить его использование. Предельным вариантом здесь может быть использование белых списков узлов, но тогда это будет уже не Интернет, а закрытая частная сеть.

То есть, тут ключевой момент – “это уже не Интернет”, поэтому-то, в контексте Интернета, тут и обсуждать особенно нечего. Но, тем не менее, ещё одна цитата из той же публикации, про возможное развитие:

Среди перспектив развития систем контроля трафика (именно контроля) можно отметить пропуск только авторизованного трафика. Конечно, такой вариант пока кажется фантастикой. Авторизация трафика — это развитие схемы с белыми списками. В этом случае доступ по спискам IP-адресов и имен не ограничивается, но промежуточные узлы пропускают только трафик, который содержит специальные криптографические маркеры, подтверждающие его легитимность.

Мессенджер Signal внедряет платное централизованное хранение резервных копий сообщений на своих серверах. Занятно, что Signal позиционируется как “безопасный мессенджер”. Впрочем, вряд ли какое-то из этих новомодных приложений не позиционируется как “безопасное” или “самое безопасное”.

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

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

Кстати, я в прошлом году писал про особенности хранения копий сообщений мессенджеров.

В Cloudflare выпустили разбор ситуации с выпуском неавторизованных TLS-сертификатов для 1.1.1.1. Пишут, что в логах Certificate Transparency (CT) эти TLS-сертификаты не обнаружили потому, что не отслеживались сертификаты для IP-адресов, в мониторинг приходило слишком много сообщений из CT, а также и не для всех доменов/ресурсов настроили отслеживание сертификатов.

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

В продолжение предыдущей заметки, про подозрительные сертификаты для 1.1.1.1, выпущенные УЦ Fina RDC 2020: интересно, что, согласно crt.sh, соответствующие пресертификаты есть и в CT-логах (Certificate Transparency) Cloudflare. Выпускать такие “странные” сертификаты в данном УЦ начали ещё в прошлом году. То есть, получается, что либо Cloudflare вообще не следит за именами из сертификатов даже в тех CT-логах, в которых является провайдером, либо это всё же по согласованию с Cloudflare выпущено. Естественно, последний вариант – ну уж совсем маловероятен, а вот в то, что Certificate Transparency не отслеживается – поверить как раз нетрудно.

Обнаружились подозрительные TLS-сертификаты, валидные для IP-адреса 1.1.1.1 (в поле SAN), но, видимо, выпущенные без согласия компании Cloudflare, являющейся оператором адреса. Один из сертификатов довольно свежий – 26 августа этого года. Выпущены эти сертификаты УЦ (Удостоверяющим Центром), ключи которого, как пишут, входят в список доверенных Microsoft Windows (но не Mozilla, и не Google Chrome).

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

Такой сертификат, при наличии секретного ключа, позволяет незаметно для пользователя перехватить TLS-трафик в сторону IP-адреса 1.1.1.1, который соответствует нескольким глобальным сервисам Cloudflare (DNS-резолвер и VPN-сервис, как минимум). Чтобы перехват сработал – клиентское ПО должно считать ключи УЦ доверенными, так что, получается, в такой конфигурации сработает только для Windows (ну или только в браузере Edge, если он использует отдельный набор корней, а сама ОС этому УЦ не верит).

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

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

Интересно, что сейчас применение маскирования IP обещают по списку доменов, который доступен на Github; в этом списке, на момент написания записки, значится почти весь “официальный” веб от “Яндекса” (yandex.ru, mc.yandex.com, yandex.st и др.), а кроме того: vk.com, mail.ru и прочие, хорошо узнаваемые в Рунете, доменные имена.

В августе 2010 года, пятнадцать лет назад, в небольшой заметке про DNSSEC, я, действуя несколько неосторожно, предположил буквально следующее:

До нового Интернета остались такие шаги (думаю, в таком порядке, как они перечислены дальше): DNSSEC на клиентах (года два на выполнение), строгое подписывание анонсов BGP и криптографическое удостоверение AS-ок (три-пять лет), переход подавляющей части трафика на IPv6 (пять-семь лет). А может даже и раньше.

Интересно сравнить с реальностью в 2025 году.

DNSSEC на клиентах

Да, тут было очень активное движение в обозначенную сторону. Сделали плагины для браузеров, например. Даже сперва всё уложилось в те самые два года, но, к сожалению, распространения не случилось и постепенно тема замылилась, пусть и не погасла совсем. То есть, что уж там в 2012, но сказать, что DNSSEC повсеместно внедрена на клиентах даже в 2025 году, конечно, нельзя: ландшафт тут вообще перекосило в другую сторону (см. ниже), а технология-то DNSSEC и в DNS-зонах не получила распространения, куда уж там клиентам.

Однако настроить клиентскую поддержку всё же можно, да и движение с переносом валидации на клиента, пусть и самое минимальное, но пока сохраняется: см. например, systemd-resolved в современных линуксах. Что ещё по этой теме есть сейчас? Ну, в те же браузеры собственный интерфейс “DNS-резолвинга” таки встроили, но это DNS over HTTPS/DNS over TLS, где проверка DNSSEC оставлена внешнему провайдеру. Это не очень-то хорошо, но что же поделать? Как минимум, TLS тут даёт какой-то инструмент для трансляции доверия. В общем, если вычесть всякие технологические оговорки, массовое внедрение “DNSSEC на клиентах” не случилось, сейчас его нет, так что прогноз про два года, строго говоря, не оправдался. Да и DNSSEC, из-за своей хрупкости, вообще не пользуется спросом в непростое время сегментации интернетов.

Строгое подписывание анонсов BGP и криптографическое удостоверение AS

“Подписывание анонсов” – это имеется в виду “сквозной” и строгий вариант sBGP, когда каждый “хоп” ставит проверяемую подпись. Не случилось. Подвижки тут тоже есть (BGPsec, SIDR Ops и др.), но пока даже нет причин говорить, что реализация как-то близка. Причины банальные, как ни странно: мало кому это нужно; как и в случае с DNSSEC – технология хрупкая, это многих пугает; большой риск централизации – тоже не особо хорошо в ситуации, когда идёт битва за банхаммер.

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

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

IPv6 как транспорт для подавляющей части трафика

Тут я уже осторожно указал дистанцию в пять-семь лет по времени, и через пятнадцать лет у нас трафик по IPv6 в Интернете большой, но не подавляюще большой. Популярность IPv6 выросла очень сильно, факт, но этот протокол “всё ещё продолжает идти на смену IPv4” (как вы знаете, адреса для последнего за это время успели закончиться раз пять или семь, как раз по числу лет в интервале ожидания моего прогноза). В общем, нельзя сказать, что совсем не сработал этот прогноз – использование IPv6, как и количество передаваемого по этой версии IP-трафика, в 2017 году относительно 2010 возросло в разы, а ещё больше – сейчас, в 2025. Однако не похоже, что прогноз сработал полностью: для dxdt.ru всё ещё нет AAAA-записи (но есть один авторитативный NS с AAAA).

Интернет сильно поменялся. Особенно, за пять лет периода 2020-2025. Но эта записка посвящена ретроспективе заметок dxdt.ru, так что обсуждение прочих изменений – оставим для других записок.

Я использую для чтения RSS полезный инструмент Tiny Tiny RSS, который работает в контейнере на внешнем сервере. И вот с некоторых пор пропал с этого сервера доступ к feeds.feedburner.com: где-то кто-то заблокировал, похоже. Из иностранных сетей доступ есть, но упомянутый сервер в российской сети, с российским IP. Проблема тут в том, что на feedburner.com “редиректит” трансляции своих корпоративных блогов Google. Непонятно зачем. А так как нынче в интернетах блокируют со всех сторон, то сразу и не скажешь – где именно оно закрыто, но возможно, что это для российских IP на стороне feedburner.com (который тоже Google, так что ничего удивительного, если так).

(Update, 28/08/2025: похоже, всё же, что вряд ли именно это – блокировка на стороне Google, по географической принадлежности IP: потому что из других россиских сетей доступ есть. Детали выяснить так и не удалось.)

С этими ИИ-LLM, “которые заменят всё и вся”, сейчас больше всего не радуют следущие моменты.

1.

Обилие сгенерированных ИИ-моделями картинок-иллюстраций на отдельных веб-страницах и на веб-сайтах вообще. Используются не только тематические ИИ-иллюстрации, но и различные фоновые изображения. Такие картинки однообразны. Обычно, содержат выраженные, и при этом одинаковые, “абсурдные элементы”: это и общая “механическая” композиция, и способ обособления “смысловых” элементов примитивным противопоставлением, крикливое оформление опорных объектов цветом, резкими углами и контурами.

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

Всё то же самое можно сказать и про сгенерированные видео, которые так же заполонили веб. Эти видеофрагменты, – особенно, сгенерированные “по фотографии”, – ужасны в своей визуальной тягучести и банальной бестолковости, но их постоянно приводят в качестве примеров типа “как было” (да!), ” как могло бы быть”.

2.

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

Как ни странно, но тексты, сгенерированные современными продвинутыми LLM, нередко узнать даже проще, чем результаты работы старинных “генераторов рефератов”: это связано с тем, что современные LLM выдают в тексте структуры “большего объёма” – оформление, построение блоков текста, все эти навязчивые, регулярные разбивки на “Почему {подставить описание}” – следует три описания “причин”, с обязательным оформлением в виде списка и “типографским” выделением фрагментов. При этом тексты написаны неплохим языком, но содержат фактические выдумки – даже не ошибки (“Not even wrong!”). Старые “генераторы рефератов” выдавали менее структурированный мусор, который больше похож на неудачный, но подлинный текст, написанный не слишком подготовленным человеком.

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

3.

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

Более того, бывает, предлагается подкорректировать и исправить ошибки в тексте, сгенерированном LLM. Смысл данного действия, что называется, тёмен – зачем пересылать текст от LLM? Запрос-то в LLM-сервис составить мог бы и сам будущий редактор этого текста. Хуже всего, что для многих и многих простых, но вполне практических, случаев LLM выдаёт подходящий текст, а всякие ложные предложения вылезают достаточно внезапно. Из-за того, что есть “примеры правильной выдачи”, нужно тратить время на то, чтобы доказать, что это сгенерированный бред, пусть и записанный наукообразно.

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

И это вот одна из явных угроз ИИ: в какой-то момент скажут, что всякая выдача LLM является верной, и даже уточнять эту выдачу может только другая LLM, но не человек, который, как давно написано в газетах, “ничего понять не сможет”.

Пишут про очередной фишинг с “омоглифом” в доменном имени. Там даже не просто омоглиф, а “омоглиф-лигатура”: то есть, символ, не входящий в обычный DNS-набор, подменяет сразу и косую черту, и “букву”, что позволяет построить имитацию URL в зоне booking.com (но зона там другая). Это, к сожалению, всё давно известные эффекты желания использовать Unicode там, где использовать Unicode не нужно. Я ещё в 2009 году описывал принцип построения таких фишинговых ссылок, и в той же записке привёл полностью рабочий пример с именем, имитирующим домен “проверка.рф” в зоне .РФ (самого .РФ тогда ещё не было в корневой зоне). Вообще, браузеры и другие клиенты должны выводить DNS-лейблы, записанные смешанными алфавитами, только в Punycode, латиницей, но, впрочем, это тоже полумера.