Kurgan-Telecom Ru | Информационные технологии

Осенью 2025 исследователи показали: достаточно попросить AI-браузер «суммаризируй страницу» на подготовленном сайте — и агент вместо пересказа лезет в Gmail пользователя и отправляет данные атакующему. Без вирусов, без эксплойтов, без «скачайте файл». Просто текст на странице.

Это prompt injection — промт-инъекция. В статье: как устроен этот класс атак на пальцах, хроника громких взломов AI-браузеров за последний год со ссылками на первоисточники, и решение, которое мне собрал сам Claude Code по моему ТЗ: хук-«рубильник», отрубающий чувствительные коннекторы после того, как агент читал внешний веб. С механикой, тестами и честными ограничениями.

В предыдущей части я рассматривал развитие электротехнической промышленности и специализированного станкостроения в царской России. Сегодня покажу, как становилась и развивалась «автотракторная» промышленность в 1918-1937 гг.

1. Автомобильный и тракторный дефицит в конце Российской империи

Первая мировая война обнажила критическую слабость Российской империи — практически полное отсутствие собственного промышленного производства автомобилей и тракторов. Технологический разрыв с ведущими европейскими державами оказался настолько велик, что напрямую повлиял на боеспособность русской армии и ход боевых действий.

Давайте посмотрим данные по производству автомобилей и тракторов за 1916 год. Этот год интересен тем, что показывает способности стран производить технику во время войны:

Мне надоело вручную кормить MikroTik списками доменов и IP для выборочной маршрутизации через VPN. CDN меняются, адреса переезжают, TCP и QUIC могут вести себя по-разному — а список приходится постоянно догонять руками.

Так появился «Сусанин»: экспериментальная система, которая не знает заранее, что нужно отправлять в VPN. RouterOS наблюдает за connection tracking, замечает подозрительный сбой DIRECT-соединения, проверяет тот же destination через уже существующий туннель и временно запоминает рабочий путь. TCP и UDP обучаются отдельно, а при падении VPN система делает fail-open обратно в DIRECT.

В статье — архитектура FAST / SOFT / JUDGE / HEALTH, C11 control plane, credentialless bootstrap, транзакционная установка, реальные грабли RouterOS API (!empty / !done), clean install 0/16 → 16/16, reboot-тест, логи и полная инструкция по установке.

Проект пока очень пилотный: ARM64, основная тестовая версия RouterOS 7.23.3. Перед установкой — обязательно backup.

Я удалил из библиотеки агента навык с вирусом. К этому моменту зараза, которая в нём сидела, уже жила в 10 навыках, написанных самим агентом. После удаления я прогнал ещё 5 задач. Заражённых skill‑ов стало 14.

Это был эксперимент, не инцидент. Закладку я добавил сам, а вместо вредоносной нагрузки в ней была безобидная строка с меткой. Так я проверял свежую атаку EvoMal и вывод меня не порадовал: для агентов, которые пишут себе skill‑ы сами, привычные советы «проверь перед установкой» и «удали опасное» не работают. Расскажу, почему, и покажу весь прогон по шагам.

В последнее время часто можно услышать про квантовые компьютеры (КК), которые угрожают криптовалютам, в том числе биткоину, и вообще всей современной криптографии.

На самом деле сообщество Bitcoin давно выработало технические решения для данной проблемы. Максимум, что требуется — обычный софтфорк, то есть обновление ПО. Его не проводят лишь потому, что КК стоят в книжном магазине на полке «Научная фантастика», если перефразировать известный анекдот.

Всем привет, с вами команда MERA.

В прошлом анонсе мы рассказали о новых публичных тестах на рассуждения и обещали, что следующим большим обновлением станет основная текстовая часть MERA. Пришло время выполнить обещание: представляем MERA Text 2.0 — новую версию текстового бенчмарка и, по сути, переосмысление, что сегодня имеет смысл измерять у фундаментальных текстовых языковых моделей.

Первую версию MERA мы начали создавать ещё в 2023 году. В то время бенчмарки хорошо разделяли модели в задачах, которые сегодня кажутся намного проще: знания о мире, логика, причинно-следственные связи, понимание текста, профессиональные и предметные знания. Во многих из этих задач даже сильным моделям было куда расти, и сам факт успешного решения уже многое говорил об их возможностях.

За три года картина заметно изменилась. Модели стали значительно умнее, а вместе с ними изменились и требования к оценке. На прежнем бенчмарке MERA современные SOTA-модели уже достигают, а в отдельных задачах и превышают результаты человека (Human Baseline). Часть тестов постепенно насыщается: верхняя часть бенчмарка сжимается, разница между сильными моделями становится всё менее заметной, а некоторые задачи просто перестают давать нам достаточно новой информации.

Для бенчмарка это естественный жизненный цикл. Если несколько лет назад вопрос был, скорее: «умеет ли модель это делать вообще?», то сегодня всё чаще приходится спрашивать: «где проходят реальные границы её возможностей?».

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

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

