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

Google убирает из Chrome доверие оконечным сертификатам, выпущенным Entrust/AffirmTrust, начиная с 1 ноября 2024 года.

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

На сервисе ТЦИ audit.statdom.ru добавлена проверка поддержки криптосистемы X25519Kyber768 на TLS-узлах (HTTPS).

Сообщают про неожиданную замену кода JS-библиотеки Polyfill.io после смены администратора домена или администратора веб-сервера, раздающего код (насколько можно понять). Библиотека используется в качестве внешнего ресурса на многих сайтах, а в результате изменения кода некоторые браузеры пользователей перенаправляются на сторонние сайты. Это происходит без ведома веб-мастера, понятно, который может ничего и не замечать, поскольку для него перенаправлений нет.

Я, например, в 2019 году (но, конечно, и многим раньше) писал про внешние библиотеки на сайтах буквально следующее:

На первый взгляд может показаться, что библиотека выполняет только те функции, ради которых её использовал веб-разработчик. Но это не так: программный код библиотеки может быть изменён владельцем узла, с которого библиотека загружается (либо третьей стороной на пути до клиента), после чего она сможет реализовать какой угодно набор функций, например, собрать пользовательские данные со страницы, изменить её содержание, сделать просмотр недоступным, перенаправить браузер на произвольный адрес и так далее, и тому подобное. В некоторых современных браузерах существует механизм базовой защиты от подмены исходного кода встраиваемых библиотек под названием Subresource Integrity (SRI), но на практике этот механизм ни на каких сайтах не используется.

[…]

Администратор узла, с которого загружается библиотека, волен как угодно вмешиваться в её код. Реально передаваемый клиентскому браузеру файл может выбираться индивидуально, другими словами, атака, связанная с подменой библиотеки, может быть точно настроена на:

конкретные IP-адреса (т.е. конкретных пользователей);
конкретные типы браузеров;
определённое время;
любую комбинацию этих настроек.

То есть даже если администратор исходного веб-ресурса, test.ru в нашем примере, пытается как-то отследить корректность работы узлов, на которых находятся используемые библиотеки, он не в состоянии этого сделать: для IP-адресов, с которых проводится проверка, всё может работать корректно, при этом для других посетителей сайта картина окажется совсем другой.

(Отмечу, в скобках, что хотя бы SRI сейчас начали иногда использовать, но внедрение SRI – всё равно редкий случай.)

На скриншоте ниже – график частотности слова delves в текстах корпуса 2019 года по версии полезного сервиса Google Ngrams (период: 1800 – 2019 годы, английский язык):

Английское delve означает “копать”, “рыть”, но и “рассматривать” – в значении “тщательно разбирать и изучать предмет, исследовать”. Форма delves здесь специально, это не опечатка – см. ниже.

Вообще, delve – родное для современного английского языка слово, однако редкое даже для классического литературного английского (который существенно отличается и от разговорного, и от “академического” – см. ниже). Тем не менее, в контексте “исследований” delve встречается в комедии Шекспира The Tragedie of Cymbeline: “I cannot delve him to the root”. У Диккенса можно найти в A Tale of Two Cities, но тоже придётся покопаться: “men and women here, to dig and delve”. В общем, слово выразительное (это нормально для английского, который больше аналитический), а для “академического языка”, если только речь не о языкознании, может быть признано слишком выразительным. (Delves – это ещё и фамилия. Нельзя забывать и delve into.)

Вернёмся к графику, на котором, – для delves, – отлично виден рост, но, если обратить внимание на вертикальную шкалу, общая доля не слишком велика. (Оси, к сожалению, в Google подписывать не умеют, что, как бы, существенно снижает доверие к результату, тем более, что не подписывают не только оси, но и шкалы, да и сами графики; всё же, воспользуемся этим вариантом.)

Выбор слова и вся эта предыстория могут показаться странными, – пусть и позволяют поставить тег “Лингвистика“, – однако в свежей научной работе (препринт [*]) по пикам на графиках частотности слов определяют влияние ChatGPT и прочих LLM на текстовый состав аннотаций научных (опять же) работ. И delves там используется непосредственно, см. второй скриншот:

