Hacker News Digest

Supercookie — это технология отслеживания пользователей через favicon, позволяющая идентифицировать посетителей даже при блокировке обычных cookie. Метод основан на использовании уникальных URL-адресов для иконок сайтов, которые сохраняются браузером и могут быть прочитаны разными доменами. Техника работает, потому что браузеры кэшируют favicon и не очищают их при закрытии приватных сеансов.

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

• Обсуждение охватывает как технические детали уязвимости favicon cache, так и более широкие вопросы приватности, ответственности разработчиков и бизнес-моделей в интернете.
• Участники подчеркивают, что браузеры и операционные системы уже давно устранили эту уязвимость, но при этом поднимают вопрос о том, что последствия для сайтов, которые намеренно используют подобные методы, должны быть более серьезными.
• Обсуждается, что даже если технически уязвимость устранена, остается вопрос о том, какие именно данные собираются и как они могут быть использованы.
• Участники также обсуждают, что вместо того, чтобы полагаться на уязвимости, разработчики и компании должны фокусироваться на создании более приватных и безопасных продуктов для пользователей.

Это сообщение представляет собой проверку CAPTCHA на веб-странице, которая определяет, является ли посетитель человеком или роботом. Пользователю предлагается подождать секунду для проверки, а внизу страницы есть ссылка для роботов с инструкциями "залезьте сюда, если вы робот".

Проверка безопасности является стандартной практикой для защиты от автоматических ботов, которые могут спамить или нарушать работу сайта. Ссылка "/stick-och-brinn/" ведет на специальную страницу для подтверждения, что пользователь действительно является роботом, что является обратной логикой обычной CAPTCHA.

• Методы блокировки LLM-краулеров включают создание "ловушек" (скрытые ссылки, невидимые для людей, но распознаваемые ботами), но они могут блокировать легитимных пользователей или RSS-ридеры.
• LLM-краулеры часто игнорируют robots.txt, создают высокую нагрузку на сайты, используют спуфированные User-Agent и не соблюдают ограничения на частоту запросов.
• Защита PDF-файлов от LLM-анализа практически невозможна, так как контент может быть извлечен через OCR или обход DRM; предлагается добавлять примечания для людей.
• Агрессивные LLM-агенты могут генерировать тысячи запросов в минуту, перегружая серверы, в отличие от классических краулеров.
• Этические вопросы включают использование LLM для рецензирования научных работ без согласия авторов и потенциальное манипулирование выводами модели.

Автор столкнулся с проблемой агрессивных ботов, собирающих данные для обучения LLM, которые составили 99% трафика на его сервере. В отличие от поисковых роботов, эти боты игнорируют robots.txt, постоянно меняют IP-адреса и отправляют множество запросов в секунду. Попытки блокировать их через IP-списки, ограничения по скорости или защитные стены (CAPTCHA, paywall) оказались неэффективными, так как боты просто находили обходные пути, а защитные меры мешали обычным пользователям.

Самым эффективным решением оказалось создание динамического генератора бессмысленного контента — "Markov babbler", который потребляет всего около 60 микросекунд процессорного времени на запрос и использует 1.2 МБ памяти. Этот подход не требует поддержки черных списков и позволяет эффективно "кормить" ботов, не тратя ресурсы на передачу реальных данных. Автор подчеркивает, что его контент лицензирован CC BY-NC-SA 4.0, но явно не разрешен для использования в обучении ML/LLM.

• Основной метод борьбы с AI-скраперами — генерация бессмысленного контента через Markov-цепи или gzip-бомбы, чтобы увеличить затраты скраперов на обработку данных.
• Этические риски: загрязнение обучающих данных LLM может привести к непредсказуемым последствиям и нарушению доверия к системам ИИ.
• Технические альтернативы: использование Basic Auth с публичными учётными данными или редирект на специализированные сервисы вроде "Markov Babbler".
• Проблема масштабирования: массовое применение методов защиты может привести к блокировке легитимного трафика и снижению репутации сайта.
• Эффективность сомнительна: современные LLM могут детектировать мусорный контент, а скраперы легко обходят простые защиты (например, через браузерные прокси).

