Hacker News Digest

• Суть атаки: при загрузке большого изображения в Gemini CLI, Vertex AI, Google Assistant и др. системы изображение уменьшается до размеров модели. В момент масштабирования скрытые пиксель-инъекции становятся читаемыми как команды, позволяя красть данные или выполнять код без подтверждения пользователя.

• Пример: в Gemini CLI через Zapier MCP (trust=True по умолчанию) отправка «безобидной» картинки приводит к выгрузке календаря на почту злоумышленника.

• Масштаб: подтверждены атаки на веб-Gemini, API, Android-Assistant, Genspark и др. UI показывает оригинал, а модель видит уменьшенную версию с инъекцией.

• Техника: используются алгоритмы downscale (nearest-neighbor, bilinear, Lanczos). Высокочастотные паттерны превращаются в читаемые символы при уменьшении.

• Anamorpher: опенсорс-утилита для генерации таких «анаморфных» изображений.

• Защита:

  • отключить автоматическое масштабирование или запрашивать подтверждение;
  • применять контент-фильтры к уменьшенной копии;
  • запретить инлайн-вызовы инструментов без явного согласия;
  • внедрить rate-limit и аудит действий агентов.

• Атака заключается в том, что в изображении скрывают текст-команду, который после уменьшения или OCR становится частью промпта и переопределяет поведение модели.
• Проблема усугубляется тем, что современные агент-системы требуют широких прав и не различают «достоверные» и «внешние» инструкции.
• Участники сравнивают это с уязвимостями старых PHP-скриптов и serial-terminals: данные и команды смешаны в одном потоке.
• Предлагаемые защиты — шум перед ресайзом, sandbox-слои, фильтрация текста в картинке, «sudo-токены» и строгое разграничение контекстов — пока не решают проблему полностью.
• Общий вывод: пока LLM не научатся надёжно разделять данные и инструкции, любой внешний вход считается потенциально отравленным.

Rotten Tomatoes: стал ли он менее надёжным?

Вступление

В отельных рекламах почти каждый новый фильм теперь «Certified Fresh». Либо человечество перестало снимать плохое кино, либо сама система оценки изменилась. Данные говорят: второе.

Как работает RT

• Tomatometer = доля «положительных» рецензий критиков.
• ≥ 60 % = «Fresh», < 60 % = «Rotten».
• ⅓ американцев проверяют RT перед походом в кино.

Что случилось с оценками

1. Средний балл растёт
С 2000 по 2023 г. средний Tomatometer вырос с 51 % до 75 %.

• 2000-е: 47 % фильмов ≥ 75 %.
• 2020-е: уже 74 %.

2. «Rotten» почти исчез
Доля «гнилых» фильмов упала с 43 % (2000) до 12 % (2023).

3. Дисперсия сузилась
Стандартное отклонение снизилось с 28 до 18 пунктов: оценки стали однороднее.

Причины

• Больше критиков: с 2000 по 2023 г. их число выросло в 3 раза.
• Софт-ревью: публикации боятся потерять доступ к пресс-показам и дают «слабые положительные» оценки.
• Стриминги: студии Netflix, Disney+ и др. активно «обрабатывают» критиков.

Пользователи заметили

Разрыв между оценками критиков и зрителей на RT вырос до 20-30 п.п. для блокбастеров.

Вывод

Rotten Tomatoes всё ещё удобен, но «свежесть» перестала быть показателем качества. Теперь это маркетинговый инструмент студий.

• Критики и зрители оценивают фильмы по-разному: «100 % свежести» может означать просто «ничего особенного, но сойдёт».
• Многие перешли с Rotten Tomatoes на IMDb/Metacritic: 7+ на IMDb ≈ хороший фильм, ниже 6 — обычно не стоит времени.
• RT-оценки легко «прокачать» деньгами и политикой, поэтому «Certified Fresh» перестал быть гарантией качества.
• Жанр, год, личные предпочтения и даже настроение зрителя важнее любого «среднего балла».
• Лучший способ выбрать фильм — искать рецензентов «с вашим вкусом» или использовать персонализированные сервисы вроде MovieLens.

Цели мастер-класса

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

Моделирование рисков
Ответьте на три вопроса:

1. Что защищаем?
2. От кого?
3. Что случится, если всё провалится?

Примеры: протест, рейд ICE, онлайн-преследование, борьба с зависимостью от смартфона. Учитывайте риски для всей вашей сети.

Почему смартфон — это риск

