IT

🎶GPT-Red: секретная разработка OpenAI для автоматического взлома нейросетей OpenAI разработала специальную модель GPT-Red, заточенную под автопоиск уязвимостей и пробой защиты в ИИ-системах. Вместо ручного подбора джейлбрейков силами людей-исследователей, алгоритм использует метод самоигры: непрерывно атакует защитные модели, анализирует их реакцию, меняет тактику и генерирует изощренные сценарии косвенного внедрения команд. ⚡️В боевых тестах GPT-Red успешно обходила блокировки в 84% случаев, тогда как живые редтимеры смогли пробить защиту лишь в 13%. Модель с легкостью находила бреши во всех версиях систем вплоть до GPT-5.5. В одном из экспериментов она атаковала автономного ИИ-агента, управлявшего офисным вендинговым автоматом: заставила обнулить цены на элитный товар, сбила чужие заказы и оформила покупки за копейки. OpenAI категорически отказывается выпускать GPT-Red в открытый доступ. Модель обучена исключительно вредоносным приемам и используется как закрытый внутренний полигон. Весь сгенерированный массив атак уже направили на дообучение серийной модели GPT-5.6 Sol, сделав её устойчивость к инъекциям в шесть раз выше. Защитить нейросеть от взлома теперь может только другая нейросеть. 🦔 CyberYozh

TP-Link нашла две уязвимости в умных камерах Kasa EC70 v4 и EC71 v4, которые позволяют любому в той же локальной сети перехватить учётные данные администратора и вытащить геолокацию устройства. Главная дыра, CVE-2026-9770 на 8,6 балла по CVSS v4.0, сидит в зашитом криптографическом ключе внутри прошивки. Он один на все устройства. Взломщик в той же сети проводит MITM-атаку, перехватывает трафик между камерой и её веб-интерфейсом и добирается до пароля админа. Вскрыв одну камеру, он получает метод для всех остальных. Вторая уязвимость, CVE-2026-13230 на 5,3 балла, живёт в механизме локального обнаружения камеры. Функция отвечает на запросы без всякой аутентификации, потому что нужна для сопряжения и настройки сети. Хакер шлёт специально сформированный запрос и получает геолокацию устройства без единого клика от пользователя. Камера наблюдения сама докладывает, где именно она стоит. TP-Link уже выпустила заплатки. Для EC70 v4 обе дыры закрыты в прошивке 2.4.0 Build 20260520, а для EC71 v4 это версия 2.4.1 Build 20260621. Компания советует немедленно обновить прошивку через официальные страницы поддержки и подтянуть мобильное приложение до совместимой версии.

​​Harness Handbook: Making Evolving Agent Harnesses Readable, Navigable, and Editable Способности агента определяются не только базовой моделью, но и его harness — кодом, который собирает промпты, управляет состоянием, вызывает инструменты и крутит control loop. Под новые модели, API и требования harness приходится постоянно дорабатывать, но перед любой правкой нужно сначала найти все места в коде, реализующие нужное поведение. Авторы называют это behavior localization и считают главным узким местом в эволюции harness: запросы формулируются в терминах поведения, а репозиторий устроен по файлам и функциям, и именно этот разрыв всё усложняет. Решение — Harness Handbook, представление кодовой базы, организованное вокруг поведения, а не структуры файлов. Это трёхуровневое дерево (L1 — обзор системы, L2 — стадии и компоненты, L3 — записи со ссылками на конкретный исходник) плюс state-register view для состояния, разделяемого между стадиями. Строится автоматически: статический анализ через tree-sitter без LLM → раскладка по стадиям через proposer-reviewer loop → синтез дерева. При модификации агент идёт сверху вниз через Behavior-Guided Progressive Disclosure (BGPD): от архитектуры к нужным стадиям и конкретным местам в коде, а потом сверяет кандидатов с текущим исходником. Отдельная полезная деталь — resynchronization: после правок handbook инкрементально обновляет только затронутые части, а ссылки, которые больше не резолвятся, помечает как stale, вместо того чтобы молча указывать на неверный код. Проверяли на двух open-source harness'ах (Terminus-2 и Codex), 60 запросов на модификацию, планировщик — DeepSeek-V4-Pro, качество планов оценивали три LLM-судьи: — win rate по качеству плана: 45.6% против 26.7% на Terminus-2 и 38.3% против 28.3% на Codex — и всё это при меньшем расходе токенов планировщика: −12.7% на Codex и −8.6% на Terminus-2 — по локализации все 24 сравнения recall/precision/F1 в пользу handbook, прирост F1 от +5.0 до +18.8 — слабый планировщик с handbook подбирается к локализации более сильных моделей (GPT-5.5, Claude Opus 4.8) и заметно реже промахивается мимо нужного кода целиком Paper Code Project Мои обзоры: Personal blog Medium Linkedin #paperreview