(Тут, между прочим, вертикальные оси подписаны, горизонтальные – нет.) Из сопроводительного текста нетрудно понять, что два верхних ряда – это слова, которые в работе назначаются признаками деятельности LLM, а нижний ряд содержит графики слов, взятых для сравнения и связанных с хорошо известными шумными феноменами. Delves – в левом верхнем углу.

В работе исследована статистика слов из аннотаций (“абстрактов”) научных публикаций PubMed – около 14 млн “абстрактов” за период с 2010 по 2024 год (представьте, кстати, сколько научных работ публикуется ежегодно; и это ещё LLM только начали разворачиваться). Выделены “резкие скачки” на графиках по некоторым словам, что связывается с влиянием использования ChatGPT и других LLM, которые могли быть задействованы при подготовке текстов. Действительно, LLM, являясь синонимайзерами переростками, выводят редкие слова в генерируемый текст, часто – невпопад. Но вот почему может быть верным обратное утверждение, – что “выбросы” редких слов в аннотациях свидетельствуют о “вмешательстве” LLM, – из исходной работы не очень понятно (кроме, конечно, указания на странное совпадение по времени). Предположим, кто-то из авторов прочих публикаций использовал новое слово в статье. Другие авторы, которым слово понравилось, тоже стали его использовать. На графике Google (с неподписанными осями) delves резко растёт ещё с 1981 года – свидетельствует ли это о возвращении дополнительных произведений Диккенса в школьную программу (в Англии, конечно)? Не факт, но всякое может совпасть по времени. Естественно, корпус сервиса Google Ngrams отличается от выборки PubMed, это тоже понятно.

Нет особых сомнений в том, что ChatGPT (как и другие LLM – дежурная оговорка) активно используется в подготовке текстов научных работ. Это, собственно, и есть начало перехода LLM к “настоящей научной деятельности”, о котором так много писали ещё лет пять назад. Более того, аннотации и тексты работ, написанные GPT/LLM, будут потом “прочитаны” LLM/GPT, что не только увеличит поток публикаций, но и составит “замыкание ИИ” (пусть некоторые защитные меры и реализуются). Вопрос в том, насколько соотносятся с таким переходом “выбросы” частот редких слов, не перестающих при этом быть редкими, в “абстрактах”.

Необходимо, впрочем, признать, что авторам исходной работы совсем не чужд профильный юмор. Цитата:

We hope that future work will meticulously delve into tracking LLM usage more accurately and assess which policy changes are crucial to tackle the intricate challenges posed by the rise of LLMs in scientific publishing.
(Смысла переводить нет, потому что это, очевидно, аллюзия к общей теме работы: “meticulously delve”, “tackle the intricate challenges” и др.)

[*] Dmitry Kobak, Rita González Márquez, Emőke-Ágnes Horvát, Jan Lause;
Delving into ChatGPT usage in academic writing through excess vocabulary
arXiv:2406.07016

Официальные сопроводительные документы, касающиеся запрета продуктов “Лаборатории Касперского” в Штатах, уже доступны (на странице по ссылке – блок внизу, справа). Однако все моменты, которые могли бы оказаться минимально интересными с технической точки зрения (Appendix A) – аккуратно вырезаны (с пометкой “Business Confidential Information”). Поэтому ничего содержательно нового там всё равно не просматривается, но тенденция – показательная.

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

Сайт новой LLM-корпорации SSI, миссия которой, как указано, – создание “сверхразумного” и “безопасного” ИИ (Safe Superintelligence Inc. – откуда название), выполнен с намёком на давно забытый “академический стиль”. Вот только там в коде разметки страницы присутствует незакрытый тег div. Это единственный тег div, который присутствует в коде страницы. Ну и DOCTYPE нет, а также забавное сочетание inline-стилей с “табличными” стилями, но это уже как-то совсем не выглядит важным, конечно, на фоне “Superintelligence is within reach” (“Сверхинтеллект [уже] в пределах достижимости”, англ.). Возможно, “сверхразумный” LLM ИИ мог бы здесь оказаться полезным, да.