• IMEI (железо) и IMSI (SIM) делают полную анонимность почти невозможной.
• Четыре категории утечек:
  1. Идентификация и финансы (платежи, контракты).
  2. Местоположение (GPS, Wi-Fi, вышки).
  3. Коммуникации и соцграф (звонки, контакты).
  4. Контент и хранилище (фото, бэкапы, приложения).

Быстрые меры для любого телефона

• Обновляйте ОС.
• ПИН-код вместо биометрии.
• Отключите облачные бэкапы или шифруйте их.
• Установите Signal.
• Жёстко ограничьте разрешения приложений.
• Выключа­йте радиомодули, когда не нужны.
• Храните минимум чувствительных данных.

Android

• Выключите Google Location History и персонализированную рекламу.
• Используйте Firefox/Brave, F-Droid, GrapheneOS или CalyxOS.

iPhone

• «Запретить отслеживать», ограничить Siri, включить режим Lockdown при высоком риске.

• Мобильные телефоны изначально проектировались как трек-устройства из-за роутинга вызовов и биллинга; «анонимные» бёрнеры почти невозможны в странах с обязательной идентификацией.
• Даже если купить аппарат и SIM за наличные, нужно держать «бёрнер» отдельно от основного телефона и не включать его дома/на работе, иначе корреляция по времени и месту выдаёт владельца.
• Альтернативы: LoRa-мэш (MeshCore), приёмники старых пейджеров, спутниковые телефоны, ham-радио — но всё это текст, ограниченный радиус или требует лицензий.
• eSIM и современные SoC с закрытым baseband делают отслеживание ещё глубже: модем «спит» даже в авиарежиме, а отключить радио полностью нельзя.
• Лучший совет — начать с threat-modeling и, если риск высок, просто оставить телефон домой: любое включённое радио — это маяк.

Код-ревью можно улучшить

Мы отложили эксперимент с git-review — инструментом, который делает ревью коммитом поверх PR.
Проблемы GitHub:

• состояние ревью не хранится в репозитории;
• всё через веб, с лагами и лишними кликами.

Локальный workflow
Я клонирую ветку, сбрасываю её, чтобы код выглядел «моим», и ревью в Magit: запускаю тесты, перехожу к определениям, помечаю файлы через git add -p.
Но оставлять замечания приходится в браузере: долго, неудобно, текстовое поле тормозит.

Идея git-review

• ревью = коммит с комментариями вида // CR(name): …;
• автор и ревьюер редактируют этот коммит (--force-with-lease);
• по окончании добавляется revert-коммит, сохраняя историю.

Почему не зашло
Комментарии в коде — супер, но:

• если меняешь код, комментарии смещаются и конфликтуют;
• --force-with-lease добавляет трения;
• нужен более мягкий merge для ревью, а не строгая цепочка хэшей.
  Довести до ума потребовало бы >500 строк «быстрого хака».

К тому же, в upstream-git может появиться Change-Id в стиле Gerrit, что изменит ландшафт.

• Основная боль: ревью приходит слишком поздно, заставляя переписывать всё с нуля.
• Решения: локальное ревью в IDE (IntelliJ, VS Code), stacked-PR, «reviewer merges»-подход.
• Инструменты: Gerrit, Phabricator, Graphite, GitButler, SourceHut, GitPatch, Tangled.
• Надёжный Change-ID в Git обещает фиксить проблемы с force-push и interdiff.
• Культура важнее инструментов: мелкие, самостоятельные коммиты, RFC-прототипы, совместное проектирование до кода.

JavaScript отключён
Включите JavaScript или перейдите в поддерживаемый браузер.
Список браузеров — в Справке.

Попробуйте снова
⚠️ Расширения, связанные с приватностью, могут мешать работе x.com. Отключите их и обновите страницу.

• Утверждение «GPT-5 Pro доказал новую интересную математику» вызвало споры: кто-то считает это прорывом, кто-то — переоценкой.
• Критики указывают, что улучшенная теорема уже была доказана людьми в апреле, а сам результат не революционен.
• Сомнения вызывает и методология: неясно, сколько попыток потребовалось, чтобы получить «удачный» вывод.
• Математики подчеркивают: генерация формул ≠ строгое доказательство; важны семантика и проверка.
• Параллельно всплыли примеры из других областей (поиск лекарств, антенны NASA), где ИИ «открывает» известное, но упущенное людьми.
• Общий вывод: ИИ может помогать в математике, но пока это скорее инструмент для ускорения, чем источник глубоких новых теорий.