Подключение Яндекс.Метрики и Яндекс.Вебмастер к lovarus.ru одним кликом. Вот одна из причин, почему нужно выкатывать продукт как можно раньше и давать тестить реальным пользователям. Я и не думал, что ручное добавление Яндекс.Метрики приведет один из проектов к тому, что он перестанет собираться, и это станет блокером к публикации. Чтобы контролировать этот процесс, я решил, сделать полную нативную интеграцию с сервисами Яндекса по API. Теперь подключить Яндекс.Метрику к своему сайту в Lovarus, можно одним кликом, и это не фича из моего воображения, а реальный запрос пользователя. Пока тестирую на dev стенде, скоро выкачу в прод.

Легенда о хардкоре: Duke Nukem 3D, Watcom и FreeBSD Когда-то подросток из сибирских краёв разглядел слово «Watcom» в EXE-файле любимой стрелялки и с тех пор мечтал дорваться до легендарного компилятора, на котором собирали Doom и Duke Nukem 3D. Спустя почти 30 лет мечта дошла до логического хардкора. Собрать OpenWatcom из исходников под FreeBSD, платформу, для которой готовых сборок нет, а потом этим компилятором собрать саму игру из исходников 2003 года. Компилятор собрался, игра собралась, заветный EXE появился. А потом намертво повесил эмулятор. Пошли в ход замедление процессора, отключение звука, смена расширителя памяти, готовый билд под Linux, откат к оригинальным исходникам. Оригинал работал без проблем, а собственноручно собранная версия падала стабильно. Виновником в итоге оказался один файл. Разберёмся, почему двух тысяч строк ассемблера хватило, чтобы обрушить всю затею.

The Elder Scrolls 6 всё ещё в разработке Bethesda решила немного успокоить фанатов после недавних сокращений в Xbox. В студии заявили, что The Elder Scrolls 6 «уже на пути», находится там, где и должна быть по плану, а команда довольна тем, как игра выглядит, и играет в неё каждый день. Звучит красиво, хотя после фразы «мы играем каждый день» у фанатов Skyrim наверняка нервно дёрнулся глаз. Главное заявление: The Elder Scrolls 6 сейчас является основным фокусом Bethesda Game Studios. По словам студии, над новой частью работает большая часть команды. Bethesda также напомнила, что Skyrim разошёлся тиражом более 65 миллионов копий, а игроки продолжают возвращаться в него спустя 15 лет. Но студия признаёт, что ожидание сиквела уже стало очень долгим. И это мягко сказано, потому что игру анонсировали ещё 8 лет назад. Повод для беспокойства появился после сообщений, что из команды The Elder Scrolls 6 могли уволить «ключевых» сотрудников, а настроение внутри студии сильно просело. При этом Microsoft объясняла сокращения желанием сосредоточиться на самых сильных брендах Xbox. The Elder Scrolls как раз один из таких брендов, поэтому ситуация выглядит немного странно. Вроде бы фокусируемся на главном, но людей всё равно режем. Ещё Bethesda подтвердила, что The Elder Scrolls 6 создаётся на Creation Engine 3. На нём же будет работать и Fallout 5. Кроме того, Zenimax Online Studios, известная по The Elder Scrolls Online, будет теснее сотрудничать с Bethesda по франшизе. Todd Howard объяснил, что компания решила рассказать о планах чуть больше, чтобы игроки понимали, куда всё движется. Но полноценный показ TES6, похоже, всё ещё где то там, за горами Тамриэля. Рядом с обещаниями, надеждой и очередным переизданием Skyrim. #новости | Telegram | YouTube | чат

💻 Что такое Command Injection? Представьте, что веб-приложение умеет выполнять команды операционной системы. Например: — проверить доступность сервера; — обработать файл; — получить информацию о системе. Само по себе это не проблема. Проблема возникает тогда, когда приложение начинает выполнять пользовательский ввод без должной проверки.