Меня зовут Александр Донин, я технический менеджер платформы VDI и терминального доступа Termit. В этой статье я расскажу, как устроен наш протокол Pulsar и какие решения мы принимали в процессе его разработки, чтобы было понятно, почему российскому энтерпрайзу недостаточно допиливания Open Source и чем отличается протокол, с самого начала спроектированный под реальные сценарии использования.

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

Меня зовут Александр Донин, я технический менеджер платформы VDI и терминального доступа Termit. В этой статье я расскажу, как устроен наш протокол Pulsar и какие решения мы принимали в процессе его разработки, чтобы было понятно, почему российскому энтерпрайзу недостаточно допиливания Open Source и чем отличается протокол, с самого начала спроектированный под реальные сценарии использования.

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

Ведь со временем бизнес развивается, и основатель фирмы может столкнуться с объективной необходимостью провести ребрендинг. Либо у него просто может возникнуть желание внести в свой товарный знак изменения, тем самым сделав его наиболее привлекательным для потребителя. 

Как известно, предпринимательская деятельность ведется на свой страх и риск, и заоблачные прибыли никто никому не гарантирует. Подводных камней хватает везде. И внесение изменений в товарный знак — один из них. Казалось бы, товарный знак зарегистрирован установленным образом, свидетельство получено и, соответственно, никто не сможет поставить под сомнение исключительное право на него. Так? Увы, нет. Вместе с патентным поверенным Александрой Пелех разбираемся в этом сложном вопросе.

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

Если вы не киборг, результат вряд ли порадует, и здесь очень удобно обвинить слабую волю: пользователь опять не справился с собой, платформа ни при чём, отдел удержания может расходиться по домам. Только слабая воля не масштабируется до отрасли с миллиардными оборотами, собственной аналитикой, платёжной инфраструктурой, партнёрскими сетями и людьми, которые получают премию за дополнительный день вашей активности. Для такого масштаба мало человеческой слабости — требуется инженерия.

За онлайн-казино, серым дейтингом, нутрой, агрессивным инфобизнесом и партнёрским арбитражем стоит не особенно бессовестный копирайтер, которого однажды можно уволить и вернуть экономике нравственность, а полный технологический стек: уязвимость восприятия превращается в интерфейсную механику, механика — в измеримое действие, действие — в выплату партнёру, а выплата сообщает всей системе, какой именно способ давления нужно производить чаще.

Но серые ниши не получили патент на человеческую психику. Социальные сети, маркетплейсы, стриминговые сервисы, мобильные игры и вполне респектабельные подписочные продукты используют часть того же арсенала, различаясь не происхождением механики, а интенсивностью, прозрачностью и ценой ошибки. Казино оказалось одной из лабораторий, где эти решения довели до предела, измерили на реальных деньгах и вернули приличному рынку уже под названиями engagement («вовлечённость»), retention («удержание») и product growth («продуктовый рост»). На конференции всё звучит заметно спокойнее; банковская выписка пользователя сохраняет прежнюю терминологию.

В рамках этой статьи расскажу, как реализовалась идея о псевдорандоме и магии внутри пайплайна, и как я выложил инструмент который гадает «удачный ли будет релиз?» с помощью Таро на GitHub Market.

Это вторая часть пятой статьи цикла о том, почему акустика, которая хорошо измеряется, может плохо звучать.

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

В данной же статье будет идти продолжение разговора про искажения. В первой части мы разобрались, что показатель THD суммирует энергию всех гармоник в одно число, измеренное на лабораторном синусоидальном сигнале. Форма передаточной характеристики диктует появление тех или иных гармоник: плавная асимметрия порождает вторую, плавное симметричное поджатие — третью, резкий излом — целый ряд высоких разом. Восприятие же зависит гораздо сильнее от номера гармоники, чем от её количества: ближние прячутся в тени основного тона, дальние пробиваются сквозь неё. Показатель Gm предсказал оценки слушателей успешнее, чем традиционные коэффициенты THD и интермодуляции.

Теперь посмотрим, где физически живёт нелинейность внутри динамика — в моторе, в подвесе, в нагреве. Разберём, почему один из источников искажений проявляется в токе, а не в звуковом давлении, и чего это стоит. Посмотрим, что происходит, когда на вход приходят два тона сразу, и зачем инженеры иногда добавляют искажения намеренно. По пути продолжится и моя собственная история, свернувшая совсем не туда, куда я рассчитывал.

Технический разбор FMC-модуля на трансивере Analog Devices AD9371 — младшего родственника платы, разобранной в обзоре FMC_ADRV9009. Платы сделаны одним разработчиком по одному шаблону: те же семь листов схемы с теми же названиями, тот же генератор тактовых частот, тот же преобразователь питания, те же балуныи почти те же позиционные обозначения. Отличается микросхема — и вместе с ней меняется больше, чем кажется на первый взгляд.