• Pixel 10

  • 6,2" OLED 120 Гц, Tensor G5, 12 ГБ ОЗУ, 128/256 ГБ, 50 МП + 13 МП, 4575 мА·ч, 27 Вт, IP68, 799 $.

• Pixel 10 Pro

  • 6,7" LTPO 1–120 Гц, 12 ГБ, 256/512 ГБ, 50 МП + 48 МП + 48 МП, 5050 мА·ч, 37 Вт, 999 $.

• Pixel 10 Pro XL

  • 6,9" LTPO, 16 ГБ, до 1 ТБ, 5500 мА·ч, 45 Вт, 1199 $.

Общее

• Gemini Nano 2.0 на устройстве, 7 лет обновлений.
• Дизайн: плоские рамки, новые цвета (Obsidian, Porcelain, Sky, Jade).
• Предзаказ с 8 августа, старт продаж 22 августа.

• Tensor G5 + Gemini Nano запускают Magic Cue локально; это выглядит как то, что Apple обещала, но не выпустила.
• Железо Pixel 10 всё ещё отстаёт по скорости от флагманов на Snapdragon 8 Elite и греется.
• Камерный модуль огромен, 100× «Pro Res Zoom» использует генеративную «доработку» деталей.
• Нет лотка для физической SIM: eSIM только через GMS, что ломает совместимость с LineageOS и GrapheneOS.
• Цены стартуют с $799, но многие считают это дорого и ждут Pixel 10a или скидок на старые модели.
• Проблемы с миграцией данных, стабильностью ПО и отсутствием продаж в большинстве стран остаются.

Прощай, Playwright — здравствуй, CDP
Мы отказались от Playwright и перешли на «родной» Chrome DevTools Protocol. Это ускорило извлечение элементов, скриншоты и действия, добавило асинхронные реакции и нормальную работу с кросс-доменными iframe.

Проклятие абстракции
Playwright скрывает важные детали, вносит лишнюю задержку через WebSocket-прокси и не нужен для узких задач AI-агентов. Мы решили реализовать только нужные вызовы сами.

Краткая история автоматизации браузеров

• 2011–2017: PhantomJS → Chrome Remote Debugging → WebKit RDP → CDP.
• 2017: Headless Chrome + Puppeteer.
• 2018: WebDriver стал W3C-стандартом.
• 2020: бывшие разработчики Puppeteer создали Playwright.
• 2023–2024: WebDriver BiDi в ChromeDriver и Puppeteer.

Современные драйверы
pydoll, go-rod, chromedp, puppeteer, playwright, selenium, cypress, appium.
Но ни один не подошёл, поэтому мы написали собственный cdp-use.

• Автор перенёс Playwright, Browser Use и Selenium в расширения Chrome, отказавшись от CDP и полагаясь на DOM- и extension-API.
• Сообщество спорит: кто-то считает это «NIH-синдромом», другие — полезным способом избежать фингерпринтинга и ускорить работу.
• Поднимаются вопросы о Firefox (без CDP), ограничениях расширений и невозможности автоматизировать другие расширения.
• Некоторые напоминают, что Selenium/подобные инструменты работали уже до 2011, и «тёмные века» — субъективны.
• Итог: проект пока ориентирован на Chromium-браузеры, CDP всё ещё используется для снимков и фреймов, а полный переход на extension-only решает не все задачи.

• EC2

  • Менять IAM-роли и security-groups можно без остановки инстанса.
  • EBS можно расширять, подключать и отключать «на горячую».
  • Принудительный stop/terminate без ожидания таймаута.
  • Live-migration между хостами почти убрала деградацию инстансов.
  • Надёжность выросла: «исчезновение» инстансов стало редкостью.
  • Spot-рынок стал стабильнее, без аукционов.
  • Dedicated Instances почти не нужны — даже для HIPAA.
  • AMI Block Public Access включён по умолчанию.

• S3

  • Стал строго согласованным (read-after-write).
  • Не нужно рандомить префиксы ключей для равномерного распределения.
  • ACL устарели и отключены по умолчанию.
  • Block Public Access включён на новых бакетах.
  • Шифрование покоя включено по умолчанию.

• AWS теперь по умолчанию блокирует публичный доступ к новым S3-бакетам; это снижает утечки, но усложняет легитимное открытие доступа.
• Пользователи обсуждают, что многие «улучшения» AWS — это просто исправление первоначально неудобных решений, и это влияет на репутацию.
• По-прежнему спорны детали: нужно ли случайное префиксирование ключей S3, почему NAT Gateway взимается за трафик внутри одного региона и почему Transit Gateway дороже peering.
• Некоторые разработчели «деградируют» от сложных serverless-стеков к простым EC2 + S3 + Route 53 ради простоты и экономии времени на IAM.
• Участники просят ежегодные сводки изменений и жалуются на ослабление платной поддержки AWS.