📌 Command Injection — это уязвимость, при которой злоумышленник может добиться выполнения произвольных команд операционной системы через веб-приложение. Другими словами, вместо ожидаемой команды приложение может выполнить совершенно другую.

🧠 Где это встречается? Чаще всего в функциях, которые взаимодействуют с операционной системой: — диагностика сети; — работа с файлами; — архивирование; — обработка изображений; — резервное копирование; — различные административные панели. 💀 Чем это опасно? Если приложение уязвимо, последствия могут быть крайне серьёзными: — выполнение произвольных команд на сервере; — чтение или изменение файлов; — получение конфиденциальной информации; — загрузка вредоносного ПО; — полный захват сервера при наличии дополнительных условий. Именно поэтому Command Injection считается одной из наиболее опасных веб-уязвимостей. 🛡 Как защититься? Основные рекомендации: — не передавать пользовательский ввод напрямую в системные команды; — использовать безопасные функции и библиотеки вместо вызова команд оболочки; — проверять и ограничивать входные данные; — запускать приложения с минимально необходимыми привилегиями. 📌 Хотя сегодня многие современные фреймворки помогают избежать подобных ошибок, Command Injection по-прежнему встречается в административных панелях, устаревших веб-приложениях и самописных сервисах. Поэтому при тестировании веб-приложений всегда стоит обращать внимание на функционал, который взаимодействует с операционной системой. #web #owasp #commandinjection #pentest #websecurity

Иммутабельная денормализация Изучение баз данных всегда сопровождается понятием нормализации, а конкретно первыми тремя формами, которые задают нам ограничения, помогающие правильно разложить все по таблицам. И это действительно база, без которой нормально работать не получится. Но есть, как обычно, нюансы. В реальных проектах выясняется, что нормализованные данные сложно соединять и выбирать. При глубоком уровне зависимостей, чтобы добраться до внешней сущности, нужно либо соединять 5 таблиц, либо делать 5 запросов. Пример из Хекслета. У нас есть программа обучения, которая состоит из модулей, в которые входят темы которые состоят из уроков, которые состоят из юнитов (теория, практика, тесты). На это все накручено много логики по прогрессу и отображению. В такой структуре, вопросы типа "какой урок следующий по порядку?" заставляют поломать голову. В таких ситуациях мы начинаем денормализацию данных. В основном она сводится к добавлению внешних ключей на косвенно связанные сущности, например, урок связан с программой обучения через модуль. Здесь мы добавляем ключ на программу прямо из урока, что позволяет выполнять запросы на уроки одной программы без необходимости соединять таблицы. В принципе это довольно базовая концепция с которой знакомы большинство разработчиков, но дальше начинается самое интересное. Как только мы делаем денормализацию, то сразу упираемся в необходимость синхронизировать данные. Если поменялось в одном месте, надо не забыть поменять и в другом месте. Это цена денормализации и ее надо платить. > Кстати есть такой концепт как синхронизирующие триггеры, которые вешают только для того, чтобы синхронизировать подобные данные. Когда-то я его активно использовал, но сейчас не стал бы Но есть и альтернативный подход, который иногда работает лучше. Вместо того, чтобы синхронизировать денормализованные данные, мы можем пересмотреть саму систему и сделать данные иммутабельными (неизменяемыми), чтобы их не нужно было синхронизировать. Например в том же примере с уроками, мы сделали так, что урок принадлежит одной программе и не может перемещаться между программами. А это значит, что мы можем записать в урок все внешние ключи, которые никогда не поменяются. В таком случае цена денормализации это занятое место ключами, чем обычно можно пренебречь. А что касается бизнес-логики? Да, такой подход работает не всегда, но, как показала практика, его можно использовать намного чаще чем кажется. Например в нашем случае это даже наоборот хорошо, иначе получается ситуация, что при переносе урока нужно переносить прогресс, что значительно усложняет логику и создает странное впечатление, когда в середине программы вдруг появляются пройденные уроки. При этом сама процедура довольно редкая, поэтому если кому-то придется пройти два раза один и тот же урок (перенос в нашем случае это копирование), то ничего страшного не случается. Но есть места где без синхронизации данных не обойтись никак. В основном это касается статусов, они могут меняться и за ними нужно следить. Telegram | YouTube | AI Клуб