• Google Safe Browsing флагнул множество легитимных сайтов, включая Immich, из-за ложных срабатываний, что вызвало обсуждение о том, что Google может злоупотреблять своим положением в браузере Chrome и сервисах вроде Safe Browsing, чтобы подавлять конкурентов.
• Участники обсуждения подчеркнули, что Google может использовать Safe Browsing как инструмент для антиконкурентной практики, поскольку флагнув сайт, он может быть использован для блокировки доступа к сервисам Google, что может быть использовано для подавления конкурентов.
• Обсуждение также затронуло вопрос о том, что Google может использовать Safe Browsing для сбора данных о поведении пользователей, что может быть использовано для таргетинга рекламы и других целей.
• Участники обсуждения также выразили обеспокоенность о том, что Google может использовать Safe Browsing для блокировки доступа к веб-сайтам, что может быть использовано для подавления свободы слова и информации.
• Участники обсуждения также выразили обеспокоенность о том, что Google может использовать Safe Browsing для блокировки доступа к веб-сайтам, что может быть использовано для подавления конкурентов.

Новая функция http.CrossOriginProtection в Go 1.25 помогает защититься от CSRF, проверяя заголовки Sec-Fetch-Site и Origin. Она блокирует небезопасные запросы (POST, PUT и т.д.) от разных источников. Однако она не защищает от старых браузеров без этих заголовков. Для полной безопасности следует сочетать её с токенами.

• Обсуждение показало, что защита от CSRF через заголовки Origin/Sec-Fetch-Site работает примерно в 95% браузеров, и автор статьи не считает это проблемой.
• Участники обсуждали, что отказ от поддержки старых браузеров — это сознательный выбор, а не упущение, и что в 2025 году оставшиеся 5% в основном представляют собой старые телевизоры, телефоны и прочие устройства, которые не могут быть обновлены.
• Некоторые участники отметили, что даже если бы мы хотели защитить этих пользователей, устаревшие методы вроде проверки Referer или токенов всё ещё не защитят от CSRF, а значит всё равно придётся от них отказаться.
• Была поднята тема, что Rails и другие фреймворки уже давно решили эту проблему, но автор статьи ответил, что не видит в этом необходимости, так как считает, что вся ответственность за безопасность ложится на разработчика, который должен внимательно изучить документацию.

Нельзя сделать скриншот этого.

• Представлен эффект текста, который исчезает при попытке скриншота, но виден в движении.
• Обсуждаются технические обходные пути: запись видео, наложение кадров, изменение масштаба или режимов съёмки.
• Упоминаются аналогичные визуальные эффекты в играх (Branta Games) и на обложках альбомов (Soulwax).
• Предлагаются потенциальные применения: защита конфиденциальных данных, CAPTCHA, недоступные для ИИ задачи.
• Отмечаются проблемы доступности для людей с нарушениями зрения и вызываемая эффектом тошнота.
• Поднимается вопрос о возможности создания обратного эффекта — текста, читаемого только на скриншоте.
• Делается вывод, что метод не является абсолютной защитой, так как обходится видеозаписью.

Как мы взломали Burger King: обход аутентификации = прослушка драйв- thru

Старт
RBI (Burger King, Tim Hortons, Popeyes) управляет 30 000 точек через платформу «assistant». Уязвимости позволяли открыть любую из них и слушать разговоры у окна заказа.

Дыры

1. Регистрация без проверки почты: GraphQL-мутация signUp создавала аккаунт мгновенно; пароль присылали открытым текстом.
2. Список всех магазинов: инкрементный storeId + запрос getStore → персонал, конфиги, id.
3. createToken без авторизации: передал storeId – получил master-токен.
4. Повышение до админа: updateUser(roles: "admin") одной мутацией.
5. Сайт заказа оборудования: пароль «защищён» клиентским JS, сам пароль в HTML.
6. Планшеты в зале и драйв-thru:
   • главный экран /screens/main?authToken=… – история разговоров с аудио;
   • диагностика /screens/diagnostic – пароль admin, регулировка громкости и запись звука в реальном времени.

Итог
Одна уязвимая GraphQL-точка → полный контроль над глобальной сетью, персональными данными и живыми разговорами клиентов.

• Пост исследователя безопасности о дырах в IT Burger King удалили после жалобы DMCA от стартапа Cyble.
• Уязвимости были клиент-side-only пароль в HTML, незащищённые голосовые записи, привязка голоса к имени и номеру авто.
• Автор сообщил Burger King заранее, получил молчание и нулевой бонус, после публикации — DMCA-удаление.
• Комментаторы обсуждают: злоупотребление DMCA, отсутствие bug bounty, этика публичного разоблачения и перспективы тюрьмы за CFAA.