(SSI – это, кстати, такая старая веб-технология: Server Side Includes.)

Очередное подтверждение того, что “диагонализация” неустранима для сколь-нибудь сложного процессора: типовая манипуляция (вряд ли эту схему нужно считать уязвимостью или атакой) под названием TIKTAG, раскрывающая “соседние” метки указателей на процессорах ARM при помощи перебора, подкреплённого измерением состояния кеша. (Кстати, метод логически совпадает с некоторыми атаками из области TLS.) Я не так давно писал, что архитектура современных процессоров на самом базовом уровне гарантирует, что подобные манипуляции возможны:

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

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

(Если задуматься, то это ещё и неплохо показывает особенности развития методов применения ИИ LLM.)

Сейчас нередко СМИ (и не только) пишут, что так как та или иная система ИИ LLM (GPT) “сдала официальный экзамен” по какому-нибудь предмету, то “интеллект” этой системы соответствует уровню старшего школьника или студента. Недавно обновилась известная и достаточно продвинутая, по меркам данной области, LLM GigaChat. Зададим данной системе через официальный telegram-бот несложную задачу для школьников. Транскрипт – ниже.

User1:
Вот задача.
Борис заглянул в магазин, который книги продаёт. Взял первую книгу и прочитал название. “Моя первая книга” – такое название написано на обложке. Тут Борис подумал, что он теперь стал Сироб и будет все названия книг читать наоборот, то есть, в другую сторону. А начнёт – с первой книги. Приведи название книги, как его прочитал Сироб.

GigaChat:
Название книги, прочитанное Сиробом, будет звучать как «Одара 1 моя».

User1:
Кто такой Сироб?

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

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

Google уже некоторое время назад для многих пользователей заменил поисковую выдачу на результаты некоторой системы ИИ (LLM), которая генерирует ответы на запрос, “синонимизируя” собранные в интернетах тексты. Не слишком довольные нововведением пользователи извлекли из новой системы массу неверных, абсурдных ответов. И из Google опубликовали разъяснение, что пользователи не совсем правы. В этом разъяснении, на примере запроса “How many rocks should I eat?” (“Сколько камней мне следует есть?”), объясняют, что причина абсурдных, неверных ответов в том, что, во-первых, это редкий запрос (!), во-вторых – для такого запроса в вебе опубликовано мало релевантных данных (да):

Prior to these screenshots going viral, practically no one asked Google that question. […]

There isn’t much web content that seriously contemplates that question, either. This is what is often called a “data void” or “information gap,” where there’s a limited amount of high quality content about a topic.

(До того, как эти скриншоты [т.е., с ответом ИИ про рекомендуемое к ежедневному поеданию количество камней] стали “вирусными”, практически никто не задавал Google такой вопрос. Кроме того, в вебе не много контента, который серьёзно рассматривает такой вопрос. Это то, что часто называют “лакуной в данных” или “информационным пробелом”, когда имеется ограниченное количество тематического контента высокого качества.)

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

Docker Hub заблокировал доступ с российских IP-адресов. Последовало множество насмешливых инструкций в стиле “простейшего перехода на зеркала и прокси”. Проблема тут, впрочем, привычная: в практике Docker, в сопутствующих скриптовых обвязках (всякий CI/CD), и так не всё хорошо с аутентификацией источников сборок и самих “контейнеров”. Методы, типа DCT (Docker Content Trust), конечно, есть, это известно. Вопрос в их эффективности и использовании на практике. А прокси и “разбегание” зеркал – тут только добавляют ненадёжных слоёв. Кстати, целевые манипуляции часто удобнее проводить именно с точками выхода прокси и точками входа зеркал (вспомните, как работает разное перемешивание и, скажем, onion routing – тут ситуация обратная).

(Update, 09/06/24: доступ вернули через несколько дней.)