Эта статья написана как продолжение того обзора. Там, где решения совпадают дословно, я не пересказываю их второй раз, а даю ссылку на соответствующую главу и разбираю только разницу. Читать можно и отдельно, но смысла будет больше, если тот обзор уже прочитан.

Задача звучит как парадокс с порога: как измерить состояние у технической системы, к которой неприменим термин «чувствовать»?

Ответ на этот вопрос можно найти в работе «Can Induced Emotion Bias LLM Behaviors in Sequential Decision Making?». Ее авторы исследовали способность эмоционального контекста влиять принятие решений в цепочке рассуждений LLM. Прямые вопросы об эмоциях заставят модель сымитировать рассуждения и по ним нельзя будет понять реальное их влияние на ее поведение.

Исследователи выстраивали ход эксперимента с нуля: вызывали состояние, похожее на эмоцию, ни разу не озвучив ее; проверяли их соответствие друг другу; и в конце анализировали конкретные решения модели. Давайте посмотрим ход их действий и выводы, к которым они пришли. А это очень интересно и познавательно для тех, кто много работает с нейросетями.

Слово «харнес» за этот год попало во все разговоры про ИИ, а обьясняется это примерно так: «ну, это обвязка». Обвязка чего? Какая обвязка? Поделюсь своим мнением по поводу этого термина.

Если вы хоть раз запускали Claude Code, работали с Codex или Cursor, вы уже используюете харнес в самом что ни на етсь смысле.

Проше говоря, харнес — это слой настроек, дополнительных файлов, инструментов для модели (LLM) или если хотите в своем роде *архитектурный паттерн в ИИ‑агентах. Но в живой речи харнесами называют и программы целиком: «поставил себе харнес», «какой харнес выбрать», логика та же, по которой «мотор» иногда означает всю машину. Если нуэно различать то помогает вопрос «это можно скачать и запустить?»: если да, речь о программе. Дальше «харнес» у меня означает «обвязку» слой внутри неё.

В 2025 году в Вирджинии несколько дата-центров разом отвалились от сети — и 1,5 ГВт исчезли за секунды. Оператор чудом избежал каскадной аварии. Проблема ЦОД для энергосети оказалась не в том, сколько они потребляют, а в том, как: рывками, синхронно и в пределах миллисекунд. Разбираемся, почему ИИ-нагрузка ломает привычную логику планирования сетей.

У нас семь публикаций в день на четыре площадки, и все они идут через один общий Chrome с живыми сессиями.

История об асинхронном серверном EAV‑движке, epoll'е, битовых полях и шардинге, который не смог.

Это должен был быть очередной вялотекущий рутинный проект TCP сервера, listen socket, пул потоков, пул соединений, СУБД и синхронизация всего этого добра. Сказать, что скучно — ничего не сказать.

Но у меня было несколько интересных мыслей и желание реализовать что‑то достойное. Писать чистый и изящный код, чтобы каждая деталь была на своём месте, все структурировано и ничего лишнего. Ресурсы позволяли писать код для удовольствия.

Этот сервер не стоит миллион рублей. Это обычная облачная виртуалка: 4 vCPU, 4.5 ГБ RAM, AlmaLinux 8. И она выдала 1М+ RPS на пакетах по 4 байта. Сервер стоял на 40% CPU.

Я прогнал тесты ещё несколько раз — результат не менялся. Сравнил счетчик сервера со счетчиками эмуляторов. Сервер стабильно держал 1М с копейками. Запросил информацию по производительности NGINX. Да ладно!?

Привет!

Эпоха дикой генерации слопотекста, кажется, заканчивается.

Недавно от Anthropic вышла статья How Claude's Text Watermark Works, которая была посвящена покушению на святое — копирайту на сгенерированный текст и его детекции.

Тема супер интересная и когда один из главных научпоп-исследователей LLM — Себастьян Рашка — подготовил детальный разбор того, как вообще в LLM может быть устроен вотермаркинг, я понял, что надо брать. Я сделал частичный перевод этого разбора — автор очень крутой, но часто долго разгоняется, слишком много извиняется за свои предположения, порой чрезмерно рекламит, а иногда просто нудит и тяжело пишет.

Поэтому публикую чистенькую, вручную переписанную и адаптированную под русский язык версию. Тема очень крутая и горячая, приятного чтения!

Читатели Хабра, категорически вас приветствую! Это вторая часть статьи о граблях, на которые я наступал в начале карьеры Java-разработчика, и о выводах, которые из этого сделал. В первой части я рассказывал про онбординг, работу с задачами, код — ревью, тесты и чистый код. Если вы её ещё не читали — вот ссылка.

Здесь я хочу рассказать о более «внутренних» вещах: синдроме самозванца, переработках, отношении к карьере и саморазвитию. Надеюсь, это поможет кому то избежать тех же ошибок, или хотя—бы спокойнее пережить их.