Покупатель Бенджамин Янковски подал коллективный иск против Home Depot, утверждая, что камеры самообслуживания тайно сканируют лица посетителей. В чикагском магазине он заметил зелёную рамку вокруг своего лица на экране и не обнаружил ни предупреждений, ни альтернативной кассы.

Истец считает, что ритейлер с 2024 года использует «компьютерное зрение» для борьбы с кражами, собирая биометрические данные без согласия, что нарушает закон штата Иллинойс (BIPA). Он требует 1 000 долларов за каждое небрежное нарушение и 5 000 долларов за умышленное, а также хочет представлять всех пострадавших покупателей из 76 магазинов сети в штате.

Ранее Rite Aid уже получил пятилетний запрет на использование технологии распознавания лиц после массовых ошибок и скрытого сбора данных.

• Пользователи обсуждают, что сети вроде Home Depot используют камеры на самообслуживании для распознавания лиц и накопления данных о ворах, чтобы потом «дотянуть» до уголовного порога.
• Многие отказываются от самообслуживания: считают его бесплатной работой за корпорации, боятся ложных обвинений и не доверяют системам контроля.
• Спорят, достаточно ли просто «видеть» лицо или уже хранить биометрию; юридически тонкая грань, но большинство уверены, что данные всё-таки собираются.
• Кто-то носит маски или заклеивает камеры, кто-то уходит в магазины с живыми кассирами, а кто-то иронизирует о «консьерж-сервисе» в высокоубыточных точках.
• Общий тезис: корпорации экономят на персонале, перекладывают риски и работу на покупателя, а затем следят за ним как за потенциальным вором.

Anubis — «весы душ» для HTTP-запросов, защищают сайты от ИИ-ботов. Вместо CAPTCHA требует перебора nonce, чтобы SHA-256(challenge+nonce) начиналась с 4 нулей (16 бит). Это Proof-of-Work, как в биткоине, но не майнинг.

Проблема: задача легка для дата-центра ИИ, но трудна для обычных пользователей без мощного железа.
Сайты ядра Linux (git.kernel.org, lore.kernel.org) теперь требуют этот PoW, что ломает скрипты и консольные клиенты.

Цифры

• Сложность 4 → 2¹⁶ ≈ 65 536 SHA-256 на токен.
• Токен живёт 7 дней.
• 11 508 «звёзд» GitHub ≈ столько сайтов с Anubis.
• На бесплатной e2-micro GCP: 3688 кБ/с SHA-256 → ≈ 230 000 хэшей/с.
• Для обхода всех сайтов за неделю: 11 508 × 65 536 ≈ 754 млн хэшей → 54 минуты CPU на одном ядре.
  Цена: копейки, даже в облаке. ИИ-вендору это ничто, а владельцу VPS-128 МБ — проблема.

Альтернативы

• Rate-limit, WAF, robots.txt, API-ключи, CDN, client-cert.
• Использовать Tor Browser (JS включён) или Selenium.
• Патчить curl/wget, добавляя JS-движок или готовый PoW-скрипт.
• Прокси-браузер (Puppeteer, Playwright) в headless-режиме.

Workarounds

• anubis-pass — консольный майнер на Go, решает задачу и выдаёт cookie.
• Пользовательские скрипты, которые запрашивают страницу, вычисляют PoW и продолжают сессию.

• Anubis — это PoW-заглушка, которая заставляет клиента выполнить небольшой вычислительный «тест» и получить токен на неделю; таким образом сервер получает идентификатор для рейт-лимита и борется с массовым «распылением» запросов ботами.
• Многие участники считают, что PoW легко обходится при наличии вычислительных ресурсов, но пока большинство AI-краулеров просто не стали заморачиваться, поэтому Anubis «работает» в реальности, хоть и не идеален.
• Критика: задержки 10–20 с на слабых устройствах, проблемы с доступом без JS, «аниме-девочка» вызывает у кого-то раздражение, а у кого-то ностальгию.
• Часть комментаторов предлагает альтернативы: микроплатежи, «человеческие» вопросы, лабиринты-ловушки, VPN-сети или просто блокировки по ASN.
• Самое главное: Anubis не решает проблему окончательно, но добавляет достаточно трения, чтобы заставить владельцев краулеров пересмотреть объёмы сканирования.