😈 В прошлом месяце мы обзавелись штрафами за несоблюдение требований к рекомендательным технологиям (до 2,8 млн). На фоне новостей про запрет иностранных форм авторизации (Google etc) это прошло незаметно - но я говорил о том, что это намного с моей точки зрения важнее и критичнее А как вообще легально оформить применение рекомендательных технологий? Давайте разберемся. Рекомендательные технологии - это любые алгоритмы, которые собирают, анализируют и используют сведения о ваших действиях на сайте или в приложении, чтобы предложить вам что-то «подходящее» . Подборка товаров «с этим товаром покупают», рекомендации похожих курсов, лента новостей, сформированная под вас - все это рекомендательные технологии. И да, даже если вы просто показываете пользователю блок «популярное» или «похожие товары» - теоретически это уже считается . Ключевой критерий - не размер бизнеса, а сам факт использования . Что должен сделать бизнес (чтобы на штраф не попасть) 1) Разместить уведомление на ресурсе. Должна быть фраза: «На информационном ресурсе применяются рекомендательные технологии» . Без вариантов, именно так. Она должна быть общедоступной, бесплатной, без регистрации и смс, и не накладываться на другие элементы 2) Сделать отдельную страницу с правилами. Под уведомлением должна быть ссылка на страницу, где указано: «На информационном ресурсе при применении информационных технологий предоставления информации осуществляется сбор, систематизация и анализ сведений, относящихся к предпочтениям пользователей сети "Интернет", находящихся на территории Российской Федерации» . На этой же странице должны быть: - правила применения рекомендательных технологий (как собираете данные, на основании чего формируете рекомендации) ; - наименование организации и адрес электронной почты для юридически значимых сообщений . 3) Назначить ответственного (как с ПДн за обработку) Закон этого не требует прямо, но лучше определить внутри компании человека или подразделение, которые будут координировать вопросы с Роскомнадзором. Чаще всего это тот же сотрудник, что отвечает за обработку персональных данных. Если на это все забить - случиться может следующее Роскомнадзор сначала запросит информацию и доступ к техническим средствам. Потом направит требование прекратить нарушения. Потом - требование прекратить использование рекомендательных технологий. Если и это не выполнено - доступ к ресурсу заблокируют . Штрафы тоже есть. Но главный риск не в деньгах, а в том, что сайт или приложение перестанут работать для пользователей из РФ. В общем всем рекомендую проверить - а есть ли у вас на сайте или в приложении блоки типа «рекомендуем», «похожие», «с этим товаром покупают», «популярное». Если да - вы используете рекомендательные технологии. И тогда вам нужно сделать все уведомления, правила и контакты 🤝

Как русские «Героев» спасали: история разработки Heroes of Might and Magic V 2003-й. Студия New World Computing, подарившая миру первые четыре части, закрывается вместе с обанкротившейся 3DO. Права на культовую серию за смешные 1,3 миллиона долларов забирает Ubisoft и делает то, чего фанаты не простят ещё долго. Отдаёт «Героев» московской студии Nival и выбрасывает в мусорку начатые наработки, чтобы перезапустить всё с нуля в полном 3D. Осенью 2005-го закрытая бета всех напугала. Багов было больше, чем юнитов на карте, баланса не существовало, а релиз стоял на март. И тогда крупнейшие фан-сайты объединились и потребовали перенести дату, отправив издателю коллективное «не смейте выпускать недоделку». Самое удивительное, что это сработало. Выясним, как вой фанатов до эры твиттера заставил крупного издателя сдвинуть планы.

Мировоззрение людей, которые воплотили переход человечества на новый техноуклад (оргструктура, культура взаимодействия, тактика и стратегия) BBN/RAND/ARPA/IPTO/SRI/PARC 1-10/100 1. J.C.R. Licklider 2. Ivan Sutherland 3. Bob Taylor 4. Larry Roberts 5. Frank Heart 6. John McCarthy 7. Leo Beranek 8. Steve Crocker 9. Wesley Clark 10. Gary Starkweather следующий переход вот-вот случится и совсем не в той области, в которой большинство ожидает, а в той, что уже существует в нескольких точках "возгорания", но все еще ниже радаров а вообще контент совсем на грани моих способностей, я примерно 1 час лекций мог осилить за 2-3, через усилие как на мат олимпиаде и как побочка теперь выступления фаундеров и партнеров из YC кажутся щенячьим писком PS Вывод после первых 10 часов погружения: c 1969 в ИТ не случилось ни одной существенной инновации (0→1)