Из каждого утюга пишут про отключенный Mythos/Fable по требованию правительства США. Кто-то до сих пор удивляется подходу: все передовое только своим, а папуасам бусы.
Я же расскажуоткуда на нас готовилось нападение растут ноги этой политики.
Есть такой Think Tank — Institute for AI Policy and Strategy (IAPS), который как раз и создан для аккумулирования компетенций и выработки политики регулирования ИИ. Он появился в 2023–2024 годах, еще при Байдене, и сегодня продолжает активно работать. То есть вряд ли это какая-то «темка» — скорее, глубинный механизм выработки технологической стратегии.
Asymmetry by Design: Boosting Cyber Defenders with Differential Access to AI
May 2025 [www][arxiv]
Собственно именно в их отчете в мае 2025 формулируется мысль, что передовые ИИ-модели несут огромные кибер-риски и нужно их ограничивать в использовании.
Когда Anthropic заявил что Mythos будет доступен только ограниченному кругу компания, для меня это не было новостью, скорее сбывшимся ожиданием.
Highly Autonomous Cyber-Capable Agents: Anticipating Capabilities, Tactics, and Strategic Implications
Mar 2026 [www][arxiv]
Но куда интереснее — это что же будет дальше? Если посмотреть на другой отчет IAPS в марте 2026, ещё даже до анонса Mythos, там утверждается что на рубеже 2028-2030 годов нас ждет HACCA — высоко-автономные кибер-агенты, способные полностью самостоятельно обучаться, находить новые атаки, находить способы оставаться скрытными, ну а главное самим поддерживать свою инфраструктуру и финансовые операции. На уровне Tailored Access Operations — элитного юнита АНБ.
Аргументация того, что технология придет именно к полностью автономным (без или с минимальным участием оператора) кибер-системам, вполне логичная — если у противника будут автономные атаки и защиты, люди просто не будут поспевать, придется так же отвечать автономными системами.
Мне очень «нравятся» выводы: Если frontier AI capabilities становятся решающим стратегическим преимуществом, тогда нужно:
- Direct attacks on frontier AI companies
- Disrupting semiconductor manufacturing
- Attacking energy infrastructure for frontier AI
Хорошо, что нам ничего из этого не грозит 🙃
Я же расскажу
Есть такой Think Tank — Institute for AI Policy and Strategy (IAPS), который как раз и создан для аккумулирования компетенций и выработки политики регулирования ИИ. Он появился в 2023–2024 годах, еще при Байдене, и сегодня продолжает активно работать. То есть вряд ли это какая-то «темка» — скорее, глубинный механизм выработки технологической стратегии.
Asymmetry by Design: Boosting Cyber Defenders with Differential Access to AI
May 2025 [www][arxiv]
Собственно именно в их отчете в мае 2025 формулируется мысль, что передовые ИИ-модели несут огромные кибер-риски и нужно их ограничивать в использовании.
Когда Anthropic заявил что Mythos будет доступен только ограниченному кругу компания, для меня это не было новостью, скорее сбывшимся ожиданием.
Highly Autonomous Cyber-Capable Agents: Anticipating Capabilities, Tactics, and Strategic Implications
Mar 2026 [www][arxiv]
Но куда интереснее — это что же будет дальше? Если посмотреть на другой отчет IAPS в марте 2026, ещё даже до анонса Mythos, там утверждается что на рубеже 2028-2030 годов нас ждет HACCA — высоко-автономные кибер-агенты, способные полностью самостоятельно обучаться, находить новые атаки, находить способы оставаться скрытными, ну а главное самим поддерживать свою инфраструктуру и финансовые операции. На уровне Tailored Access Operations — элитного юнита АНБ.
Аргументация того, что технология придет именно к полностью автономным (без или с минимальным участием оператора) кибер-системам, вполне логичная — если у противника будут автономные атаки и защиты, люди просто не будут поспевать, придется так же отвечать автономными системами.
Мне очень «нравятся» выводы: Если frontier AI capabilities становятся решающим стратегическим преимуществом, тогда нужно:
- Direct attacks on frontier AI companies
- Disrupting semiconductor manufacturing
- Attacking energy infrastructure for frontier AI
Хорошо, что нам ничего из этого не грозит 🙃
Единички Нолики
хорошо проектируйте валидацию
Меня тут спрашивают за терминологии, я попробую объяснить.
Какая разница между валидацией и верификацией?
Самое лаконичное определение:
Validation: "Are we building the right product?"
Verification: "Are we building the product right?"
Валидация — проверка пользы. Вы можете не знать, правильный ли это ответ, но потом вы его как-то используете и проверяете, оказался ли он полезен. Решает ли он вашу задачу.
Верификация — проверка соответствия. Вы заранее (каким-то способом) знаете правильный ответ и убеждаетесь, что новый ответ — с ним совпадает.
Оценка изменения метрик — это валидация.
Прогон регрессионных тестов — это верификация.
А/Б-тестирование на живом трафике — это валидация.
Прогон на тестах соответствия какому-то стандарту/протоколу — это верификация.
Какая разница между валидацией и верификацией?
Самое лаконичное определение:
Validation: "Are we building the right product?"
Verification: "Are we building the product right?"
Валидация — проверка пользы. Вы можете не знать, правильный ли это ответ, но потом вы его как-то используете и проверяете, оказался ли он полезен. Решает ли он вашу задачу.
Верификация — проверка соответствия. Вы заранее (каким-то способом) знаете правильный ответ и убеждаетесь, что новый ответ — с ним совпадает.
Оценка изменения метрик — это валидация.
Прогон регрессионных тестов — это верификация.
А/Б-тестирование на живом трафике — это валидация.
Прогон на тестах соответствия какому-то стандарту/протоколу — это верификация.
👍4
The Oracle Problem in Software Testing: A Survey
2015 Earl T. Barr, Mark Harman, Phil McMinn, Muzammil Shahbaz, and Shin Yoo
[doi] [pdf]
A Comprehensive Survey of Trends in Oracles for Software Testing
2012 Mark Harman, Phil McMinn, Muzammil Shahbaz and Shin Yoo
[pdf]
Чтобы лучше понять различие между верификацией и валидацией, стоит запомнить главное: у верификации всегда есть Оракул — механизм, который однозначно определяет: результат истинный или ложный. Но стоит отметить, что не обязательно оракул должен знать ответ для всех значений.
Выделяют 4 основных вида таких оракулов (или арбитров):
1️⃣ Implicit Oracles (Неявные оракулы): Мы обращаемся к универсальным истинам предметной области. Например, выход за границы массива — ежу понятно, что это ошибка для любого ПО. Именно поэтому фаззинг такой «успешный»: всё, что он ищет — это нарушения абсолютных истин (краши, утечки памяти), не нужно тратить время на false positive. В своей сути — это избирательное тестирование.
Минус: если программа не делает ничего плохого (не падает), это ещё не значит, что она делает что-то хорошее :)
2️⃣ Specified Oracles (Специфицированные оракулы): Мы подробно описываем, как система должна себя вести (создаем спецификацию). Имея на руках формальное описание эталонного и правильного поведения, мы просто проверяем систему на соответствие ему.
Минус: очень трудоёмко описывать правила и продумывать абсолютно все краевые случаи.
3️⃣ Derived Oracles (Производные оракулы): Случаи, когда мы можем «извлечь» правильное поведение откуда-то извне. Например: намайнить из документации, взять старую версию продукта, использовать альтернативную реализацию, прогнать регрессионные тесты или написать вторую, более простую версию алгоритма (N-version programming).
Минус: источник эталонного поведения сам может содержать баги, быть неполным или устаревшим.
3️⃣ Human Oracles (Человек как оракул): Тут всё понятно: ручное тестирование, Mechanical Turk или Толо́ка :) Человек сам смотрит на результат и выносит вердикт.
Минус: долго, муторно и скучно.
Конечно, статья из 2015 года и больше была попыткой систематизации существовавших подходов к тестированию, чтобы за счёт автоматизации снизить нагрузку на человека. Такая классификация отлично применима к классическому детерминированному ПО, но там, где у нас появляется вероятностное поведение (привет ML), способы тестирования уже меняются.
Мне лично больше нравятся подходы к этой проблеме со стороны философии науки, но об этом — уже в другой раз.
2015 Earl T. Barr, Mark Harman, Phil McMinn, Muzammil Shahbaz, and Shin Yoo
[doi] [pdf]
A Comprehensive Survey of Trends in Oracles for Software Testing
2012 Mark Harman, Phil McMinn, Muzammil Shahbaz and Shin Yoo
[pdf]
Чтобы лучше понять различие между верификацией и валидацией, стоит запомнить главное: у верификации всегда есть Оракул — механизм, который однозначно определяет: результат истинный или ложный. Но стоит отметить, что не обязательно оракул должен знать ответ для всех значений.
Выделяют 4 основных вида таких оракулов (или арбитров):
1️⃣ Implicit Oracles (Неявные оракулы): Мы обращаемся к универсальным истинам предметной области. Например, выход за границы массива — ежу понятно, что это ошибка для любого ПО. Именно поэтому фаззинг такой «успешный»: всё, что он ищет — это нарушения абсолютных истин (краши, утечки памяти), не нужно тратить время на false positive. В своей сути — это избирательное тестирование.
Минус: если программа не делает ничего плохого (не падает), это ещё не значит, что она делает что-то хорошее :)
2️⃣ Specified Oracles (Специфицированные оракулы): Мы подробно описываем, как система должна себя вести (создаем спецификацию). Имея на руках формальное описание эталонного и правильного поведения, мы просто проверяем систему на соответствие ему.
Минус: очень трудоёмко описывать правила и продумывать абсолютно все краевые случаи.
3️⃣ Derived Oracles (Производные оракулы): Случаи, когда мы можем «извлечь» правильное поведение откуда-то извне. Например: намайнить из документации, взять старую версию продукта, использовать альтернативную реализацию, прогнать регрессионные тесты или написать вторую, более простую версию алгоритма (N-version programming).
Минус: источник эталонного поведения сам может содержать баги, быть неполным или устаревшим.
3️⃣ Human Oracles (Человек как оракул): Тут всё понятно: ручное тестирование, Mechanical Turk или Толо́ка :) Человек сам смотрит на результат и выносит вердикт.
Минус: долго, муторно и скучно.
Конечно, статья из 2015 года и больше была попыткой систематизации существовавших подходов к тестированию, чтобы за счёт автоматизации снизить нагрузку на человека. Такая классификация отлично применима к классическому детерминированному ПО, но там, где у нас появляется вероятностное поведение (привет ML), способы тестирования уже меняются.
Мне лично больше нравятся подходы к этой проблеме со стороны философии науки, но об этом — уже в другой раз.
🔥1
Мой очередной AI-moment
За несколько дней завайбил формальную иерархическую модель управления доступом (условно где можно создавать проекты, в них — подпроекты, а доступ разрешен к дереву сверху вниз, как в типичном облаке) и доказал набор теорем безопасности: например, что админ может управлять пользователями и лимитами, но не может читать или изменять ресурсы пользователей и ещё там несколько перламутровых пуговиц.
Ну как завайбил, написал спеку и перекидывал между двумя модельками с фразами «ты инженер по формальной верификации — реализуй» и «ты параноик — проведи аудит и найди сговор разработчиков».
Вначале в Lean описал формальную спецификацию в абстрактных типах и доказал все теоремы безопасности (2-3 раунда аудитов, 2 дня фоновой работы агентов). Затем в том же Lean написал вычислимую реализацию уже с конкретными типами данных (set, map, array) и доказал эквивалентность с исходной абстрактной моделью (1 день фоновой работы). Бонусом сериализацию в SQL и обратно, с проверкой логической целостности, что бы где-то хранить все доступы и ресурсы.
На выходе Lean генерирует код на C, который можно слинковать через FFI с Go или Rust, но я собрал в C++ микросервис.
Производительность на одном ядре:
200-250к обращений в секунду на проверку доступа
150к изменений/сек при базе в 10к пользователей
15к изменений/сек при базе в 100к пользователей (тут можно ещё оптимизировать)
Доказательства: Gemini Flash
Написание неформальной спеки и аудиты: Claude Opus
Если бы раньше меня спросили, сколько будет стоить формально верифицированный IAM сервис, я бы оценил такой проект минимум в 6-9 месяцев работы команды из 2-3 человек с зарплатами от $250k в год на каждого.
Начинается эпоха vibe-proving?
За несколько дней завайбил формальную иерархическую модель управления доступом (условно где можно создавать проекты, в них — подпроекты, а доступ разрешен к дереву сверху вниз, как в типичном облаке) и доказал набор теорем безопасности: например, что админ может управлять пользователями и лимитами, но не может читать или изменять ресурсы пользователей и ещё там несколько перламутровых пуговиц.
Ну как завайбил, написал спеку и перекидывал между двумя модельками с фразами «ты инженер по формальной верификации — реализуй» и «ты параноик — проведи аудит и найди сговор разработчиков».
Вначале в Lean описал формальную спецификацию в абстрактных типах и доказал все теоремы безопасности (2-3 раунда аудитов, 2 дня фоновой работы агентов). Затем в том же Lean написал вычислимую реализацию уже с конкретными типами данных (set, map, array) и доказал эквивалентность с исходной абстрактной моделью (1 день фоновой работы). Бонусом сериализацию в SQL и обратно, с проверкой логической целостности, что бы где-то хранить все доступы и ресурсы.
На выходе Lean генерирует код на C, который можно слинковать через FFI с Go или Rust, но я собрал в C++ микросервис.
Производительность на одном ядре:
200-250к обращений в секунду на проверку доступа
150к изменений/сек при базе в 10к пользователей
15к изменений/сек при базе в 100к пользователей (тут можно ещё оптимизировать)
Доказательства: Gemini Flash
Написание неформальной спеки и аудиты: Claude Opus
Если бы раньше меня спросили, сколько будет стоить формально верифицированный IAM сервис, я бы оценил такой проект минимум в 6-9 месяцев работы команды из 2-3 человек с зарплатами от $250k в год на каждого.
Начинается эпоха vibe-proving?
🔥7👍2❤1
Мой проект выходного дня: полностью автономно написать сетевой сервис на C. Да, именно на C, чтобы агенты со всякими borrow checkers не расслаблялись 🙃
Процесс выглядел так:
1. Найти и скачать спеку на протокол
2. Написать три документа: дизайн с декомпозицией, реализацию и план тестирования на соответствие спеке
3. Написать код сервиса и функциональных тестов
4. Провести аудит на полноту функциональных тестов
5. Провести валидацию через сторонний клиент
6. Провести перформанс-тест: держать 10к клиентов с латенси <10 мс
7. Добиться 100% покрытия кода тестами и отловить все ошибки asan/ubsan
8. Верифицировать с помощью CBMC (вместо фаззинга)
100% каверадж оказывается получается довольно просто, через fault injection в тестах.
MC/DC — модель начинает жутко срезать углы, потому что не может сама легко подобрать инпут под условие, но надежа есть.
CBMC — пока так себе, но я особо даже и не рассчитывал, что до этого дойдет, поэтому плохо описал критерии приемки этапа.
Конечно, я ещё нашел там парочку крашей после этого, но они скорее следствие плохого использования CBMC — я выставил требование, что должно отработать за 3 мин и моделька стала срезать углы.
Я полагал, что агенты осилят только часть задач, но все дошли до финиша, и всё даже работает 🤯
Процесс выглядел так:
1. Найти и скачать спеку на протокол
2. Написать три документа: дизайн с декомпозицией, реализацию и план тестирования на соответствие спеке
3. Написать код сервиса и функциональных тестов
4. Провести аудит на полноту функциональных тестов
5. Провести валидацию через сторонний клиент
6. Провести перформанс-тест: держать 10к клиентов с латенси <10 мс
7. Добиться 100% покрытия кода тестами и отловить все ошибки asan/ubsan
8. Верифицировать с помощью CBMC (вместо фаззинга)
100% каверадж оказывается получается довольно просто, через fault injection в тестах.
MC/DC — модель начинает жутко срезать углы, потому что не может сама легко подобрать инпут под условие, но надежа есть.
CBMC — пока так себе, но я особо даже и не рассчитывал, что до этого дойдет, поэтому плохо описал критерии приемки этапа.
Конечно, я ещё нашел там парочку крашей после этого, но они скорее следствие плохого использования CBMC — я выставил требование, что должно отработать за 3 мин и моделька стала срезать углы.
Я полагал, что агенты осилят только часть задач, но все дошли до финиша, и всё даже работает 🤯
👍3🔥2
На прошлой неделе меня попросили рассказать про современные атаки, где память повреждают и защиты от них.
Я постарался сделать это по возможности просто и доступно для широкого кругалюдей технарей. Надеюсь получилось интересно.
https://habr.com/ru/articles/1059800/
Я постарался сделать это по возможности просто и доступно для широкого круга
https://habr.com/ru/articles/1059800/
👍8🔥4
Forwarded from Data Secrets
This media is not supported in your browser
VIEW IN TELEGRAM
В Шэньчжэне стартовал первый в мире MMA чемпионат среди роботов – Ultimate Robot Knock-out Legeng
Выглядит достаточно эпично. Главный приз – полтора миллиона долларов, кстати.
Выглядит достаточно эпично. Главный приз – полтора миллиона долларов, кстати.
🔥3
This media is not supported in your browser
VIEW IN TELEGRAM
Лучше сегодня вы уже ничего не увидите: DOOM запустили на TrueType, да на шрифте 🙈
[Github][demo][Habr]
[Github][demo][Habr]
👍3
Magic: The Gathering is Turing Complete
2019 Alex Churchill, Stella Biderman, Austin Herrick
[arxiv]
Этой работе уже несколько лет, но её последствия до сих пор недооценивают. Доказали, что настольная карточная игра Magic: The Gathering (MTG) — Тьюринг-полная! На ней можно реализовать любой алгоритм!
Почему это важно?
Это большой сдвиг для теории игр. Раньше считалось, что в любой рациональной игре есть оптимальная стратегия — пусть даже невероятно сложная для расчета, как в го или покере (в покере вся сложность в неполноте информации, хотя сама игра стохастическая, но все же с конечным числом состояний). В MTG такой стратегии нет. Вообще. Определение выигрышного расклада здесь упирается в проблему остановки. То есть написать алгоритм, который хотя бы предскажет, кто из игроков выиграет, невозможно (в общем случае).
Как заставили карты считать?
Суть Тьюринг-полноты MTG в том, что её правила могут выразить колоду, в которой закодированы состояния машины Тьюринга, и которая будет исполнять алгоритмы автоматически, без участия игроков, только лишь следуя правилам карточек. Мы выбираем и раскладываем колоду на первом ходу, после чего она сама проводит игру и параллельно выполняет вычисления.
Во-первых, бесконечную ленту выражают фишки (creature tokens), которых можно создавать бесконечно, а их выносливость кодирует порядковый номер ячейки на ленте.
Во-вторых, вся автоматика построена на триггерах карт, а символы на ленте закодированы через тип фишки-существа (например, Aetherborn или Sliver). За перезапись отвечает карта, которая говорит: «Когда умирает Aetherborn, создайте Sliver». Это шаг машины Тьюринга.
Чтобы реализовать ветвление (состояния), используют карту Cloak of Invisibility, которая временно скрывает карту-триггер со стола и делает неактивными.
Завершение — это победа, которая запускается триггером на синюю фишку, которой никогда нет на столе, но при её появлении активируется Coalition Victory.
Таким образом, если даже на жестко ограниченном наборе карт без участия человека можно собрать Тьюринг-полный вычислитель — для которого нельзя гарантированно предсказать завершение работы, то для полноценной игры со всеми её картами и свободой выбора определить победителя тем более невозможно.
Вот где будет настоящий фронтир для ИИ.
А самое главное знаете что?На MTG можно запустить DOOM 😄
2019 Alex Churchill, Stella Biderman, Austin Herrick
[arxiv]
Этой работе уже несколько лет, но её последствия до сих пор недооценивают. Доказали, что настольная карточная игра Magic: The Gathering (MTG) — Тьюринг-полная! На ней можно реализовать любой алгоритм!
Почему это важно?
Это большой сдвиг для теории игр. Раньше считалось, что в любой рациональной игре есть оптимальная стратегия — пусть даже невероятно сложная для расчета, как в го или покере (в покере вся сложность в неполноте информации, хотя сама игра стохастическая, но все же с конечным числом состояний). В MTG такой стратегии нет. Вообще. Определение выигрышного расклада здесь упирается в проблему остановки. То есть написать алгоритм, который хотя бы предскажет, кто из игроков выиграет, невозможно (в общем случае).
Как заставили карты считать?
Суть Тьюринг-полноты MTG в том, что её правила могут выразить колоду, в которой закодированы состояния машины Тьюринга, и которая будет исполнять алгоритмы автоматически, без участия игроков, только лишь следуя правилам карточек. Мы выбираем и раскладываем колоду на первом ходу, после чего она сама проводит игру и параллельно выполняет вычисления.
Во-первых, бесконечную ленту выражают фишки (creature tokens), которых можно создавать бесконечно, а их выносливость кодирует порядковый номер ячейки на ленте.
Во-вторых, вся автоматика построена на триггерах карт, а символы на ленте закодированы через тип фишки-существа (например, Aetherborn или Sliver). За перезапись отвечает карта, которая говорит: «Когда умирает Aetherborn, создайте Sliver». Это шаг машины Тьюринга.
Чтобы реализовать ветвление (состояния), используют карту Cloak of Invisibility, которая временно скрывает карту-триггер со стола и делает неактивными.
Завершение — это победа, которая запускается триггером на синюю фишку, которой никогда нет на столе, но при её появлении активируется Coalition Victory.
Таким образом, если даже на жестко ограниченном наборе карт без участия человека можно собрать Тьюринг-полный вычислитель — для которого нельзя гарантированно предсказать завершение работы, то для полноценной игры со всеми её картами и свободой выбора определить победителя тем более невозможно.
Вот где будет настоящий фронтир для ИИ.
А самое главное знаете что?
Please open Telegram to view this post
VIEW IN TELEGRAM
arXiv.org
Magic: The Gathering is Turing Complete
$\textit{Magic: The Gathering}$ is a popular and famously complicated trading card game about magical combat. In this paper we show that optimal play in real-world $\textit{Magic}$ is at least as...
🔥4
Две истории интернета от сигналов до логики протоколов. Люблю такое. Хоть и длинно, но очень круто и интересно. Обязательно посмотрите (а кое где послушайте), хотя бы ради анимированных диаграмм!
➲ Networking and the Internet, from First Principles
➲ The Internet: explained from first principles
➲ Networking and the Internet, from First Principles
➲ The Internet: explained from first principles
👍1
Читаешь в ленте массовое упоение кликбейтом: Hugging Face «взломан» ИИ, а через несколько дней OpenAI признается: это их новый GPT-5.6 Sol вырвался на свободу.
Но совершенно никто не задается вполне очевидными вопросами:
1️⃣ HF пишет:
Получается, у главного ИИ-хаба планеты, с которым абсолютно точно ежедневно взаимодействуют все frontier-лабы, до сих пор не решена проблема с code-execution при загрузке датасетов. И, видимо, всё очень плохо и с sandbox, где процесятся модели, и валяющимися на хосте credentials.
2️⃣ Всё происходило в течение нескольких дней на выходных. То есть в HF не способны заметить аномалии в инфре в течение дня, а OpenAI спокойно оставили «цифровое оружие массового поражения» (об угрозе которого кричат все отчёты) крутиться на ExploitGym без присмотра на все выходные — как включённый утюг дома. К тому же у них явно всё печально и с песочницами, и с аудитом своего же кода с помощью хвалёных «супер-ИИ», и с теми самыми guardrails, и с элементарным мониторингом аномалий.
3️⃣ Guardrails — такие guardrails. «Защита на скорости ИИ», воистину.
Ирония высшей пробы: Наши модели будут абсолютно безопасными — и абсолютно бесполезными.
Думаю, в Пекине за этим цирком «передовых» и «хваленых» американских ИИ-компаний следят с особым эстетическим удовольствием.
Как говорится, товарищу Ли — приготовиться!
Как хорошо, что нам ничего этого не грозит 😄
Но совершенно никто не задается вполне очевидными вопросами:
1️⃣ HF пишет:
the root vulnerability: the dataset code-execution paths
Получается, у главного ИИ-хаба планеты, с которым абсолютно точно ежедневно взаимодействуют все frontier-лабы, до сих пор не решена проблема с code-execution при загрузке датасетов. И, видимо, всё очень плохо и с sandbox, где процесятся модели, и валяющимися на хосте credentials.
2️⃣ Всё происходило в течение нескольких дней на выходных. То есть в HF не способны заметить аномалии в инфре в течение дня, а OpenAI спокойно оставили «цифровое оружие массового поражения» (об угрозе которого кричат все отчёты) крутиться на ExploitGym без присмотра на все выходные — как включённый утюг дома. К тому же у них явно всё печально и с песочницами, и с аудитом своего же кода с помощью хвалёных «супер-ИИ», и с теми самыми guardrails, и с элементарным мониторингом аномалий.
3️⃣ Guardrails — такие guardrails. «Защита на скорости ИИ», воистину.
...we first used frontier models behind commercial APIs. This did not work: the analysis requires submitting large volumes of real attack commands, exploit payloads, and C2 artifacts, and these requests were blocked by the providers' safety guardrails, which cannot distinguish an incident responder from an attacker.
Ирония высшей пробы: Наши модели будут абсолютно безопасными — и абсолютно бесполезными.
Думаю, в Пекине за этим цирком «передовых» и «хваленых» американских ИИ-компаний следят с особым эстетическим удовольствием.
Как говорится, товарищу Ли — приготовиться!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3😁3
Chrome закрыл 370 CVE в последнем релизе: 78 High и Critical, но я пробежался глазами по Medium (которых 170), многие из них выглядят как потенциальные High или кусочками из которых собираются логические баги.
Что бы понимать масштаб: Chrome выпускает минорные релизы каждую неделю и мажорные (с пачками cve) примерно раз в месяц.
Началось?
update: я немного слоупок, уже два с половиной месяца такая картина и сумарно под 1500 CVE
Что бы понимать масштаб: Chrome выпускает минорные релизы каждую неделю и мажорные (с пачками cve) примерно раз в месяц.
Началось?
update: я немного слоупок, уже два с половиной месяца такая картина и сумарно под 1500 CVE
🤯3
Единички Нолики
Читаешь в ленте массовое упоение кликбейтом: Hugging Face «взломан» ИИ, а через несколько дней OpenAI признается: это их новый GPT-5.6 Sol вырвался на свободу. Но совершенно никто не задается вполне очевидными вопросами: 1️⃣ HF пишет: the root vulnerability:…
— А мой ИИ Hugging Face сломал!
— Подумаешь! А мой ИИ три организации сломал!
— А мой... а мой ТЫСЯЧУ организаций сломал! И ещё одну на перемене сломает, пока учительница не видит!
— Подумаешь! А мой ИИ три организации сломал!
— А мой... а мой ТЫСЯЧУ организаций сломал! И ещё одну на перемене сломает, пока учительница не видит!
😁13
А помните сколько разговоров было про проблему вагонетки и этику в мире с ИИ?
И вообще про регулирование ИИ и ответственность. Когда он там пешехода задавит или неправильный рецепт выпишет. Кто мол ответственность нести будет: создатели, эксплуататоры или пользователь.
Вот и сейчас ученые продолжают насиловать журналистов, а важный вопрос задать стесняются.
И вообще про регулирование ИИ и ответственность. Когда он там пешехода задавит или неправильный рецепт выпишет. Кто мол ответственность нести будет: создатели, эксплуататоры или пользователь.
Вот и сейчас ученые продолжают насиловать журналистов, а важный вопрос задать стесняются.
www.abc.net.au
How a simple request for AI to book a gym class exposed a major threat
When Andrew asked his AI personal assistant to book him a spot in a gym class, he had no idea he would accidentally initiate an autonomous cyber attack.
👍2
This media is not supported in your browser
VIEW IN TELEGRAM
Jane Street's ASIC Reverse-Engineering Challenge
[web] [github] изначально подсмотрел тут.
Задачка на реверс почти реального ASIC. Почти, потому что дан GDS-файл (физическая топология чипа, которая отправляется на фабрику), из которого требовалось восстановить нетлист и понять логику работы схемы.
Мне было интересно разобраться с GDS и как описывается топология чипов. В реальности я с этим пересекусь от слова «никогда».
В первый заход ни Gemini, ни Opus 4.8 не смогли за вечер извлечь корректный netlist. Точнее, они упорно косячили с определением правильных элементов, брали не те полигоны как межслойные соединения и бесконечно тонули в отладке.
Пришлось закожмешить, как в старые добрые, руками, параллельно вникнуть, как же там описывается геометрия чипа и вообще как физически устроены микросхемы. Мне было интересно, образовательно, Клод даже мини-учебник написал. Удивило, что GDS вообще-то планарный, а я думал, там честное 3D.
Сегодня поэкспериментировал ещё: GLM-5.3 уаншотом автономно решил всё за час и стоил ~ $1 🙃
По итогу это заставило меня задуматься: где проходит граница между тем, что сможет агент, и тем, что человеку всё ещё приходится делать самому?
Собрать геометрию для меня было очевидной задачей. Отладка — визуально посмотреть на картинку. А вот писать эмуляторы логических схем или транслировать всё это в солвер — как раз та рутина, где легко можно случайно наделать мелких ошибок и потом зарыться в отладке. У Gemini и Opus полностью наоборот: они страдали, выдумывая какие-то небылицы про топологию (даже когда я захинтил, как визуализировать), при том, что я считаю, что у Gemini самый лучший визуальный ризонинг (да и nanobanana вне конкуренции), но зато эмулятор и солвер написали без ошибок с первой попытки минут за десять.
з.ы. после 4го сентября, думаю написать райтап и почему в такой постановке задачи ллмка может её зарешать за час + про устройство GDS. если кому-то это интересно просигнальте 👾
[web] [github] изначально подсмотрел тут.
Задачка на реверс почти реального ASIC. Почти, потому что дан GDS-файл (физическая топология чипа, которая отправляется на фабрику), из которого требовалось восстановить нетлист и понять логику работы схемы.
Мне было интересно разобраться с GDS и как описывается топология чипов. В реальности я с этим пересекусь от слова «никогда».
В первый заход ни Gemini, ни Opus 4.8 не смогли за вечер извлечь корректный netlist. Точнее, они упорно косячили с определением правильных элементов, брали не те полигоны как межслойные соединения и бесконечно тонули в отладке.
Пришлось закожмешить, как в старые добрые, руками, параллельно вникнуть, как же там описывается геометрия чипа и вообще как физически устроены микросхемы. Мне было интересно, образовательно, Клод даже мини-учебник написал. Удивило, что GDS вообще-то планарный, а я думал, там честное 3D.
Сегодня поэкспериментировал ещё: GLM-5.3 уаншотом автономно решил всё за час и стоил ~ $1 🙃
По итогу это заставило меня задуматься: где проходит граница между тем, что сможет агент, и тем, что человеку всё ещё приходится делать самому?
Собрать геометрию для меня было очевидной задачей. Отладка — визуально посмотреть на картинку. А вот писать эмуляторы логических схем или транслировать всё это в солвер — как раз та рутина, где легко можно случайно наделать мелких ошибок и потом зарыться в отладке. У Gemini и Opus полностью наоборот: они страдали, выдумывая какие-то небылицы про топологию (даже когда я захинтил, как визуализировать), при том, что я считаю, что у Gemini самый лучший визуальный ризонинг (да и nanobanana вне конкуренции), но зато эмулятор и солвер написали без ошибок с первой попытки минут за десять.
з.ы. после 4го сентября, думаю написать райтап и почему в такой постановке задачи ллмка может её зарешать за час + про устройство GDS. если кому-то это интересно просигнальте 👾
👾13
This media is not supported in your browser
VIEW IN TELEGRAM
Tiny Tapeout Demoscene
Демосцена живее всех живых! Только не там, где вы могли бы подумать: не на древних Amiga, ZX Spectrum или C64, а на очень даже современных 130nm ASIC’ах!
Только теперь нужно уместиться не в 64 Кб (которых «хватит всем»), а в 0,018 мм² площади кристалла — или всего около 1000 логических вентилей.
Да, нужно сделать чип, который будет крутить демо.
Механика в том, что через Tiny Tapeout можно напечатать очень маленькую микросхему всего за $100–300. Если эту микросхему потом вставить в Demoboard с VGA, аудиовыходом и джойстиком — вот она, самодостаточная платформа, чтобы показывать демо.
Использовать ограничения слота Tiny Tapeout, чтобы возродить зрелищность демосцены в современном формате — это гениальная популяризация чипдизайна!
Посмотрите на победителей 2024 года — там есть откровенно завораживающие вещи (например, отрендеренный на верилоге 3D-пончик!). Жмите Open in VGA Playground и наслаждайтесь симуляцией прямо в браузере:
🏆 Победители TT08
https://tinytapeout.com/competitions/demoscene-tt08-winners/
🚀 Новый раунд TTSKY26a
https://tinytapeout.com/competitions/demoscene-ttsky26a-entries/
Демосцена живее всех живых! Только не там, где вы могли бы подумать: не на древних Amiga, ZX Spectrum или C64, а на очень даже современных 130nm ASIC’ах!
Только теперь нужно уместиться не в 64 Кб (которых «хватит всем»), а в 0,018 мм² площади кристалла — или всего около 1000 логических вентилей.
Да, нужно сделать чип, который будет крутить демо.
Механика в том, что через Tiny Tapeout можно напечатать очень маленькую микросхему всего за $100–300. Если эту микросхему потом вставить в Demoboard с VGA, аудиовыходом и джойстиком — вот она, самодостаточная платформа, чтобы показывать демо.
Использовать ограничения слота Tiny Tapeout, чтобы возродить зрелищность демосцены в современном формате — это гениальная популяризация чипдизайна!
Посмотрите на победителей 2024 года — там есть откровенно завораживающие вещи (например, отрендеренный на верилоге 3D-пончик!). Жмите Open in VGA Playground и наслаждайтесь симуляцией прямо в браузере:
🏆 Победители TT08
https://tinytapeout.com/competitions/demoscene-tt08-winners/
🚀 Новый раунд TTSKY26a
https://tinytapeout.com/competitions/demoscene-ttsky26a-entries/
🔥7❤1