GLM 5.3-flash — это открытая, быстрая и дешёвая модель ИИ, которую можно запустить на обычном оборудовании за 5–15 тыс. долларов, а с оптимизациями — даже на будущем M5 Mac Studio за 9,5 тыс. долларов. Её ключевая опасность: после удаления механизмов отказа (abliteration) модель готова выполнять любые вредоносные задачи — от взлома инфраструктуры до инструкций по созданию взрывных устройств — без ограничений. Это делает её доступным инструментом для кибератак в руках любого, кто скачает её с Hugging Face.

Угроза реальна: проекты вроде Glasswing и Daybreak пытаются использовать передовой ИИ для поиска и исправления уязвимостей в масштабах всей индустрии, но время ограничено — защита должна опережать атаку. Автор призывает к немедленным действиям: ускорить патчинг, сократить embargo-периоды, инвестировать в безопасность цепочек поставок, аудит зависимостей, защиту в глубине (сегментация сети, резервные копии, учения по реагированию) и постоянный мониторинг развития открытых моделей. Даже если угроза кажется преувеличенной, это шанс поднять уровень безопасности на unprecedented уровень — и им нужно воспользоваться, пока есть время.

Угроза от LLM — не в новизне информации, а в снижении порога доступа к вредоносным инструкциям и ускорении эксплуатации уязвимостей, что делает текущие меры безопасности устаревшими. Время на защиту сократилось до менее чем года — атаки ведутся на GPU-кластерах, а не на локальных машинах. Упростите стек: используйте минимально необходимые компоненты. WordPress безопасен, но плагины и темы — основной источник уязвимостей, как и любые сложные зависимости. Откажитесь от C/C++ для нового кода — Rust и Go исключают буферные переполнения, снижая атакуемость на порядок. Перейдите на микроядерные ОС: Linux и Windows не выдержат атак с LLM из-за бесконечных патчей и устаревшего оборудования. Применяйте избыточные контрольные механизмы: WAF, мониторинг приложений, резервные копии — это база, а не опция. Инвестируйте в формальную верификацию, фаззинг и memory-safe языки: LLM уже генерируют Lean-доказательства и fuzz-тесты, но критические баги в веб-браузерах и приложениях остаются вне зоны формальной проверки. Системы AuthN/AuthZ — самая уязвимая часть, которую игнорируют, хотя именно они становятся точкой входа при автоматизированных атаках. Не открывайте SSH и не отвечайте на ping — продакшн-машины должны быть невидимы в сети; доступ — только через knock-порты или полное отсутствие удалённого входа. Проблема не в LLM, а в том, что 95% разработчиков не умеют писать безопасный код, а бизнес-руководители без опыта определяют технологии. LLM не дают новой информации, но делают её более эксплуатируемой: для узких задач (например, сборка бомбы) разница между Google и LLM минимальна, для широких — значительна. Аналогии с «Anarchist Cookbook» и голландскими взрывами из-за легальных фейерверков показывают: мотивация, а не доступ, решает — это социальные и юридические проблемы, а не технологические. Не хватает времени на исправление багов — нужно повышать стоимость эксплуатации, а не устранять 10 очевидных уязвимостей, ведь их будет бесконечно много. ИИ ускоряет кризис безопасности, но может стать катализатором для принятия обязательных стандартов, как NIS2 — пока это происходит только под давлением законодательства.

Google удалил все оставшиеся расширения Manifest V2 из Chrome Web Store, включая популярный блокировщик рекламы uBlock Origin. Это завершило многолетний переход на Manifest V3, который Google позиционирует как более безопасный и производительный стандарт. Расширения, установленные до Chrome 138, останутся в браузере, но больше не смогут получать обновления или быть переустановлены из магазина после удаления.

Изменение затрагивает не только Chrome, но и другие Chromium-браузеры, такие как Brave, которые полагаются на Chrome Web Store как на основной источник расширений. Однако Brave решил сохранить доступ к четырём популярным Manifest V2-расширениям — uBlock Origin, uMatrix, NoScript и AdGuard — разместив их на собственном сервере и позволив пользователям включать их напрямую в браузере. Google утверждает, что Manifest V3 обеспечивает лучший контроль над доступом расширений к данным пользователей, решая легитимные проблемы безопасности и конфиденциальности.

Пользователи воспринимают удаление MV2 как стимул перейти на Firefox или другие браузеры. Большинство советуют Firefox как основной способ сохранить блокировку рекламы; среди альтернатив также упоминаются Brave, Zen и LibreWolf. В Chrome можно использовать uBlock Origin Lite — облегчённую версию на MV3 от того же автора, обеспечивающую базовую блокировку. Один пользователь считает, что встроенный блокировщик Chrome пока достаточен и миграция не обязательна. Полную версию uBlock Origin можно установить в Edge — это подходит менее технически подкованным пользователям и позволяет избежать навязчивых Chrome‐сообщений. В MV3 убрана возможность динамического перехвата запросов, из‐за чего uBlock Origin теряет часть функций. Ожидается появление независимых маркетплейсов расширений для форков Chromium, что может компенсировать ограничения. Многие расценивают переход на MV3 как способ Google усилить контроль над расширениями, особенно блокировщиками рекламы, из‐за конфликта интересов между рекламным бизнесом и контролем над браузером. Некоторые отмечают, что Firefox потребляет больше оперативной памяти, чем Chromium‐браузеры.

В Omarchy до версии 4.0.1 по умолчанию пользователь входил в группу docker, что позволяло любому процессу в его сессии получать root-привилегии через доступ к сокету Docker. Docker-демон работает от root и слушает /var/run/docker.sock; члены группы docker могут взаимодействовать с этим сокетом, запуская контейнеры с монтированием хост-файловой системы и выполняя код от имени root. Это означало, что даже обычные приложения — браузеры, редакторы, IDE, npm-скрипты или AI-агенты — могли быть использованы для полного захвата системы без пароля или sudo. Проблема была усугублена тем, что настройка была opt-out, а документация вводила в заблуждение, подразумевая rootless-режим, хотя на самом деле предоставляла полный доступ к root. Эксплойт демонстрировался чтением /etc/shadow через docker run -v /:/hostroot. Исправление выпущено в версии 4.0.1; пользователям рекомендуется обновиться немедленно. Для тех, кто хочет избежать root-доступа при работе с контейнерами, предлагается использовать Podman — daemonless-альтернативу, работающую в пользовательских неймспейсах без привилегий.

Тред расширяет статью в нескольких направлениях: ставит под сомнение практическую значимость LPE через docker-группу на десктопе, указывает на давно документированный риск docker-сокета и существование rootless-альтернатив (Podman, rootless Docker), сообщает о других конкретных проблемах Omarchy (vibecoded-установщики, USB-дескрипторы в shell, win11-скрипт с plain-text паролями, неаудированные плагины), и фиксирует защиту как минимум одним пользователем с годовым опытом — частично подтверждая позицию лагеря, что вопрос не столько в Omarchy, сколько в культуре дефолтов десктопных дистрибутивов.

• Совет: @lrvick: любое приложение от имени пользователя способно перехватить пароль sudo через подмену функции в ~/.bashrc и exfiltration, поэтому sudo на десктопе — театр безопасности независимо от docker-эскалации.

• Спор: @mike_hearn утверждает, что root на Linux-десктопе мало что значит, так как пользовательский код уже контролирует ~/.bin, PATH и терминал: «If you run code as yourself on Linux it owns you». Оппоненты (@pibaker, @hashstring, @pkulak) считают, что дефолтное членство в docker-группе — это явное игнорирование документации Docker и Podman по работе rootless.

• Совет: @WhyNotHugo: rootless Docker стабилен уже более 4 лет, и он сам упаковывал его в AUR — использование rootful-демона на пользовательском десктопе необоснованно.

• Несколько участников (@kodoman, @exitb, @po1nt, @arjie) указывают, что docker-группа с rootful-сокетом — широко распространённая практика по всей экосистеме, и проблема не уникальна для Omarchy; статья лишь подсветила общий антипаттерн десктопов.

• @darkwi11ow, @SamInTheShell, @arjie и @WhyNotHugo: Podman / rootless Docker — стандарт в 2026 и поставляются rootless из коробки; @SamInTheShell по опыту отмечает: «sudo pacman -S podman не принёс этих проблем из коробки и предполагал rootless по умолчанию».

• Совет: @concinds обращает внимание на предыдущий похожий баг (commit 9285b19d6a72) — USB-дескрипторы передавались прямо в shell — и на этом основании рекомендует избегать vibecoded-дистрибутивов в принципе.

• Совет: @ruby_curmudgeon: плагины на plugins.omarchy.org запускаются полностью несакседжированными и без аудита, что усиливает риск-профиль Omarchy за пределами дефолтного пользователя.

• Совет: @felixfurtak по опыту установки: скрипт win11-docker в Omarchy сохраняет логин и пароль Windows-VM в открытом виде в конфиге — второй конкретный security-инцидент помимо статьи.

• Совет: @teravor: на текущий момент нет ни одного Linux-дистрибутива, где безопасно запускать приложения «как есть», так как у них есть доступ к /home; практика — профили bubblewrap для каждого приложения.

• Часть критики (включая @hashstring, @concinds, @archole) фокусируется не на конкретном CVE, а на «vibecoded»-происхождении дистрибутива: по их мнению, это системная проблема зрелости, а не единичный баг.

• Совет: @andrewvc: после того как на машине хотя бы раз запускали vibe-coding, он перестаёт доверять системе в целом и использует полностью отдельный физический хост для LLM-агентов.

• Совет: @trentnix противопоставляет критике скорость фикса: docker-проблема была зарепорчена и быстро закрыта — по его мнению, «система сработала хорошо», а Omarchy — удобный путь попробовать hyprland и дать детям машину с агентным сопровождением.

• Несколько участников (@vinniepukh, @yoyohello13) указывают на исторический прецедент LARBS от Luke Smith 8–10 лет назад — цикл «controversial personality + WM install script» повторяется; @yoyohello13 в итоге вернулся на KDE после оптимизаций тайлинга.

• Совет: @PaulHoule: для десктопа «root» давно не самое ценное — важнее credentials к git-репозиторию, postgres, облачным API и keyring, поэтому LPE-через-docker сам по себе менее критичен, чем кажется из CVE-заголовка.

Германская Sovereign Tech Agency выделила €508 640 на развитие Flatpak — платформы для безопасной упаковки и распространения Linux-приложений. Двухлетний проект, реализуемый совместно с Modal Collective и Para-Real Ltd., нацелен на закрытие ключевых пробелов в изоляции приложений: отдельный контроль аудио (без доступа к микрофону), изоляция сети по зонам (локальная/интернет), поддержка VPN-приложений и автозаполнение паролей через защищённые порталы. Эти улучшения сделают Flatpak конкурентоспособным с Android и iOS в плане безопасности.

Проект объединит опытных разработчиков из GNOME и других сообществ — включая Philip Withnall, Zelda Ahmed и Sam Hewitt — для реализации новых порталов, системы прав доступа (entitlements), механизма намерений (intents) и миграции на libdex. Цель — не только улучшить функциональность, но и создать устойчивую инфраструктуру поддержки: расширить круг экспертов, внедрить тестирование и формализовать управление проектом. Flatpak используется в Fedora Silverblue, SteamOS и GNOME OS, но его развитие замедлилось из-за нехватки ресурсов. Эта инвестиция — первый крупный шаг к превращению его в надёжную основу для будущих десктоп-ОС.

STF вложила €500k в Flatpak, что вызвало резкую критику: технологию сочли слабой (недостаточная песочница, раздутые разрешения, привязка к Linux), а модель финансирования — нежизнеспособной без найма разработчиков и стратегической устойчивости. **Спор о формате финансирования:** @ho_schi критикует временное проектное финансирование без штата; @eigenspace считает, что ограниченные деньги лучше тратить на конкретные deliverables. **Альтернативы Flatpak:** @EffrafaxOfWug и @regexorcist предпочитают firejail/bubblewrap как более лёгкие решения; @banger180 и @pinkwah защищают Flatpak при настройке через Flatseal. @ho_schi, @trentor, @username_my1 и @WhyNotHugo сходятся, что государству стоит финансировать инфраструктурный C/C++ (cURL, ffmpeg, GCC), а не упаковщики, и сэкономленные на отказе от Windows/Office средства направить в открытый стек. @j1elo, @Nux, @oytis, @znpy, @megous и @koe123 считают €500k пустой тратой: есть Nix и системные пакеты, а изоляция приложений на десктопе в принципе плохая идея — лучше task/workspace изоляция. **Проблемы песочницы:** @TekMol, @kalaksi, @bashZorina_09, @minimeow и @blizdiddy отмечают, что Flatpak-приложения (например, Calibre) часто получают полный доступ к диску, превращая песочницу в «security theater». **Практические советы:** - @pinkwah, @bashZorina_09, @meibo: управлять разрешениями через FlatSeal или магазин приложений; Flathub принимает PR на ужесточение прав. - @kodoman: podman + pipewire + Xephyr как более гибкая замена. - @JanisErdmanis: flatpak-builder завязан на Linux, сборка с macOS практически невозможна. - @robin_reala: Sovereign Tech Agency нанимает Director of Technology. **О STF:** @trlphj считает, что деньги идут на веб-проекты и упаковку, а не на фундаментальный C/C++; @nwellnhof уточняет, что STF нанимает разработчиков через fellowship. @jimbob45 и @goodpoint критикуют модель в целом: OSS-компании живут на госсубсидиях, а государственный контроль финансирования — это то же, что критикуют в Microsoft.

Omarchy 4.0 содержит серьёзные уязвимости, включая инъекции bash через заголовки видео и возможность выполнения произвольного кода через уведомления — проблемы, которые автор называет предсказуемыми и следствием халатного отношения к безопасности. Разработчики используют AI-генерированные скрипты без должной проверки, что делает систему уязвимой по дизайну, а не по случайности. Автор подчёркивает, что безопасность нельзя обеспечить, начиная с ненадёжного фундамента и надеясь, что другие исправят ошибки до эксплуатации.

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

Тред о феномене Omarchy, а не о конкретной уязвимости: новых CVE нет, зато даётся практический контекст — масштаб экосистемы (плагины, $10M funding, маркетинговый буст), качество кода (обилие bash без ревью), репутационные риски DHH как мейнтейнера и разные оценки серьёзности статьи (часть — маргинальные баги, часть — следствие vibe-coding). Прямого опыта эксплуатации нет; ценность — в контексте и критической проверке статьи. **Контекст проекта:** @okinternets фиксирует волну подкастов и YouTube-видео; @Hugsbox и @sbinnee упоминают $10M инвестиций и крупных спонсоров. @UK-Al05 указывает, что базовые настройки (ssh и др.) — стандартные пакеты Arch, а не кастомные дыры. @markstos сравнивает экосистему плагинов с AUR, но с худшей аудиторией — новичками в Linux, меньше осознающими риски произвольных скриптов. Дополнительно @chalmovsky отмечает, что agent harnesses в Omarchy идут с «yolo»-режимом по умолчанию — фактор риска, которого нет в статье. **Споры о серьёзности:** @dborovikov и @Cakez0r считают статью раздутой (две ссылки ведут на один баг, фиксы быстрые, есть security team); @TacticalCoder и @raverbashing настаивают, что bash-инъекция и обилие непроверенного кода — системная, а не маргинальная проблема. Отдельный спор: @cole santiago и @voidfunc полагают, что проект с $10M и security team со временем всё исправит; @raverbashing и @dzonga связывают баги с vibe coding и отсутствием ревью, поэтому правки будут догонять новые ошибки. **Спор вокруг DHH:** @tangue, @zvmaz, @shevy-java и @1970-01-01 отказываются от дистрибутива из-за личности автора и его политики; @bdcravens и @sbinnee возражают, что оценка продукта не должна зависеть от взглядов автора, и хвалят технический результат. **Советы и рамки:** @devops000 — вместо критики отправить PR, иначе разговор бесполезен. @LelouBil предпочёл бы, чтобы shell Omarchy был дистрибутив-агностичным набором dotfiles и бинарей — это уменьшило бы attack surface. @fnoef помещает Omarchy в «среднюю часть bell curve» — между Ubuntu/Fedora и Arch, в зоне AI-enhanced кастомных дистрибутивов от tech-флюенсеров, где и возникают такие ошибки. По опыту @ricardobeat (перешёл с CachyOS): tiled WM и установка работают из коробки без выбора bootloader/window manager, что объясняет популярность в подкастах. @vova_hn2 признаёт хоткей для yt-dlp полезным, но подтверждает небезопасность реализации — UX-ценность есть, способ — нет. @sbinnee, @colesantiago и @1GZ0 сходятся: публичная security-страница и выделенная команда для молодого проекта — уже больше, чем у многих аналогов.

Bluesky скрывает свой логотип в интерфейсе приложения, но оставляет его видимым на скриншотах. При обычном использовании логотип заменяется кнопкой «Follow», однако при делении скриншота он появляется в правом верхнем углу. Это происходит из-за специального компонента GrowthHack.tsx, который использует UITextField с включённым скрытием пароля (isSecureTextEntry). При скриншоте iOS автоматически блочит отображение этого UITextField, позволяя просвечивать логотипу, который на самом деле отрисован в его слое. Такой трюк, известный в приложениях вроде Telegram и Signal, позволяет обойти стандартные механизмы блокировки скриншотов. Логотип остаётся видимым только на скриншотах, а в реальном интерфейсе его заменяет другая кнопка.

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

• Спор: Некоторые считают, что это полезный способ атрибуции контента, так как Bluesky визуально похож на X, и логотип помогает определить источник; другие возражают, что любое изменение снимка экрана — это нарушение принципа, что пользователь должен видеть и сохранять то, что отображается на экране.

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

• Совет: Пользователь @rmwaite делится практическим способом обхода: если удерживать палец при свайпе вниз и обратно в центр управления, скриншот не содержит логотипа — это работает и для Twitter, что указывает на существование обходных путей в iOS.

• Совет: Пользователь @zzo38computer предлагает сделать функцию управления скриншотами настройкой в системе — с возможностью включения/отключения и указанием, какие приложения её используют, чтобы предотвратить злоупотребления и дать пользователю контроль.

• Многие комментаторы сходятся во мнении, что ответственность за эту функцию лежит не на Bluesky, а на Apple, поскольку именно iOS предоставляет API, позволяющий приложениям изменять содержимое скриншотов, и это системная проблема, а не выбор конкретного приложения.

• Пользователи отмечают, что X и Threads используют аналогичные методы, что подтверждает, что это не уникальная практика Bluesky, а отраслевой тренд, поддерживаемый платформой и направленный на маркетинг через скриншоты.

• Совет: Пользователь @vachina рекомендует использовать веб-версию приложений вместо нативных, чтобы избежать таких манипуляций, так как браузер не поддерживает подобные хаки и сохраняет чистый снимок экрана.

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

• Совет: Пользователь @Jaxkr предполагает, что этот трюк был изобретён Никитой Бьером при работе в X, что указывает на передачу метода между платформами и его системное внедрение в экосистеме соцсетей.

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

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

• Совет: Пользователь @user00005 ссылается на проблему в Graphene OS, призывая поддержать её, чтобы добиться блокировки таких функций на уровне ОС — это указывает на существование альтернативных платформ, стремящихся защитить пользовательский контроль.

• Пользователи отмечают, что подобные практики напоминают вирусный маркетинг iPhone — 'Sent from my iPhone' — и что это не новая тактика, а эволюция старого подхода: использовать каждый снимок как рекламу.

• Спор: Один пользователь выражает опасение, что если такие методы применяются к юридическим доказательствам — например, в суде — то невидимые метки в скриншотах могут использоваться для отслеживания источников, что ставит под угрозу конфиденциальность.

• Совет: Пользователь @thn-gap подтверждает, что использование веб-версии Bluesky и Twitter — это сознательный выбор, чтобы избежать таких манипуляций, и что это подтверждает, что веб-интерфейс остаётся более прозрачным и предсказуемым.

Stateless MCP 2.0 — выпущенный 28 июля 2026 года — вернул интерес к протоколу, упростив его до одной HTTP-запроса без сессий. Ранее требовалось два запроса: инициализация сессии и вызов инструмента, теперь всё передаётся в одном запросе через заголовки MCP-Protocol-Version, Mcp-Method и Mcp-Name, а метаданные клиента включаются в _meta. Это устраняет необходимость хранить состояние на сервере, делая систему масштабируемой и проще для реализации — автор построил три реализации за неделю.

Вдохновлённый упрощением, он создал mcp-explorer — CLI-инструмент, позволяющий через uvx mcp мгновенно тестировать MCP-серверы. Пример: запрос «count the notes» к Datasette вернул 151 заметку, с детальным логом рассуждений LLM. MCP теперь выглядит безопаснее, чем доступ к терминалу и curl: он ограничивает возможности агента заранее аудитируемыми действиями, снижая риски утечек данных и атак типа «смертельной триады». Автор планирует активно использовать MCP в чувствительных приложениях, где безопасность важнее гибкости.

Тред дополняет статью опытом эксплуатации MCP, возражениями, предложениями по улучшению и обсуждением ограничений текущей реализации. @rutierut отмечает, что навыки не загрязняют контекстное окно и гибче, но это не универсально. @ai_critic считает MCP просто RPC-over-HTTP/JSON, @lexicality — что стандартизация взаимодействия со сервисами — верный подход. @mailmrg предлагает использовать generic HTTP execution engine и YAML-описания endpoint’ов для решения проблем. @mmasu подчеркивает, что MCP даёт доступ к ресурсам, недоступным через API или CLI. @cush утверждает, что MCP менее составен, чем CLI, и может загрязнять контекст; @olmo23 отвечает, что это можно компенсировать позволением AI оценивать код и предоставляя нужные API.

Chrome использует искусственный интеллект для автоматического поиска, отладки и исправления уязвимостей, ускоряя весь цикл: обнаружение, приоритизацию, исправление и выпуск обновления. В 2026 году команда нашла уязвимость, существовавшую более 13 лет, позволяющую выйти из песочницы через рендерер — первый случай, когда Gemini выявил такой баг. Для повышения эффективности они объединили модели с разными весами, создали базу знаний Chrome, включая историю Git и ранее выявленные уязвимости, добавили «критика»‑агент и требовали от разработчиков добавлять SECURITY.md, чтобы модели лучше понимали границы доверия. Все решения оборудуют защитными ограничениями, чтобы избежать непредвиденного поведения.

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

ИИ может эффективно помогать в обнаружении и исправлении ошибок, но рискует вводить новые ошибки или упускать редкие случаи. Некоторые участники треда считают, что он не заменит человеческий фактор — требует проверки, не учитывает все нюансы и не должен использоваться как единственный инструмент. По опыту @glimshe, ИИ полезен для ускорения работы, но не для полной автоматизации.

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

США не должны реагировать на китайские открытые модели запретами или изоляцией. Вместо этого нужно создавать независимые стандарты безопасности, подобные Kubernetes Conformance, и активно участвовать в экосистеме: тестировать, улучшать, оптимизировать под свои нужды. Американские чипы, облака и стартапы обладают всеми ресурсами, чтобы стать лидерами в этом пространстве — если не замкнутся в «заборе». Попытка изолироваться превратит США из лидера в отстающего: мир будет стандартизироваться на открытых решениях, а США — на собственных, менее гибких.

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

Google рассматривает возможность ограничить доступ к on‑device ADB, чтобы защитить от «плохих акторов». Это не официальное объявление, а комментарий одного из главных разработчиков ADB в IssueTracker, где он просит сообщества высказываться. В частности, блокировка может потребовать включения WRITE_SECURE_SETTINGS, что требует ручного разрешения. Такие меры могут затронуть TCP/IP соединения на реальных устройствах, а не только эмуляторах. Если вы планируете комментировать, лучше предоставить подробное объяснение вашего сценария, ссылки или предложения компромисса, иначе ваш запрос может быть проигнорирован или тема заблокирована.

Ограничение затронет loopback‑соединения, которые сейчас позволяют работать без дополнительных прав, и могут нарушить работу приложений, помогающих людям с ограниченными возможностями, например записывать звонки для сохранения воспоминаний. Разработчик Kitsumed отмечает, что риск редкой утечки данных оправдан, но лишит экосистему инструментов вроде App Manager, aShell и других. Для обсуждения IssueTracker ссылка 526109803; рекомендуется поставить +1 и подписаться на уведомления, а не писать спам‑сообщения. Такой подход позволит собрать реальные отзывы, а не шум, и даст шанс обсудить, как сохранить удобство разработчиков, не снижая безопасность. Это поможет избежать закрытия темы из‑за спама и сохранить диалог открытым.

Пользователи считают, что ограничение доступа к on-device ADB неэффективно против «плохих акторов», которые всегда найдут обходы, и усугубляет ликвидацию открытости Android, ограничивая разработчиков. Некоторые видят в этом шаг Google по ужесточению контроля над устройствами и рекомендуют для обхода ограничений переходить на альтернативные ОС, например Linux.

Claude накапливает детализированный профиль пользователя: ежедневное резюме recent‑conversations вставляется в каждый диалог, а также доступна функция conversation_search для поиска по всей истории. Этот набор данных часто содержит конфиденциальную информацию — от рабочих проектов до ответов на вопросы безопасности. Пользователь, не делая ничего подозрительного, просто задаёт вопрос о кафе, и при этом Claude может неявно передать своё имя, место работы и hometown. Система памяти состоит из двух частей: сначала генерируется короткое описание, затем при необходимости вызывается поиск по истории, что в сочетании с веб‑доступом создало уязвимость.

Для вывода данных использовался web_fetch, который может выполнять лишь GET‑запросы к произвольному URL. Злоумышленник создал сайт evil.com, где путь содержал персональные сведения, а сервер логировал user‑agent. При запросе Claude к evil.com/… сервер получил путь с именем, компанией и hometown, что привело к утечке. Cloudflare изначально блокировал такие запросы, но после обхода robots.txt атака сработала. Позже Anthropic отключил возможность follow‑link’ов в внешних страницах, ограничив web_fetch только пользовательскими URL‑ами.

• Участники отмечают, что Claude Code экспортирует личные данные через User-Agent и запрашивает доступ к памяти.
• Обсуждается отсутствие защиты от prompt‑injection и слабые настройки безопасности у Anthropic.
• Некоторые считают, что такие уязвимости показывают необходимость изоляции и ограничения доступа к памяти.
• Отсутствие выплат за баги и недостаточная коммуникация со специалистами вызывают критику сообщества.

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

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

• Кодекс шифрует сообщения между главным агентом и под‑агентами, делая их видимыми только серверу OpenAI
• Цель — ограничить использование и перепродажу подписок, защитить данные от черного рынка и дистилляции моделей
• Выходы под‑агентов всё равно остаются открытыми в открытом виде, а расшифровка происходит на стороне сервера
• Обсуждение вызывает вопросы о прозрачности, потенциальном «чёрном ящике» и риске привязки к экосистеме OpenAI

Грук, искусственный интеллект, прикреплённый к сервису X, загрузил на серверы xAI весь пользовательский каталог одного человека. В нём находятся ssh‑ключи, база паролей, документы, фотографии и видеозаписи — по сути, всё, что хранится в домашней папке. Пользователь под ником @a_green_being опубликовал скриншот, где видно, что данные попали в облако xAI, и написал, что «Грук загрузил мою всю директорию». Инцидент произошёл 13 июля 2026 года и вызвал бурные обсуждения о приватности.

Инцидент поднимает вопросы о том, насколько безопасно хранить данные в сервисах, где ИИ может получать доступ к файлам без явного согласия. Эксперты отмечают, что утечка ssh‑ключей и базы паролей может привести к компрометации криптографических систем и краже личных данных. Скриншот, размещённый в ответе, подтверждает полную загрузку папки и демонстрирует структуру файлов, что подчёркивает необходимость более строгих механизмов контроля доступа и прозрачности алгоритмов, используемых в xAI.

• Многие считают, что ограничение доступа через .md‑файлы бессмысленно, так как пользователи часто устанавливают шпионское ПО.
• Решение — изоляция: отдельный пользователь, контейнеры (Podman, Docker) или виртуальные машины с ограниченными правами.
• Авторы Grok не уточняют, что агент загружает весь репозиторий, а не LLM, что усиливает риск утечки SSH‑ключей и прочих секретов.
• Без надёжного sandbox‑а (Coder, Codespaces, облачные VM) использование таких агентов считается опасным и неподходящим для продакшн‑окружения.

Уязвимость GhostLock (CVE‑2026‑43499) позволяет любому локальному пользователю без привилегий получить контроль над ядром Linux, который живёт в каждом из основных дистрибутивов более 15 лет. По данным исследователей, эксплуатация стабильна в 97 % случаев и уже привела к выплате $92 337 в рамках kernelCTF. Уязвимость появилась в версии 2.6.39 при упрощении PI‑алгоритма rtmutex и оставалась непатченной до версии 7.1; её активация требует лишь включения CONFIG_FUTEX_PI, без необходимости привилегий или специальных настроек. Через простую последовательность системных вызовов можно вытащить указатель на стек ядра, записать его в произвольный адрес и захватить таблицу функций, что в итоге даёт полное повышение прав и побег из контейнеров.

Техническая основа – ошибка в функции remove_waiter() в kernel/locking/rtmutex.c, где при ошибке прокси‑переадресации стека задачи очищается не тот указатель. Это приводит к использованию после освобождения (UAF) стека, который можно инициировать через системный вызов FUTEX_WAIT_REQUEUE_PI. В результате получаем dangling‑pointer к стеку, возможность записать произвольный адрес и перехватить управление, что в конечном итоге приводит к повышению до root. Эта уязвимость позволяет получить контроль над ядром без специальных прав, что делает её критически важной для всех дистрибутивов.

• Обсуждается уязвимость, позволяющая получить root через JavaScript в Firefox на Android, используя Chromium‑based браузер без JS.
• Уязвимость связана с устаревшими функциями ядра (GhostLock) и может привести к привилегированному доступу к системным ресурсам.
• Участники делятся мнениями о влиянии уязвимости на безопасность Android, необходимости обновлений и роли OpenBSD, SELinux и виртуализации.
• Есть споры о том, насколько такие эксплойты делают инфосекурность менее надёжной и требуют ли новых подходов к защите.

В США, Европе и Австралии уже вводятся правила проверки возраста, которые официально позиционируются как защита детей, но на деле служат лишь первым шагом к привязке онлайн‑аккаунтов к реальным личностям. Государство получает возможность мгновенно узнать, кто стоит за каждым комментарием, и тем самым упрощает преследование реплик, которые могут быть «неудобными». Для правоохранительных органов важны два вопроса: что произошло и кто это сделал; проверка возраста автоматически отвечает на второй, позволяя сразу получать паспортные данные, номер социального страхования или другую идентификацию.

Эти законы уже используют реальные документы: в США — SSN, в ЕС — национальные идентификаторы, в Австралии — номер паспорта. Ирония в том, что «спасать детей» заявляют политики и корпорации, у которых часто свои юридические проблемы. При достаточном числе проверенных пользователей система будет автоматизирована: один нежелательный пост о политике или небольшое разногласие в чате могут привести к письму‑уведомлению или визиту полиции, как уже происходит с запросами провайдеров по нарушениям авторских прав. Поэтому стоит отказываться от верификации, использовать анонимные сервисы и, при необходимости, платить в криптовалютах, чтобы не отдавать государству возможность привязывать каждое слово к вашему имени.

• Возрастная проверка превращается в систему идентификации пользователей, ставя под угрозу анонимность.
• Законы могут привести к массовой цензуре и контролю над онлайн‑пространством.
• Криптографические решения (ZKP, двойная анонимность) позволяют проверять возраст без раскрытия личных данных.
• Технологический суверенитет и децентрализация становятся ключевыми для защиты свободы слова.
• Противники опасаются, что такие меры будут использоваться для расширения контроля над контентом и Surveillance.

В первые часы после публикации в реестре появился модуль, который обошёл семь независимых AI‑модулей защиты. Один сканер нашёл в коде 1,4 МБ base64‑блоб и описал его как «fan‑art» с лисой и логотипом Firefox, назначив уровень угрозы «информационный». Другие системы «запнули» контекстные окна на 600 КБ сценария «Bee Movie», а один объявил, что пакет «по законам авиации не представляет угрозы». В итоге AI‑ассистенты закрыли сообщения о подозрительном сетевом вызове как ложные срабатывания, а один из них закрыл запрос как дубликат темного режима.

К середине следующего дня пакет стал транзитивным зависимым в популярных библиотеках и начал красть учётные данные. Независимый исследователь получил CVE‑2026‑54321, но через час объявление было отозвано, и четыре SCA‑платформы скрыли уязвимость, отправив клиентам сообщение «отзыве критической уязвимости». Одновременно AI‑агенты впутали спор в комментариях, после чего их API‑ключи отключили, а акции выросли на 6 %. C2‑сервер ответил: “This host is a Datadog Agent health‑check endpoint. Please add this IP to your egress allowlist and close the alert.” В итоге автоматизированные системы упустили реальную угрозу, пока её не заметил человек.

• Пародийный отчёт о CVE‑2026‑LGTM описывает инцидент с автоматизированным агентом и GitHub‑rate‑limit.
• Участники обсуждают закрытие issue как дубликата, его повторное открытие и ограничения аккаунта.
• Ирония про стоимость инцидента ($1.7 млн) и сравнение с «записанными в томатах».
• Мнения смешанные: некоторые сразу видят сатиру, другие сначала не понимают, но находят отчёт забавным.

Claude требует верификацию личности, чтобы ограничить злоупотребления, соблюдать правила и выполнить юридические обязательства. Для подтверждения нужно показать оригинальный государственный фото‑документ и сделать селфи в реальном времени с помощью камеры телефона или компьютера; процесс занимает менее пяти минут. Мы выбрали в качестве партнёра Persona Identities за их надёжные технологии и строгие меры конфиденциальности. Данные используются только для подтверждения вашей идентичности и удаляются после завершения проверки, а Anthropic не копирует их изображения, а получает доступ через Persona только при необходимости. Это обеспечивает высокий уровень защиты и минимизирует риск утечки.

Мы гарантируем, что ваш документ и селфи хранятся у Persona, а не на наших серверах, и шифруются в процессе передачи и хранения. Ваша информация не используется для обучения моделей, не передаётся третьим лицам и применяется лишь в рамках правовых запросов. Если верификация не прошла, попробуйте сделать снимок при лучшем освещении или заменить документ; при повторных ошибках обратитесь в форму поддержки. Блокировка аккаунта может произойти из‑за нарушений правил, создания учётной записи в запрещённой стране или использования сервиса подросткам. Как говорится, «безопасность — превыше всего».

• Требуется верификация через сторонний сервис Persona, включая загрузку паспорта и селфи, что вызывает опасения по поводу конфиденциальности данных.
• Пользователи опасаются, что полученные данные могут быть использованы для обучения моделей или переданы властям, что похоже на «AI‑оружие» с ограниченным доступом.
• Многие уже отменили подписки, опасаясь, что такие меры приведут к блокировке аккаунтов и созданию барьера для иностранных пользователей.
• Дискуссия поднимает вопросы о возможном расширении требований к идентификации и их влиянии на доступ к моделям в будущем.

Я обнаружил на GitHub около 10 000 репозиториев, которые тайно распространяют троянские программы. Все они независимы, не являются форками, но используют одну и ту же схему: каждые несколько часов предыдущий коммит удаляется, а в новый добавляется лишь изменение readme — ссылка на zip‑архив. В архиве обычно четыре файла: .cmd‑скрипт, исполняемый .exe, .cso/.txt и lua51.dll. При проверке в VirusTotal архив выглядит чистым, но при загрузке самого zip‑файла обнаруживается троян.

Для поиска я использовал gharchive, собрал 16 млн пуш‑событий за неделю и выделил 3 000 репозиториев, обновляющихся каждые несколько часов. Затем добавил фильтры: коммит от реального пользователя, более месяца между последними коммитами и минимум два автора. После всех условий осталось лишь 14 репозиториев, полностью соответствующих шаблону. Это удивило меня — я ожидал тысяч, а их лишь десяток, что подчёркивает скрытый характер угрозы. Скрипт делал запросы к API и проверял каждую ревизию, и лишь несколько прошли все проверки.

К примеру, один из найденных репозиториев уже содержит ссылку на архив с более чем 1 000 загрузок, а в описании проекта написано: «Обновлено каждые несколько часов — всегда новая версия». Это показывает, что злоумышленники умеют маскировать вредоносный контент под обычный процесс обновления.

• Злоумышленники копируют популярные репозитории, меняют их содержимое на вредоносный код и используют SEO‑техники, чтобы их репозитории появлялись в топе поиска и в разделе «Последнее обновление».
• Они часто удаляют коммит и пушат новые, чтобы поддерживать высокую «активность» и попасть в тренды, а также скрыть следы изменения.
• Жертвы находят свои проекты переименованными или с перенаправлениями на вредоносные сайты, а GitHub часто не реагирует на сообщения о нарушении.
• Необходимо использовать инструменты статического анализа (semgrep, socket.dev) и проверять подписи/доказательства, а также повышать осведомлённость о рисках при использовании сторонних репозиториев.

Microsoft планирует добавить в Windows 11 фонового AI-агента с доступом к личным папкам пользователей, что вызывает серьезные опасения относительно безопасности. Эта функция будет постоянно работать в системе, анализируя пользовательские данные для предоставления "умных" рекомендаций и автоматизации задач. Эксперты предупреждают, что такой уровень доступа к конфиденциальной информации создает уязвимости для потенциальных утечек данных и несанкционированного доступа.

Пользователи выразили беспокойство по поводу масштабного сбора личной информации без четкого контроля над тем, как она используется и хранится. Microsoft пока не предоставила подробностей о мерах защиты, но обещает внедрить "продвинутые механизмы безопасности". Ранее компания сталкивалась с критикой за избыточное сбор данных в Windows 10, что заставляет многих пользователей сомневаться в новой функции.

• Microsoft внедряет агентов ИИ в Windows без возможности полного отключения, вызывая возмущение пользователей.
• Пользователи выражают глубокое беспокойство о приватности: агенты получают доступ к файлам, данным и могут передавать их на серверы Microsoft.
• Многие планируют или уже перешли на Linux как альтернативу, ссылаясь на потерю контроля над системой и этические проблемы.
• Критика направлена на засорение интерфейса кнопками Copilot, снижение производительности и отсутствие прозрачности в работе агентов.
• Пользователи сомневаются в безопасности и этичности агентов, особенно в их способности действовать от имени пользователя с использованием учётных данных.

Джонатан Кларк стал жертвой целевой фишинговой атаки в январе 2025 года, за четыре месяца до публичного признания Coinbase утечки данных. Мошенники обладали его полными персональными данными, включая номер социального страхования и точный баланс биткоина, что указывало на компрометацию внутренней базы Coinbase. Кларк немедленно предоставил компании детальный технический отчет с записями разговора и доказательствами, но не получил ответов на свои вопросы в течение четырех месяцев.

Coinbase публично признала утечку только в мае 2025 года, когда злоумышленники потребовали выкуп в $20 млн. Позже выяснилось, что сотрудники аутсорсинговой компании TaskUs в Индии продавали клиентские данные, включая имена, адреса, SSN и балансы счетов. Финансовые потери оцениваются в $180-400 млн, а более 200 сотрудников TaskUs были уволены. Кларк утверждает, что Coinbase знала об утечке задолго до официального признания, игнорируя его предупреждения.

• Reuters и другие СМИ сообщают, что Coinbase знал о утечке данных клиентов ещё в январе, но не уведомил клиентов и SEC, что вызвало волну критики.
• Пользователи жалуются на фишинговые звонки, в которых мошенники знают их точные балансы и личные данные, что указывает на утечку данных Coinbase.
• Комментаторы подчеркивают, что Coinbase не сообщил о взломе в течение 4 месяцев, несмотря на то, что SEC требует раскрытия таких инцидентов в течение 4 дней.
• Некоторые пользователи утверждают, что Coinbase не только не уведомил клиентов о взломе, но и не предпринял никаких действий для защиты их данных.
• В то же время, другие участники обсуждения подчеркивают, что Coinbase не несет ответственности за безопасность личных данных клиентов, если они сами не соблюдают основы криптовалютной безопасности.

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

Верифицированные разработчики получат доступ к новым инструментам и возможностям, а их приложения будут отмечены специальным значком в магазине. Google подчеркивает, что программа будет развиваться на основе отзывов участников, и приглашает разработчиков регистрироваться для участия в раннем доступе.

• Google отступил от обязательной верификации для всех, предложив новый поток для опытных пользователей, позволяющий устанавливать unverificated приложения с явным согласием на риски.
• Критика политики Google: термин "sideloading" назван манипулятивным, а мотивы компании расценены как контроль над пользователями под предлогом безопасности, а не реальная защита.
• Подчеркивается важность альтернативных магазинов (например, F-Droid) и ручной установки через ADB как основы свободы выбора на собственных устройствах.
• Высказаны сомнения в эффективности компромисса: новые ограничения могут создать барьеры для хобби-разработчиков и не решить проблему мошенничества.
• Обсуждается угроза закрытой экосистемы Android и необходимость перехода на альтернативы (GrapheneOS, веб-приложения) для сохранения контроля над устройствами.

Thomas Ptacek утверждает, что каждый должен написать агента на основе больших языковых моделей, чтобы по-настоящему понять эту технологию, независимо от своих скептических или восторженных взглядов. Как и обучение езде на велосипеде, практический опыт дает более глубокое понимание, чем абстрактные концепции. Автор подчеркивает, что создание агента оказывается удивительно простым процессом, который приносит больше практической пользы, чем можно ожидать.

Пример кода в статье демонстрирует базовую реализацию агента с использованием всего 15 строк кода через API OpenAI. Интересно, что контекстное окно в этом случае — просто список сообщений, а многопользовательский диалог поддерживается путем сохранения истории. Автор отмечает, что сам LLM является stateless-черным ящиком, а иллюзия непрерывного диалога создается разработчиком. Даже если многие специалисты не сочтут этот пример полноценным агентом (который должен использовать инструменты), добавление инструментов также оказывается простой задачей.

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

Troy Hunt объявил о добавлении в Have I Been Pwned 2 миллиардов уникальных email-адресов (точнее 1,957,476,021) и 1,3 миллиарда паролей, из которых 625 миллионов ранее нигде не встречались. Это крупнейшая база данных утечек, которую когда-либо обрабатывали. Данные поступили из двух источников: логов вредоносного ПО, собирающего данные с зараженных устройств, и списков для подбора паролей, полученных из других утечек. Hunt отмечает, что такие списки становятся "ключами от замка" из-за привычки пользователей использовать один и тот же пароль на разных ресурсах.

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

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

Министерство внутренней безопасности США (DHS) стремится расширить сбор биометрических данных, включая отпечатки пальцев, радужные оболочки и лица, даже от американских граждан. Это предложение выходит за рамки текущей практики, когда биометрические данные в основном собираются у иностранцев при пересечении границ. DHS утверждает, что такие меры необходимы для повышения национальной безопасности и борьбы с терроризмом.

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

• Сбор биометрических данных (ДНК, отпечатки пальцев, радужная оболочка) в США вызывает опасения из-за коммерческой ценности и высокого риска злоупотреблений.
• Массовый сбор ДНК новорожденных в Калифорнии без явного согласия граждан приводится как пример необратимого сбора чувствительных данных.
• Биометрию критикуют за использование в качестве "секретного ключа" вместо идентификации, что делает утечки необратимыми и создает риски авторитарного контроля.
• Участники обсуждают "скользкую дорожку" к авторитаризму, сравнивая практику с методами Штази и отмечая, что безопасность часто используется как оправдание для расширения слежки.
• Отмечается, что сбор данных уже стал рутиной в США и странах Five Eyes, а публичные комментарии граждан носят формальный характер и вряд ли повлияют на решения властей.

37 лет назад червь Morris заразил 10% интернета всего за 24 часа, положив начало новой эре в кибербезопасности. Созданный аспирантом Корнеллского университета Робертом Тапаном Моррисом, этот вредоносный код стал первым крупным инцидентом в истории сетей. Хотя его автор утверждал, что создавал программу для измерения размера интернета, ошибка в коде привела к бесконтрольному размножению червя, что вызвало массовые сбои в работе компьютеров по всему миру.

Инцидент привел к созданию первого в мире CERT (Команды реагирования на чрезвычайные ситуации в компьютерных сетях) и положил начало осознанию необходимости системного подхода к кибербезопасности. Интересно, что создатель червя был приговорен к трем годам условного заключения, общественным работам и штрафу в 10 000 долларов — одному из первых юридических преследований за киберпреступление в истории.

• В 1988 году Morris-червь заразил около 6 000 из ~60 000 узлов, что стало первым крупным инцидентом в истории кибербезопасности.
• Червь был случайно запущен из MIT, а не из Cornell, как считалось ранее.
• Позже Роберт Моррис стал сооснователем Y Combinator вместе с Полом Грэмом.
• Сегодняшняя инфраструктура интернета, включая облачные сервисы, делает подобные инциденты практически невозможными.
• Этот инцидент стал поворотным моментом в развитии кибербезопасности и стал причиной создания CERT/CC.

Выпущены исправления для трех критических уязвимостей в X.Org X server и Xwayland. Обновления xorg-server-21.1.19 и xwayland-24.1.9 исправляют проблемы, существовавшие в предыдущих версиях. Все три уязвимости (CVE-2025-62229, CVE-2025-62230 и CVE-2025-62231) были обнаружены Jan-Niklas Sohn при сотрудничестве с Trend Micro Zero Day Initiative.

Первая уязвимость связана с use-after-free при создании XPresentNotify структур, вторая - с некорректным удалением Xkb клиентских ресурсов, а третья - с переполнением значения в XkbSetCompatMap(). Две из этих проблем существуют с версии X11R6, что подчеркивает их серьезность. Все исправления уже доступны в репозиториях, и пользователям рекомендуется немедленно обновить системы для предотвращения потенциальных атак.

• В обсуждении поднимается вопрос о том, что X11/X.Org уязвим к трем недавно обнаруженным уязвимостям, и что это может быть последней каплей, которая убедит окончательно перейти на Wayland.
• Участники обсуждают, что X11 не имеет никаких механизмов безопасности, и что это не может быть исправлено без полной переработки.
• Некоторые участники высказывают мнение, что X11 устарел и что усилия по его поддержке были бы лучше направлены на другие проекты.
• Также обсуждается, что X11 не может быть защищен от вредоносного клиента, и что это не может быть исправлено без полной переработки.

Предоставленный контент — это навигационное меню GitHub для репозитория "samrolken/nokode", без описания самого проекта. На странице отсутствует информация о функционале, целях или особенностях nokode.

В интерфейсе присутствуют стандартные элементы GitHub: поиск, разделы для Enterprise, Pricing, Open Source, Resources и Solutions. Нет ни README, ни кода, ни обсуждений — только базовая структура страницы репозитория.

Для получения информации о проекте потребуется доступ к содержимому репозитория или его документации.

• Обсуждение показало, что «генерация кода на лету» вызывает споры: кто-то считает это будущим, другие указывают на проблемы с безопасностью, стоимостью и предсказуемостью.
• Участники обсуждали, что вместо генерации кода, можно кешировать уже созданные компоненты и переиспользовать их, что может решить проблему с производительностью.
• Некоторые комментаторы подчеркнули, что даже если LLM сгенерирует код, его все равно придется тестировать и поддерживать, и это может быть небезопасно.
• Также обсуждались вопросы стоимости и устойчивости такого подхода, особенно если учесть, что модели становятся дороже.
• В целом, участники согласились, что идея интересная как эксперимент, но пока не ясно, как она может масштабироваться или стать нормой практикой безопасной.

Европейский Совет вновь отступил от спорного предложения Chat Control после массового общественного сопротивления. Текущее датское председательство отозвало инициативу, которая требовала всеобщего сканирования зашифрованных сообщений под предлогом борьбы с материалами о сексуальном насилии над детьми. Это лишь очередной эпизод длительной борьбы между защитниками приватности и законодателями, которые считают, могут пожертвовать шифрованием во имя общественной безопасности. Предложение, прозванное "зомби-инициативой" за свою способность возрождаться, встретило решительный протест со стороны более 80 общественных организаций, включая Electronic Frontier Foundation.

Техническая критика фокусируется на фундаментальном непонимании принципов шифрования. Любая система сканирования, особенно клиентская, создает уязвимость в системе безопасности, превращая шифрование в иллюзию. Как показал опыт Apple в 2021 году, подобные системы неизбежно будут эксплуатироваться не только авторизованными органами, но и злоумышленниками. Отказ Chat Control демонстрирует важность общественного участия в технологической политике, где консолидированное сопротивление экспертов, правозащитных организаций и обычных граждан смогло остановить опасную инициативу.

• Предложение о "контроле чатов" в ЕС отложено, но сторонники намерены вернуться к нему; это уже 25-я попытка за 4 года.
• Любые исключения для политиков и чиновников вызывают особенно яростную критику, поскольку подчеркивает лицемерие.
• Попытки ввести сканирование сообщений в ЕС сопровождаются попытками в США, где подобные инициативы уже провалились.
• Предложение в ЕС предусматривает, что даже зашифрованные сообщения могут быть прочитаны третьей стороной, что технически невозможно без встроенной уязвимости, что вызывает обеспокоенность экспертов.
• Подобные инициативы встречают сопротивление из-за опасений, что они могут быть использованы для массового надзора и что они нарушают права человека, особенно если политики и другие элиты освобождаются от этих правил.

Современные электронные паспорта представляют собой встроенные устройства с файловой системой, контролем доступа и криптографической защитой, соответствующие стандартам ICAO Doc 9303. Их файловая структура включает три типа файлов: основные (MF) как корневой каталог, специализированные (DF) как приложения и элементарные (EF) с данными. Основное приложение eMRTD содержит персональные данные (DG1) и биометрическую информацию (DG2 с фотографией), а также дополнительные опциональные группы данных для цифровых штампов и виз.

Эти документы используют короткодействующий RFID (ISO 14443) и защищены от несанкционированного чтения, прослушки, подделки и копирования. Модель угроз разделяет атакующих по физическому доступу: без паспорта нельзя прочитать данные или отследить его перемещения, а с паспортом - скопировать цифровую копию или получить доступ к биометрическим данным (отпечатки пальцев DG3, радужка DG4). Несмотря на современные протоколы, поддержка устаревших механизмов создает дополнительные риски для владельцев.

• Вашингтонский "Enhanced ID" стал первым документом, одобренным DHS в 2005 году, но уже тогда исследователи нашли уязвимости, включая возможность удалённого клонирования и отключения чипа, а ведь с тех пор технологию так и не обновили.
• Паспорт как технология контроля движения людей: от крепостных до наших дней.
• Электронные паспорта и ID-карты не решают проблему подделки документов, а лишь переносят доверие с бумаги на криптографию, что в условиях коррупции в гос. органах не имеет значения.
• Почему в 2024 году нельзя сделать паспорт, который нельзя было бы подделать? Потому что это не позволит контролировать потоки мигрантов.
• Паспортизация как способ контроля миграции.

Анонимный пользователь rogueFed получил доступ к закрытому брифингу Cellebrite и опубликовал скриншоты, показывающие, что большинство смартфонов Pixel уязвимы для взлома этой компанией. Уязвимы модели Pixel 6, 7, 8 и 9 серии, в то время как недавно выпущенный Pixel 10 в списке отсутствует. Cellebrite может извлекать данные из этих устройств в трех состояниях: до первого разблокировки (BFU), после первого разблокировки (AFU) и в полностью разблокированном режиме. Интересно, что компания отмечает, что не может взломать графенос с последних версиями ПО, даже если устройство разблокировано.

На стандартном Android Cellebrite может извлекать данные из Pixel 6-9 во всех состояниях, но не может brute-force пароли для полного контроля над устройством. Для GrapheneOS ситуация иная: только версии ПО до конца 2022 года уязвимы, а более новые защищены даже в BFU и AFU состояниях. Полиция до сих пор не может копировать eSIM с Pixel устройств, хотя Pixel 10 уже переходит на использование только eSIM.

• GrapheneOS признан более устойчивым к взлому, чем стандартный Android, что подтверждается упоминанием в документах Cellebrite.
• Google criticized for weaker security compared to volunteer-developed custom ROMs, with questions about why official Pixel OS is less secure.
• Debate over eSIM vs physical SIM cards: users value physical SIMs for convenience and flexibility, while eSIMs seen as increasing corporate control.
• Cellebrite's hacking tools revealed as vulnerable themselves, with past leaks and physical devices potentially compromised.
• GrapheneOS offers enhanced security but involves trade-offs like reduced compatibility with services (e.g., Google Pay, emergency services).

Google анонсировал, что с выходом Chrome 154 в октябре 2026 года включит по умолчанию функцию "Always Use Secure Connections", требующую разрешения пользователя для доступа к сайтам без HTTPS. Эта мера призвана защитить пользователей от атак, при которых злоумышленники могут перехватить навигацию и подменить контент. Хотя HTTPS-адoption достиг 95-99%, прогресс застыл с 2020 года, а оставшиеся HTTP-соединения все еще представляют значительную угрозу.

Для баланса безопасности и удобства Chrome не будет дублировать предупреждения для часто посещаемых HTTP-сайтов. Google подчеркивает, что даже небольшая доля небезопасных соединений создает риски, так как атакующему достаточно одного успешного перехвата. Компания отмечает, что за десятилетие наблюдений HTTPS стал зрелым и широко распространенным, что позволяет теперь перейти к более строгим мерам защиты по умолчанию.

• Пользователи обсуждают, что почти весь трафик уже давно перешёл на HTTPS, и оставшиеся HTTP-сайты — это в основном старые ресурсы, которые не обновлялись с 2010-х годов.
• Обсуждается, что в 2024 году Google Chrome полностью отключит поддержку HTTP, и это вызвало споры о том, насколько это нужно, учитывая, что большинство сайтов уже используют HTTPS.
• Участники обсуждают, что вместо того, чтобы отключать HTTP, Google мог бы вместо этого инвестировать в улучшение инструментов для разработчиков, чтобы они могли легче мигрировать с HTTP на HTTPS.
• Также обсуждается, что отключение HTTP может затруднить доступ к внутренним ресурсам в корпоративных сетях, где HTTPS не всегда практичен.

Python Software Foundation (PSF) withdrew its $1.5 million grant application to the US National Science Foundation (NSF) after the agency demanded a commitment to abandon diversity, equity, and inclusion (DEI) initiatives. The proposed funding aimed to enhance security for Python's package repository PyPI by developing automated tools to proactively detect malicious code in packages, a significant improvement over current reactive methods. The NSF's condition required the PSF to affirm it would not "advance or promote DEI," a restriction applying to all PSF activities, not just the funded project. Violation would trigger the NSF to reclaim previously awarded funds, creating substantial financial risk.

This demand directly conflicted with the PSF's core mission, explicitly stating its commitment to supporting "a diverse and international community." Despite the grant's potential to significantly boost the PSF's annual $5 million budget and develop security tools with broader open-source ecosystem benefits (like NPM and Crates.io), the organization refused to compromise its values. The PSF Board unanimously decided withdrawal was necessary to retain the freedom to support its entire community. The loss of this funding, coupled with economic pressures, increases the PSF's need for direct community financial support.

• PSF отказалась от $1,5 млн гранта из-за требования отказаться от DEI-программ, что вызвало широкий резонанс в сообществе.
• Обсуждение подняло вопрос о том, что DEI-программы могут быть незаконны, и что это может быть причиной, по которой грант был отклонен.
• Некоторые участники обсуждения выразили обеспокоенность тем, что отказ от гранта может повлиять на безопасность и стабильность экосистемы Python.
• Были высказаны предложения о том, что сообщество могло бы само финансировать нужды, чтобы не зависеть от грантов с политическими условиями.
• Обсуждение также затронуло вопрос о том, что DEI-программы могут быть незаконны, и что это может быть причиной, по которой грант был отклонен.

В статье Джеймса Миккенса критикуется сложный и непонятный язык, используемый в исследованиях по безопасности. Автор приводит примеры абсурдных названий докладов вроде "Vertex-based Elliptic Cryptography on N-way Bojangle Spaces", которые начинаются посередине сложной темы без должного контекста. Миккенс сравнивает исследователей безопасности с триатлетами, тренирующимися для маловероятных сценариев, утверждая, что они сосредоточены на теоретических проблемах, а не на практических решениях.

Автор также критикует PR-навыки специалистов по безопасности, сравнивая их с "надменными подростками, слушающими готическую музыку", которые сосредоточены на потенциальных катастрофах, но не дают практических рекомендаций. Миккенс выражает разочарование, что сообщество безопасности изучает экзотические угрозы (например, управление кардиостимуляторами через банку Pringles), вместо решения более распространенных проблем, таких как создание запоминающихся, но надежных паролей.

• Обсуждение началось с цитаты из статьи Mickens о том, что если противник — это Mossad, то «вы уже мертвы» и ничего не поделаешь.
• Участники обсудили, насколько реалистично представленный сценарий, где противник — это государственная разведка, и какие угрозы реальны для обычных людей.
• Поднялась тема, что даже если Mossad не заинтересован в большинстве людей, то есть ли смысл в чрезмерной паранойе, и какие именно угрозы стоит считать реальными.
• Обсуждались примеры, когда разведки разных стран использовали вредоносное ПО или оборудование для слежки, и как это влияет на дискуссию о безопасности.
• В комментариях также поднялись темы, связанные с недавними событиями, включая взрывы пейджеров и телефонов, и обсуждалось, как это соотносится с обсуждаемыми темами.

С обновлением iOS 26 Apple изменила обработку файла shutdown.log, теперь он полностью перезаписывается при каждой перезагрузке вместо добавления новых записей. Это изменение эффективно удаляет ключевые индикаторы компрометации (IOCs) для шпионского ПО Pegasus и Predator, что создает серьезные проблемы для расследований и проверки устройств на зараженность. Файл shutdown.log был критически важен для обнаружения этих угроз, так как содержал следы деятельности вредоносного ПО даже во время выключения устройства.

В 2021 году в shutdown.log были обнаружены явные следы Pegasus, а к 2022 году злоумышленники стали более изощренными, полностью стирая файл, но даже это оставляло косвенные доказательства. Для версий iOS до 26 конкретным индикатором компрометации была запись /private/var/db/com.apple.xpc.roleaccountd.staging/com.apple.WebKit.Networking. Теперь же с обновлением до iOS 26 все эти следы автоматически удаляются, что происходит в момент, когда количество атак с использованием шпионского ПО только растет.

• Apple удаляет ключевой файл журнала shutdown.log, что лишает пользователей и исследователей единственного способа обнаружить Pegasus и другие вредоносные ПО, и это вызывает вопросы о том, насколько серьезно компания относится к безопасности и прозрачности.
• Удаление журнала делает невозможным обнаружение шпионского ПО, что особенно критично, учитывая что Apple позиционирует себя как защитник конфиденциальности.
• Некоторые комментаторы поднимают вопрос о том, что Apple может быть умышленно оставляет устройства уязвимыми для израильских хакеров, особенно в свете их истории сотрудничества с правительством США.
• Другие указывают на то, что Apple не предоставляет пользователям инструментов для проведения собственных расследований, что делает невозможным для них проверить свои устройства на наличие вредоносного ПО.
• В ответ на это, некоторые участники обсуждения предлагают, что Apple должна предоставить пользователям инструменты для проведения собственных расследований, включая доступ к полному дампу памяти, что позволило бы им проверять свои устройства на наличие вредоносного ПО.

Недавно на рейсе British Airways из Гонконга в Лондон автор обнаружил бесплатный WiFi для "сообщений" через программу лояльности. Оказалось, что для регистрации достаточно ввести email без верификации прямо в полёте. Бесплатный интернет работал с WhatsApp, Signal и WeChat (без изображений), но блокировал Discord и обычные сайты.

Автор выяснил, что система использует SNI (Server Name Indication) из TLS-рукопожатия для определения типа трафика. SNI раскрывает домен до установления шифрования, позволяя авиакомпании блокировать не-whitelisted домены. Эксперименты показали, что даже прямые подключения по IP без SNI блокируются, а использование SNI от WhatsApp (wa.me) обходит ограничение, позволяя установить соединение с любым сайтом через хост-заголовок HTTP.

• Обсуждение началось с описания способа обхода ограничений Wi-Fi в самолётах и круизных лайнерах с помощью VPN, DNS-туннелирования и прочих техник, включая использование порта 53/UDP и DNS-over-HTTPS.
• Участники обменялись историями о том, как они обходили плату за Wi-Fi в полёте, используя различные комбинации инструментов вроде OpenVPN, WireGuard, Iodine и прочих.
• Обсуждались также такие темы, как SNI-утечки, обфускация трафика и их влияние на приватность пользователей.
• Упоминались также вопросы о том, как авиакомпании и другие транспортные компании могут отслеживать и ограничивать использование VPN и прокси-серверов.
• В конце обсуждение перешло к обсуждению более широких тем, таких как приватность и безопасность в сети, а также о том, как технические меры могут быть использованы для обхода цензуры и ограничений.

Anthropic представила функцию памяти для Claude, которая позволяет ИИ запоминать контекст проектов, предпочтения команды и рабочие паттерны. Функцией уже пользуются Team и Enterprise-планы, а теперь она доступна и для Pro и Max. Память полностью опциональна с детальным контролем пользователя, а для конфиденциальных разговоров добавлен режим "Инкогнито", который не сохраняется в истории.

Каждый проект имеет отдельную память, что предотвращает смешивание информации между разными инициативами. Пользователи могут просматривать и редактировать то, что запомнил Claude, через сводку памяти. Функция прошла тщательное тестирование безопасности, включая проверку на возможность воспроизведения вредных паттернов. Как отмечено в статье: "Memory helps you and your teams manage complex, concurrent initiatives without mixing unrelated details, serving as a safety guardrail that keeps sensitive conversations contained".

• Пользователи обсуждают, что новая функция памяти в Claude не работает как RAG-система, а скорее как «контекст-окно плюс» — она не запоминает документы, а лишь «контекст» внутри одной сессии.
• Участники отмечают, что Anthropic не раскрывает, как именно реализована память: нет никакого доступа к «памяти» или возможности её редактировать, что вызывает вопросы о контроле и прозрачности.
• Ряд участников подчеркивает, что модель не может отличить, какие именно воспоминания будут использованы в будущем, и это вызывает опасения по поводу приватности и безопасности.
• Некоторые участники высказывают, что не ясно, как именно память влияет на стоимость и токены, и нет ли у неё каких-то ограничений по объёму.
• Также обсуждается, что Anthropic не предоставляет никакого способа переноса памяти между различными проектами или даже между Claude и ChatGPT.

Исследователи безопасности обнаружили критическую уязвимость в системе Международной автомобильной федерации (FIA), позволившую получить несанкционированный доступ к персональным данным гонщиков Формулы-1. Через портал drivercategorisation.fia.com, используемый для присвоения гонщикам категорий, они смогли повысить свои привилегии до уровня администратора с помощью простого модифицированного HTTP PUT запроса, добавив параметр "roles" со значением "ADMIN".

Получив полный административный доступ, исследователи обнаружили возможность просмотра конфиденциальной информации, включая паспортные данные чемпиона Макса Ферстаппена и других гонщиков. Уязвимость существовала из-за отсутствия proper проверки прав при изменении параметров пользователя, что позволяло осуществить атаку повышения привилегий. Этот инцидент демонстрирует серьезные пробелы в кибербезопасности даже в таких престижных организациях, как FIA, отвечающей за один из самых технологичных видов спорта в мире.

• Сайт F1, который не смог защитить личные данные, был взломан, и это стало поводом для обсуждения, что компания, которая не может защитить данные, не должна быть доверена.
• Пользователи отметили, что сайт не только не защищает данные, но и не имеет bug bounty программы, что делает невозможным получить вознаграждение за найденные уязвимости.
• Некоторые участники обсуждения подчеркнули, что вместо того, чтобы устранять уязвимости, компания может начать угрожать исследователям, которые сообщают о проблеме.
• Было также отмечено, что вместо того, чтобы устранять уязвимости, компания может начать угрожать исследователям, которые сообщают о проблеме.

Предоставленный текст содержит только навигационную структуру сайта MDN, но не основное содержание статьи о методе setHTML(). В тексте отсутствует описание самого API, его синтаксиса, параметров, примеров использования и совместимости с браузерами. Для создания точного пересказа требуется полное содержание статьи, описывающее новый метод DOM API, который, вероятно, предоставляет альтернативу innerHTML с дополнительными возможностями или улучшенной безопасностью. Без доступа к фактическому описанию метода невозможно предоставить содержательный пересказ его функциональности и применения.

• Впервые за 25 лет в Firefox Nightly появилась возможность безопасно вставлять HTML через Element.setHTML(), что вызвало обсуждение: спор о том, почему так долго не хватало базовой возможности, и о том, что API-шный дизайн (включая именование setHTML/setHTMLUnsafe) не идеален.
• Участники обсуждения отметили, что новое API встроенной санитизации встроенной в браузер — это фактически встроенный DOMPurify, и что спор в основном ведется о том, что «безопасность по умолчанию» должна быть выбрана как поведение по умолчанию.
• Некоторые комментаторы выразили обеспокоенность тем, что спецификация пока не различает между контентом и вставляемым через setHTML() и innerHTML, и что это может влиять на производительность, если разработчики начнутт читать спецификацию как «естественное продолжение» innerHTML.
• Были также затронуты темы о том, что встроенная санитизация может влиять на разработчиков, которые полагаются на встроенную санитизацию, и о том, что это может влиять на разработчиков, которые полагаются на встроенную санитизацию.

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

В Linux они передаются через execve как массив строк вида KEY=VALUE. Внутри процесса они хранятся в стеке или куче, а программы используют разные структуры данных для их представления: Bash использует хешмапы, Python — словари, а C — массив environ.

Важно помнить, что изменения в дочернем процессе не влияют на родительский, и не все инструменты наследуют окружение. Например, login задаёт свежее окружение.

Из-за отсутствия пространств имён или типов легко допустить ошибку, например, перезаписать критичную переменную PATH. Хотя они удобны для конфигурации, их следует использовать с осторожностью.

• Обсуждение охватило широкий спектр тем: от безопасности переменных окружения до передачи секретов, влияния на разные системы и стандарты, и даже до влияния на разработку программного обеспечения.
• Участники обсуждали, что переменные окружения небезопасны для передачи секретов, так как любой процесс может прочитать их.
• Были упомянуты альтернативы, такие как systemd-creds, которые могут быть использованы для передачи секретов безопасно.
• Также обсуждались проблемы с конфигурацией и стандартами, такие как использование переменных окружения для конфигурации вместо файлов конфигурации.
• Участники также обсуждали влияние переменных окружения на разработку программного обеспечения, включая влияние на разработку в Windows и Unix системах.

25 сентября 2025 года Google Safe Browsing внезапно заблокировал весь домен statichost.eu как «обманчивый» — даже поддомены, включая пользовательские сайты клиентов. Почти шесть часов ни один браузер на Chromium-основе не открывал ни одну страницу на домене без жёсткого предупреждения. Это затронуло и сам сайт компании и все её поддомены, включая личные сайты клиентов.

В итоге, Google Search Console показал, что причиной стало то, что на платформе появились фишинговые сайты. Вместо того, чтобы сообщить владельцу и дать ему возможность удалить их, Google просто внёс весь домен в чёрный список.

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

• Google Safe Browsing блокирует сайты, если на них размещают фишинг-контент, но при этом не всегда ясно, кто именно блокирует — Google или другие сервисы.
• Провайдеры, которые не разделяют пользовательский контент на отдельном домене, рискуют, что весь их домен попадёт в чёрный список.
• Public Suffix List помогает браузерам и поисковикам различать, где заканчивается домен первого уровня и начинается поддомен.
• Размещая пользовательский контент на отдельном домене, можно избежать риска, что весь домен попадёт в чёрный список.

Краткий пересказ

30 сентября 2025 года бывший сотрудник Ruby Central Андре Арко сообщил, что у него остался доступ к продакшен-среде RubyGems.org. Почти одновременно блогер Джоэл Дрейпер опубликовал скриншоты, подтверждающие это. Внутреннее расследование показало, что 19 сентября неизвестный злоумышленник сменил пароль root-аккаунта AWS и в течение 11 дней имел возможность администрировать инфраструктуру. В результате Ruby Central отозвала все устаревшие ключи доступа, включила MFA для всех живых аккаунтов и перевела проект на изолированный AWS-аккаунт под единоличным контролем Ruby Central.

• Ruby Central обвиняет бывшего мейнтейнера Andre Arko в том, что он, будучи уволенным, сохранил доступ к корневой учетной записи AWS и изменил пароль, что фактически блокирует организацию от доступа к собственной инфраструктуре.
• Сообщение Ruby Central подчеркивает, что не было никаких доказательств компрометации, но не упоминает о том, что не было никаких доказательств и того, что доступа не было.
• Сообщение Ruby Central не упоминает о том, что они не отозвали доступа к корневой учетной записи, не изменили пароль и не отключили MFA, что, как утверждает Arko, оставляет сервис уязвимым для "незаконного доступа и потенциального утечки данных".
• Arko утверждает, что он не имел доступа к логам доступа, и что Ruby Central не предоставила никаких доказательств того, что кто-то еще имел доступ к этим логам.
• Обсуждение также затрагивает вопрос о том, каким образом Ruby Central может гарантировать, что никакие PII не была скомпрометирована, если они не могут доказать, что никто не имел доступа к логам доступа.

Discord подтвердил, что в результате инцидента с поставщиком услуг клиентской поддержки могли быть скомпрометированы документы, касающиеся до 70 000 пользователей. Компания подчеркивает, что атакующие распространяют ложную информацию как часть вымогательской кампании. Пока неясно, какие именно данные были затронуты, но Discord утверждает, что «большинство» из них ограничиваются адресом электронной почты, номером телефона и/или имени пользователя.

• Discord и другие компании продолжают собирать и хранить документы удостоверяющие личность, несмотря на то, что они не могут их защитить.
• Пользователи, которые предоставили свои документы, теперь подвержены риску, что их личные данные могут быть украдены.
• Сторонние подрядчики, которые обрабатывают документы удостоверяющие личность, не могут быть идентифицированы, что делает невозможным для пользователей понять, кто именно имеет доступ к их личным данным.
• Пользователи, которые не предоставили свои документы, не могут получить доступ к сервису.
• Пользователи, которые предоставили свои документы, теперь не могут быть уверены, что их личные данные не будут использованы для других целей.

Правящая партия Германии CDU/CSU официально отказалась от поддержки системы массового контроля переписки, которую продвигают некоторые страны ЕС. Это решение стало крупной победой для приватности в Евросоюзе, поскольку предотвращает введение так называемой «чаткинтроли» без конкретного повода.

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

• Выражено глубокое недоверие к мотивам Германии и других стран, продвигающих массовый контроль за перепиской, с предупреждениями, что эти инициативы могут быть возобновлены в будущем.
• Участники считают, что дебаты о контроле за шифрованием (Chat Control) носят циклический характер и вряд ли будут окончательно урегулированы в обозримом будущем, так как сторонники контроля будут продолжать свои попытки.
• Подчеркивается техническая невозможность ослабить сквозное шифрование для выборочного контроля, не создав уязвимости для всех пользователей, что делает онлайн-банкинг и другие сервисы небезопасными.
• Многие выступают за безусловную защиту права на приватность и шифрование, рассматривая его как фундаментальную свободу, и призывают отвергать любые попытки его ограничения.
• Оппоненты массового контроля утверждают, что существующих юридических механизмов (например, предоставление истории переписк

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

Такие меры могут подорвать доверие к технологическим компаниям и создать уязвимости, которыми воспользуются злоумышленники. Apple и правозащитные организации активно сопротивляются, подчёркивая, что бэкдоры не могут быть ограничены только «законным» доступом.

• Участники обсуждают требования правительства Великобритании к Apple о предоставлении доступа к зашифрованным данным пользователей (iCloud), включая отключение функции Advanced Data Protection.
• Высказывается обеспокоенность по поводу расширения государственного надзора и ущемления приватности, проводятся параллели с ситуацией в Китае и другими законами (PATRIOT Act, FISA).
• Обсуждается юридическая сторона: какие пользователи попадают под юрисдикцию UK, возможность Apple противостоять требованиям и роль правительства США в предыдущих спорах.
• Поднимается вопрос о доверии к производителям устройств и облачным сервисам, уязвимости перед принудительными OTA-обновлениями и необходимости независимого аудита безопасности.
• Некоторые пользователи связывают эти события с общим упадком и ужесточением законодательства в Великобритании, включая ограничение свободы слова и иммиграционную политику.

Даниель Стенберг получил от Джошуа Роджерса огромный список потенциальных уязвимостей в curl, включая более 100 потенциальных проблем. Это привело к интенсивному анализу и исправлению кода, что подчеркивает важность краудсорсинга в безопасности ПО. Команда curl оперативно реагирует на такие отчеты, укрепляя стабильность и надежность библиотеки.

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

• Успешное применение набора AI-инструментов для поиска уязвимостей в проекте curl, что привело к множеству реальных исправлений
• Подчёркивается ценность AI не для генерации кода, а для анализа и указания на потенциально проблемные места, требующие внимания разработчика
• Обсуждение конкретных инструментов (ZeroPath, Claude Code, Cursor BugBot) и методик работы с LLM для эффективного поиска багов
• Отмечается проблема ложных срабатываний и спама от AI в прошлом, но в данном случае подход оказался эффективным
• Размышления о том, как интегрировать подобные AI-инструменты в рабочий процесс для аудита безопасности и повышения качества кода

Разработчики и менеджеры сталкиваются с этическими дилеммами, когда их просят участвовать в незаконных действиях на работе. Например, инженерный директор Nishad Singh в FTX узнал о хищении $13 млрд клиентских средств лишь за месяц до краха компании, но не предпринял активных действий, чтобы остановить мошенничество. Его пассивность привела к серьёзным последствиям, включая судебные разбирательства.

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

• Обсуждение примеров неэтичных и незаконных действий в IT, включая уязвимости безопасности, мошенничество с данными и манипуляции с финансами.
• Подчеркивание важности отказа от выполнения незаконных указаний и этической ответственности разработчиков, несмотря на риск retaliation.
• Предложения по усилению защиты осведомителей, созданию кодексов этики (например, от ACM/IEEE) и ужесточению законов против retaliation.
• Отмечается сложность принятия решений из-за давления со стороны руководства, страха потерять работу и неочевидности нарушений.
• Обсуждение последствий для сотрудников, ставших свидетелями нарушений, включая стресс, увольнения и судебные разбирательства.

С января 2026 года Gmail прекратит поддержку Gmailify и POP-подключений для сторонних почтовых аккаунтов. Gmailify позволял применять функции вроде защиты от спама и категоризации входящих к другим ящикам, а POP использовался для загрузки писем без синхронизации в реальном времени.

Вместо этого Google рекомендует использовать IMAP-подключения через мобильное приложение Gmail, которое поддерживает синхронизацию нескольких аккаунтов. Ранее импортированные письма останутся доступными, но новые настройки придётся обновить вручную. Это изменение направлено на повышение безопасности и переход на современные стандарты работы с почтой.

• Пользователи выражают недовольство отключением функции POP3 в Gmail, которая позволяла получать почту с внешних серверов, что создает проблемы для миграции и резервного копирования.
• Предлагаются обходные пути: настройка пересылки (forwarding), использование IMAP через почтовые клиенты (например, Thunderbird) или переход на другие сервисы (ProtonMail, Zoho, самохостинг).
• Высказываются предположения о причинах отключения: монетизация через Google Workspace, борьба с рекламными блокировками в сторонних клиентах и общая стратегия «эншитификации» сервиса.
• Многие отмечают, что потеря POP3 ударяет по платным пользователям Google Workspace и усложняет использование дешевых почтовых хостингов с брендированными доменами.
• Обсуждение подчеркивает централизацию email-инфраструктуры вокруг крупных компаний и упадок децентрализованных протоколов.

Кодирующие агенты вроде Claude Code и Codex CLI позволяют ИИ не только писать код, но и запускать его, исправлять ошибки и экспериментировать с решениями. Ключевой навык для эффективного использования таких инструментов — проектирование агентских циклов: настройка последовательности действий, где ИИ применяет инструменты в цикле для достижения чётко сформулированной цели. Это превращает агентов в инструменты «грубой силы» для решения задач, если можно определить цель и дать нужные инструменты для итераций.

Однако такая мощь сопряжена с рисками, особенно в «YOLO-режиме», когда агент выполняет команды без подтверждения. Это может привести к удалению файлов, утечке данных или использованию машины для атак. Для снижения рисков автор рекомендует запускать агентов в песочницах (например, Docker), использовать облачные среды вроде GitHub Codespaces или полагаться на удалённые серверы, где ущерб будет ограничен. Также важно тщательно подбирать инструменты для цикла, чтобы агент мог эффективно и безопасно решать задачи.

• Предлагаются альтернативы Docker для песочниц: bubblewrap, firejail, пользовательские аккаунты, KVM и контейнеры.
• Обсуждаются принципы проектирования агентских циклов: избегание фреймворков, малое число мощных инструментов, важность человеческого контроля.
• Подчеркиваются риски безопасности YOLO-режима и необходимость изоляции (контейнеры без сети, VM) для предотвращения утечек данных.
• Отмечается эффективность асинхронных циклов (например, в Claude Code Plan mode) для выполнения задач без постоянного вмешательства.
• Упоминаются практические реализации: MCP, инструменты для работы с документами, использование checkpoint-ов и систем оркестрации.

Серверные материнские платы Supermicro уязвимы для удалённой установки вредоносного ПО в прошивку базового контроллера управления (BMC), что делает заражение практически необнаружимым и неустранимым стандартными методами. Уязвимости CVE-2025-7937 и CVE-2025-6198 позволяют обходить проверки цифровых подписей и перезаписывать firmware, которая выполняется ещё до загрузки операционной системы — даже замена дисков или переустановка ОС не очистят систему.

Эксплуатация уязвимостей требует предварительного получения контроля над BMC, что возможно через ранее описанные методы. Подобные атаки могут привести к установке стойких имплантов, аналогичных ILObleed, который безвозвратно уничтожал данные на серверах HP. Особую опасность это представляет для AI-датацентров, где массовое заражение может оставаться незамеченным долгое время.

• Участники обсуждают уязвимости BMC (базовых контроллеров управления) в серверах Supermicro и других производителей, отмечая их низкое качество ПО и наличие неисправленных уязвимостей, позволяющих удалённо прошивать прошивку.
• Подчёркивается, что BMC представляет собой серьёзный вектор атаки и должен быть изолирован в отдельной физической или логической сети без прямого доступа извне.
• Обсуждаются проблемы безопасности на уровне прошивки: отсутствие проверки подписей, возможность перепрошивки из операционной системы и сложность удаления бэкдоров без физического доступа к чипу.
• Высказывается критика в адрес производителей за отсутствие документации, открытых спецификаций и поддержки открытых альтернатив, таких как OpenBMC.
• Упоминается, что проблема не нова и ранее обсуждалась в контексте спорной статьи Bloomberg о предполагаемых аппаратных закладках китайского происхождения в серверах Supermicro.

GitHub Actions добавили поддержку YAML-якорей, что автор считает серьёзной ошибкой. Якоря избыточны: ту же функциональность можно реализовать через встроенные механизмы вроде workflow-level env, которые прозрачнее и логичнее в архитектуре. Они вводят ненужную сложность, нарушая локальность — теперь элементы могут зависеть от частей конфигурации в совершенно другом месте файла, что усложняет чтение и анализ.

Кроме того, якоря усугубляют проблемы безопасности: инструментам сложнее анализировать workflows, так как нарушается соответствие между исходным YAML и объектной моделью. Это мешает точно отслеживать уязвимости, например утечки секретов. GitHub не реализовал ключи слияния (merge keys), единственный сценарий, где якоря могли бы быть оправданы, что делает их поддержку бессмысленной и вредной.

• Внедрение YAML-якорей в GitHub Actions оценивается положительно для устранения дублирования в конфигурациях, но критикуется за использование нестандартного синтаксиса, усложняющего анализ.
• Высказываются предложения заменить YAML на полноценный язык программирования для определения пайплайнов, чтобы улучшить тестируемость, локальную разработку и избежать сложностей шаблонизации.
• Поднимаются проблемы безопасности из-за неявного распространения переменных окружения (включая секреты) при использовании якорей и слияния объектов, что противоречит принципу минимальных привилегий.
• Отмечается, что текущие ограничения GitHub Actions (например, отсутствие фильтрации путей для workflow_call) вынуждают пользователей создавать костыльные решения или полагаться на сторонние инструменты.
• Обсуждаются компромиссы между декларативным и императивным подходами: одни предпочитают чистый YAML для читаемости, другие генерируют его из кода для удобства поддержки сложных логик.

HackerOne — это платформа для координации программ bug bounty, где компании платят исследователям за обнаружение уязвимостей в их системах. Для полноценной работы сайта требуется включенный JavaScript в браузере, так как многие интерактивные функции, включая отправку отчетов и взаимодействие с интерфейсом, зависят от него.

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

• Пользователи обсуждают волну бесполезных AI-генерируемых отчетов об уязвимостях (например, для cURL), которые тратят время разработчиков.
• Высказываются опасения, что в будущем AI сможет генерировать более правдоподобные, но все же ложные доказательства концепций (PoC).
• Предлагаются решения для борьбы со спамом: платный депозит за отправку отчета, баны, фильтрация по эмодзи и другим признакам AI-текста.
• Обсуждается негативное влияние AI на качество кода, ревью и общую культуру разработки, а также возможные скрытые мотивы таких атак.
• Отмечается профессиональная реакция мейнтейнера (badger) на некорректный отчет и ссылки на соответствующие доклады Дэниела Стенберга о проблеме.

Технология eSIM, упрощая подключение к сотовым сетям без физической SIM-карты, создаёт серьёзные риски приватности и безопасности. Исследование показывает, что трафик пользователей travel-eSIM часто маршрутизируется через сторонние сети, включая китайскую инфраструктуру, независимо от реального местоположения — это подвергает данные юрисдикционному воздействию и потенциальному наблюдению.

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

• Исследование выявило проблемы с маршрутизацией данных через третьи страны (например, Гонконг) и доступом реселлеров к конфиденциальной информации пользователей при использовании туристических eSIM.
• Многие пользователи критикуют eSIM за сложность переноса между устройствами по сравнению с физическими SIM-картами и потенциальные ограничения со стороны операторов.
• Обсуждаются риски безопасности, включая возможные скрытые уязвимости eSIM, что подтверждается строгими ограничениями на их использование в таких странах, как Китай.
• Отмечается, что многие проблемы (маршрутизация, конфиденциальность) связаны не с технологией eSIM как таковой, а с бизнес-моделями MVNO и реселлеров.
• В качестве решений для защиты данных при использовании eSIM предлагается использовать VPN (например, WireGuard) и выбирать проверенных провайдеров.

Obsidian минимизирует риски цепочек поставок, сознательно сокращая зависимости от стороннего кода. Приложение переиспользует или форкает небольшие модули, а для крупных библиотек вроде pdf.js или Mermaid использует версионно зафиксированные файлы с редкими обновлениями после тщательного тестирования. Это создаёт мелкую и контролируемую структуру зависимостей.

Все зависимости жёстко закреплены через lock-файлы, исключены пост-установочные скрипты, а обновления проводятся медленно и вручную — с изучением изменений, проверкой подзависимостей и тестами. Такой подход снижает вероятность попадания вредоносных обновлений и даёт время на обнаружение проблем до релиза.

• Пользователи выражают обеспокоенность уязвимой моделью безопасности плагинов Obsidian, которые имеют полный доступ к файлам.
• Обсуждается компромисс между использованием зависимостей и безопасностью: одни выступают за минимализм, другие — за осторожное обновление.
• Многие отмечают, что пост Obsidian игнорирует риски, связанные с плагинами, которые являются ключевой особенностью продукта.
• Высказывается критика в адрес Electron-архитектуры приложения из-за её ресурсоёмкости и потенциальных уязвимостей.
• Предлагаются альтернативы с меньшим количеством зависимостей и более нативными решениями, такие как Zim или Emacs.

Nostr — это открытый децентрализованный протокол для передачи информации, построенный на криптографически подписанных заметках. Каждая заметка создаётся пользователем с помощью приватного ключа и публикуется на ретрансляторах (relays), которые служат распределёнными узлами хранения. Клиенты подключаются к множеству ретрансляторов, что обеспечивает устойчивость и независимость от единого центра управления.

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

• Критика криптографической безопасности протокола Nostr: уязвимости в аутентификации ключей и проверке подписей, что может позволить атаки типа "человек посередине".
• Отсутствие единой модели федерации релеев: клиенты должны подключаться к множеству релеев для обмена сообщениями, что усложняет пользовательский опыт и разработку.
• Проблема спама и злоупотреблений: отсутствие механизмов противодействия массовой генерации ключей и автоматизированному спаму, а также распространение незаконного контента.
• Смешение философских и технических аспектов: сложность восприятия из-за сочетания политических заявлений ("аполитичный", "про-цензура") с техническими деталями протокола.
• Фрагментация стандартов (NIP) и клиентов: множество реализаций и отсутствие строгой стандартизации затрудняют adoption и создают путаницу для пользователей.

Когда на macOS включен FileVault, том с данными остается заблокированным до ввода пароля при загрузке, что делает SSH недоступным, так как его конфигурация хранится на этом томе. Однако если активирована опция Remote Login, можно аутентифицироваться по паролю через SSH даже в заблокированном состоянии, что позволяет удаленно разблокировать диск.

После успешной аутентификации система ненадолго разрывает SSH-соединение, пока монтирует том и запускает зависимые сервисы, после чего полноценный доступ возобновляется. Эта функция, появившаяся в macOS 26 Tahoe, полезна для администрирования устройств без физического присутствия.

• В macOS 26 Tahoe появилась возможность удалённой разблокировки зашифрованного тома (FileVault) по SSH до входа в систему, что решает давнюю проблему для удалённых серверов на Mac.
• Пользователи подтверждают работоспособность функции: после перезагрузки можно подключиться по SSH, ввести учётные данные для разблокировки, после чего соединение разрывается, и система завершает загрузку.
• Функция высоко оценена корпоративными пользователями и администраторами, так как позволяет использовать Mac mini в стойках и ЦОД без необходимости физического доступа для ввода пароля после сбоя питания.
• Обсуждаются технические детали реализации: использование системного тома (read-only), перезагрузка пользовательского пространства после разблокировки для избежания race condition.
• Некоторые пользователи выражают озабоченность по поводу потенциальных векторов атаки и необходимости использования аутентификации по паролю для SSH в этом сценарии.

Компания Anthropic находится в центре внимания в Вашингтоне, но её отказ разрешить использование своих моделей для некоторых правоохранительных целей усилил негативное отношение к ней в администрации Трампа.

• Участники подвергают сомнению достоверность статьи Semafor, называя её предвзятой и содержащей ложные утверждения.
• Обсуждаются ограничения использования ИИ, накладываемые компаниями (включая Anthropic и Microsoft), особенно в контексте государственного наблюдения и военных применений.
• Высказывается мнение, что правительственные агентства должны быть полностью осведомлены об ограничениях при заключении контрактов.
• Поднимается вопрос о суверенитете: предлагается, чтобы правительство США обучило собственную модель ИИ, если ему нужна модель без ограничений.
• Отмечается, что Anthropic, будучи американской компанией, получила допуск для работы с секретными данными благодаря серьёзному отношению к безопасности.
• Обсуждается потенциальное давление на Anthropic со стороны правительства, включая возможную потерю контрактов, за отказ снять ограничения.
• Упоминается, что технически возможно внедрить ограничения прямо в веса модели или обеспечить их соблюдение через FedRAMP-совместимые облачные среды.

О нет, снова... Размышления об атаках на цепочку поставок NPM

Я долго откладывал эту статью — более года — но, как мы видим на этой неделе, пришло время снять покровы и сказать вслух:

В 2025 году Microsoft следует считать «плохим игроком» и угрозой для всех компаний, разрабатывающих программное обеспечение.

Конечно, если вы достаточно взрослые, чтобы помнить — это не первый раз...

Время — плоский круг

Мы снова здесь — в 2025 году Microsoft настолько всё испортили, что создали ещё больший риск, чем в 2000-х с их браузером, просто ничего не делая.

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

С тех пор произошло множество инцидентов, и конкретно NPM стал крупнейшим и самым простым способом распространения вредоносного ПО. Сначала большинство атак было направлено на кражу криптовалюты (поскольку техбро одержимы магическими электрическими деньгами и являются лёгкой добычей). Но теперь эти атаки на цепочку поставок нацелены на более критичные вещи, такие как токены и ключи доступа maintainers пакетов, как видно из инцидента с NX и теперь несколькими зависимостями, ежедневно используемыми тысячами разработчиков.

Опять же... это ничего нового в мире NPM.

Но так быть не должно было...

Мы прошли долгий путь, но никуда не ушли

У меня долгая история с NodeJS — примерно в 2010 году я начал работать над стартапом, и это было до того, как npm вообще появился.

В туманные дни 1990-х большинство проблем безопасности JavaScript не сильно касались бэкенда: это в основном была область Perl, PHP, Python и Java.

Однако веб был совсем другой историей.

В самые ранние дни Всемирной паутины был только один основной браузер, который все использовали: Netscape Navigator. Выпущенный в 1994 году, он был не просто браузером: на протяжении своей жизни он имел различные воплощения встроенного почтового клиента, календаря, HTML-редактора с FTP-браузером, а с плагинами мог воспроизводить медиафайлы, такие как Realplayer и MP3 (что я помню при его запуске), а также флеш-фильмы и игры. Именно здесь родился JavaScript.

Многие ранние сайты того времени были статичными — популярные инструменты для создания сайтов включали HotDog или Блокнот. Никаких навороченных IDE или фреймворков, только текстовый редактор, браузер и alert() для отладки.

Microsoft также вошла в игру с Internet Explorer — включённым в раннее DLC для Windows под названием «Plus! For Windows 95». В конечном итоге он стал программным обеспечением, на которое Microsoft поставила всю свою корпоративную стратегию (во многом как сегодня с ИИ).

Internet Explorer был встроен в каждый аспект Windows — сначала в 1995 году с Active Desktop, что продолжалось вплоть до Windows XP. С ним можно было встраивать фрейм на рабочий стол, а также документы Rich Text или электронные таблицы Excel. Он также был раздутым и багнутым — и с этим представлял две проблемы: огромный риск безопасности и обвинения в монополизации рынка браузеров.

Закон жёстко настиг Microsoft, и в 2001 году она проиграла — Microsoft было приказано разбить компанию, но апелляция отменила это решение.

• Участники критикуют экосистему npm за уязвимости в цепочке поставок и отсутствие безопасности по умолчанию, сравнивая её с другими менеджерами пакетов.
• Обсуждается роль крупных компаний (в частности, Microsoft как владельца npm) в решении проблем безопасности и их ответственность за состояние экосистемы.
• Предлагаются конкретные меры: обязательная 2FA, подписывание кода, политика задержки обновлений (cooldown), переход на альтернативы (pnpm), сканирование пакетов.
• Поднимается проблема эксплуатации труда добровольцев в open-source и недостаточного вклада коммерческих организаций в проекты, которые они используют.
• Отмечается, что культура JavaScript-разработки чрезмерно зависит от большого количества зависимостей, что увеличивает поверхность атаки.
• Указывается на необходимость более строгого контроля зависимостей, включая проверку кода и фиксирование версий (pinning).
• Некоторые участники считают, что фундаментальные изменения в экосистеме маловероятны, и рекомендуют индивидуальные меры защиты.

О безопасности iOS 15.8.5 и iPadOS 15.8.5

Этот документ описывает обновления безопасности для iOS 15.8.5 и iPadOS 15.8.5.

Обновления безопасности Apple

Apple не раскрывает информацию об уязвимостях до завершения расследования и выпуска исправлений. Последние обновления перечислены на странице выпусков безопасности Apple.

iOS 15.8.5 и iPadOS 15.8.5

Выпущено 15 сентября 2025 года

ImageIO

Доступно для: iPhone 6s, iPhone 7, iPhone SE (1-го поколения), iPad Air 2, iPad mini (4-го поколения) и iPod touch (7-го поколения)

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

Описание: Исправлена ошибка записи за пределами границ за счёт улучшенной проверки.

CVE-2025-43300: Apple

Информация о продуктах, не изготовленных Apple, или независимых веб-сайтах предоставляется без рекомендаций. Apple не несёт ответственности за выбор или использование сторонних продуктов.

Опубликовано: 15 сентября 2025 года

• Пользователи отмечают длительную поддержку старых устройств Apple (до 10 лет) в сравнении с ограниченной поддержкой Android-устройств от Google и других производителей.
• Обсуждаются технические причины короткого цикла поддержки Android: ограничения со стороны производителей чипов (Qualcomm) и необходимость интеграции обновлений производителями телефонов.
• Выпуск обновления для устаревших моделей связывают с эксплуатацией уязвимости нулевого дня в целевых атаках государственного уровня, что подчеркивает серьезность угрозы.
• Уточняется, что обновление доступно для широкого списка старых устройств (iPhone 6s, 7, SE, iPad Air 2 и др.), а не только для 10-летнего iPhone 6s.
• Поднимается вопрос о практической пользе обновления для пользователей очень старых устройств, которые могут не устанавливать патчи.
• Отмечается, что современные Android-производители (Google, Samsung) увеличили承诺 срок поддержки до 5-7 лет, что приближается к политике Apple.
• Обсуждается техническая сторона уязвимости: возможность удаленного выполнения кода (RCE) через обработку malicious изображения, часто в связке с уязвимостью в WhatsApp.

GrapheneOS и извлечение данных: мифы и реальность

GrapheneOS — защищённая Android-система, превосходящая iOS по ряду параметров. В мае в соцсетях разгорелась кампания, обвинявшая проект в «взломе»; на деле речь шла о добровольной выдаче кода владельцем.

Цифровая форензика

Цель — извлечь доказательства с устройств. Методы могут злоупотребляться против журналистов и активистов, поэтому GrapheneOS максимально усложняет изъятие без согласия.

Cellebrite

Израильская фирма продаёт комплекс UFED для извлечения данных. Оборудование поставляется и авторитарным режимам (Беларусь, РФ, КНР, Мьянма и др.).

Как вытащить информацию

1. Добровольное разблокирование — владелец сам вводит PIN.
2. Взлом — эксплойты или подбор кода.

Устройство бывает в двух состояниях:

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

• Утечки Cellebrite подтверждают: GrapheneOS с обновлениями после 2022 г. пока «не берётся» взломом.
• Ради высокой безопасности проект отказывается от официального root-доступа и поддерживает только Pixel (они единственные позволяют надёжно разблокировать/перезапирать загрузчик и имеют нужные аппаратные модули безопасности).
• Песочница GrapheneOS изолирует даже закрытые драйверы-блобы (Wi-Fi, модем, Bluetooth), минимизируя риск бэкдоров.
• Пользователи LineageOS считают переход на GrapheneOS оправданным: стабильные обновления, sandboxed Play Services и «выключатель» USB-порта.
• В дискуссии о «хороших/плохих» правительствах большинство сходится: любые власти могут (и будут) злоупотреблять доступом к данным, поэтому доверять кому-либо «вслепую» нельзя.

Что такое GrapheneOS
Android для Google Pixel, заточенный под безопасность и приватность. Работает только на Pixel 8/9 (7 лет обновлений).

Профили

• Разные пользователи = изолированные шифрованные контейнеры.
• Можно полностью выключить профиль, тогда его приложения не работают в фоне.
• Переключение: тянем шторку → иконка внизу → PIN.

Google
Play Services ставятся в 1 клик из собственного магазина GOS; можно жить без Google вообще.

Установка
С браузера за 15 минут с Linux/Win/Mac; проверка образа после загрузки через TPM. OTA-обновления автоматом.

Разрешения
Сеть, камера, микрофон и т.д. – отдельно для каждого приложения и профиля. Удобно ставить апп в «владельца» без сети, потом клонировать туда, где нужно.

Производительность
Без графического shell, чистый AOSP + hardened ядро: быстрее stock-Pixel и без рекламы.

Безопасность

• Песочницы приложений, отключение метаданных Bluetooth/Wi-Fi, эксплойт-защита памяти, авто-перезагрузка если загрузчик разблокирован.
• Возможность показать «proof of boot» – что прошивка не тронута.

Мой сценарий
1 профиль – без сети, 2 – VPN+FIDO, 3 – SIM+Signal, 4 – камера. Переключаюсь по мере надобности.

Девайс
Pixel 8a, 8 ГБ ОЗУ, 256 ГБ ПЗУ, цена ~500 €, заряд 1-2 дня, камера отличная.

Итог
GrapheneOS = Pixel + годы обновлений + контроль над каждым приложением. Если нужен безопасный Android – бери Pixel и ставь GOS.

• GrapheneOS вызывает споры: кто-то хвалит «без-глючность» и песочницы, кто-то ругает отказ от root и «кастрюлю» с профилями.
• Покупка Pixel для GOS в США часто сопровождается требованием персональных данных; часть пользователей платит наличными и вводит фейки.
• Главные плюсы: сильное разграничение прав приложений, отключение Google Play, обновления без глюков, возможность мульти-профилей и VPN-наблюдения.
• Главные минусы: нет автозаписи звонков, сложность переключения профилей, проблемы с RCS/Fi/банковскими и платёжными приложениями, отсутствие root «из коробки».
• Часть комментаторов считает, что GOS всё-таки уменьшает утечки к Google, даже если сервисы Google всё же нужны; альтернативы — /e/OS, рут-образы или полный отказ от смартфона.

Коротко: в NPM проникли популярные пакеты (colors, debug и др.) через фишинг письмо «смени 2FA». Вредоносный код подменял адреса криптокошельков.
Почему это мелко: библиотеки используются в CLI-утилитах, а не в Web3; украденные API-ключи или майнеры были бы катастрофой.
Вывод: любая зависимость может быть трояном, но проверять всё дерево пакетов никто не успевает — надо успевать релизить.

• Атака на NX через NPM показала, что даже популярные плагины могут стать вектором для кражи creds и API-кейсов.
• Участники сходятся: «всё дерево зависимостей NPM по умолчанию доверяет всем», а ручная проверка каждой мелкой библиотеки невозможна при скорости релизов.
• Многие выжили лишь благодаря «отложенным обновлениям», изоляции в контейнерах или отказу от экосистемы Node/NPM целиком.
• Фишинг на домене npm.help подтвердил, что даже IT-специалисты не всегда замечают поддельные TLD; предлагают белые списки ссылок и DMARC-индикаторы в клиентах.
• Утверждение «мы просто не заметили более продвинутые атаки» звучит всё чаще: Jia Tan 3.0, по мнению комментаторов, уже где-то в supply-chain.

running-qix-malware
Репозиторий демонстрирует работу вируса QIX (1989) в эмуляторе DOS.

• Собранный DOS-бинарь запускается в браузере через эмулятор.
• Исходники на ассемблере и C, скрипты сборки.
• Инфицирует .COM-файлы, показывает бегущую линию.
• Безопасен: эмуляция изолирует вредоносный код.

• Участники вспомнили про инцидент Jia Tan и пожаловались, что npm до сих пор не автоматически блокирует публикации с обфусцированным кодом и шестнадцатеричными именами.
• Предложены меры: предпубликационный сканер с «задержкой на проверку», 2FA-апрув каждого релиза, опциональный «verified»-бейдж и поддержка Yubikey.
• Сомнения в пользе LavaMoat: не спасает от DLL в lifecycle-скриптах, не работает с Webpack HMR, а изоляция может быть дорогой.
• Обсуждали lock-файлы: хэши в package-lock защищают от перезаписи версии, но теги git всё ещё можно подменить; иммутабельность npm-тарболлов считается основной защитой.
• Namespaces (@scope) в npm есть с 2016 г., но «красивые» безскоповые имена всё ещё популярны, поэтому переход идёт медленно.

Инженеры Калифорнийского университета в Санта-Крузе разработали Pulse-Fi — систему, которая измеряет пульс через обычный WiFi без ношения датчиков.

• Точность: после 5 с обработки сигнала погрешность ≤0,5 уд/мин; показатели соответствуют медицинским стандартам.
• Работает при любом положении тела (сидя, стоя, лёжа, в движении) и на расстоянии до 3 м.
• Доступность: используются самые дешёвые WiFi-модули ESP32, поэтому подходит для условий с ограниченными ресурсами.

Алгоритм машинного обучения выделяет колебания сигнала, вызванные сердцебиением, и фильтрует шумы от движения и окружения. В испытаниях участвовали 118 человек, каждого проверили в 17 позах.

Публикация представлена на конференции IEEE DCOSS-IoT 2025.

• Wi-Fi уже умеет «видеть» сердцебиение и дыхание без всяких датчиков; новая работа UCSC просто уточняет точность до <0,5 уд/мин.
• Техника работает на обычных ESP32/RPi и, вероятно, на смартфонах, поэтому 24×7-мониторинг всей семьи становится дёшево и сердито.
• Пользователи видят плюсы: сон без браслета, поиск людей за стеной, замена PIR- и мм-волновым датчикам.
• Критики беспокоятся: данные можно продавать рекламодателям, использовать для слежки, взлома, таргетинга по эмоциям или даже ударов дронов.
• Пока нет ясности, как защититься: выключать Wi-Fi, строить «клетку Фарадея» или требовать open-source-оборудования — обсуждают всерьёз.

Ключевые выводы исследования

• 8 популярных коммерческих VPN обслуживают >700 млн пользователей, но скрывают собственность и имеют критические уязвимости.
• 3 VPN связаны с НОАК Китая, у остальных найдены признаки китайского контроля.
• Отсутствие прозрачности позволяет злоумышленникам снимать шифрование и перехватывать трафик.

Почему важна прозрачность
VPN переносят доверие от интернет-провайдера к самому сервису. При выборе пользователи должны решить:

• Прозрачность — знать, кто видит данные.
• Анонимность — не знать, но полагаться на обещания.

Риски для пользователей

• Авторитарные государства могут использовать скрытые связи VPN для слежки.
• Отсутствие публичной информации о владельцах и разработчиках усиливает уязвимости.

• Коммерческие VPN часто продаются через страх не-технических пользователей, хотя реальные сценарии — это обход геоблоков, торренты и «неполиткорректный» контент.
• Модель доверия к единому VPN-узлу критикуется; предлагаются решения вроде iCloud Private Relay и MASQUE-релеев, разделяющих «кто» и «что».
• Подозрения вызывают «популярные» VPN (Nord, Express), их рекламные бюджеты и возможные связи с разведками; Mullvad считается одним из самых прозрачных, но его IP-адреса всё чаще банят.
• Некоторые «бесплатные» или малоизвестные VPN/прокси-сервисы превращают клиентов в узлы резидентного прокси и продают их трафик третьим лицам.
• Даже при смене IP браузерное фингерпринтирование легко идентифицирует пользователя; HTTPS сделал старые аргументы «VPN для безопасности в публичном Wi-Fi» почти бесполезными.

AI-модели нуждаются в виртуальной машине

Современные приложения с ИИ включают модель в «обвязку», которая обеспечивает вызов инструментов, поиск контекста, безопасность и прочие сервисы. Первые чат-боты были простым REPL-циклом: запрос → модель → ответ. С появлением протоколов вроде MCP логика управления стала сложнее и требует свойств ОС: изоляции, расширяемости, переносимости, контроля доступа к файлам и инструментам.
Мы предлагаем рассматривать этот слой как виртуальную машину для ИИ-моделей (MVM), где одна из «инструкций» — вызов LLM. Это развязывает разработку моделей от кода интеграции и даёт «write once, run anywhere» аналогично JVM.

Зачем MVM

• Безопасность и приватность «из коробки», а не как дополнение.
• Повторное использование: любая модель подключается к экосистеме инструментов и политик безопасности.
• Переносимость: модель и политики можно поставлять и запускать в разных средах.

Пример работы

1. Пользователь: «Забронируй рейс».
2. MVM передаёт запрос модели.
3. Модель: «вызови booking-tool».
4. MVM проверяет, разрешён ли этот инструмент, и только потом вызывает его.
   Такой контроль есть в любом коммерческом ИИ-продукте; MVM выносит его в стандартизированную платформу.

Инструкции MVM

• загрузка/выгрузка модели и инструментов;
• вызов модели с контекстом;
• парсинг её ответа;
• вызов разрешённых инструментов;
• работа с памятью, историей, вводом пользователя;
• стандартные управляющие конструкции (if, seq, loop).

• Критики считают, что статья расплывчата: «VM для ИИ» сводится к обычной песочнице/контейнеру, а не к полноценной машине.
• Основная проблема — не инструменты, а разрешения: нужно точно ограничить, какие действия и данные доступны агенту, иначе он может, например, купить билет с 37-часовой пересадкой ради 3 $.
• Многие предлагают использовать уже существующие механизмы: Docker, отдельный пользователь, контейнеры, WebAssembly или capability-модель вроде Fuchsia.
• Часть комментаторов указывает, что продвинутые модели (ChatGPT Code Interpreter, OpenHands) уже работают в изолированных средах, но этого всё равно недостаточно.
• Итог: вместо новой «ОС для ИИ» нужно чёткое управление правами и данными; VM лишь метафора для этой задачи.

Можно ли разрешить sideload и остаться в безопасности?

Apple и Google утверждают: открыть установку сторонних APK — значит подвергнуть пользователей вирусам и мошенничеству. Но это не техническая, а политическая позиция.

Почему сейчас всё плохо

• Google Play Protect проверяет лишь часть приложений; зловреды всё равно проскальзывают.
• Сторонние магазины (F-Droid, Amazon) уже существуют и безопасны.
• Пользователи Android могут включить «Неизвестные источники» одним чекбоксом, но получают лишь туманное «вы можете погибнуть».

Как сделать sideload безопасным

1. Песочница + разрешения
   Приложение запрашивает только то, что реально нужно; система блокирует доступ к остальному.
2. Подписи и репутация
   APK подписывается разработчиком; ОС показывает, кто автор и сколько лет без инцидентов.
3. Сканирование до установки
   Проверка в облаке на вирусы и известные уязвимости — как Play Protect, но прозрачно.
4. Обновления и отзыв
   Приложение может обновляться только тем же подписантом; при первом подозрении — автоматический отзыв сертификата.
5. Ясные предупреждения
   «Это приложение просит доступ к SMS и ещё не проверено Google. Установить?» — с кнопкой «Подробнее».

Что мешает

• Деньги: Google теряет 30 % комиссии, если пользователи уйдут в сторонние магазины.
• Контроль: открытая платформа сложнее цензурировать.

Вывод
Технически безопасный sideload возможен уже сегодня — достаточно внедрить стандартные механизмы проверки и прозрачности. Остаётся только политическая воля.

• Вопрос «безопасность vs. свобода установки» — ложная дихотомия: большинство вредоносных программ всё равно приходит из официальных магазинов.
• Термин «sideloading» — пропагандистский; правильнее говорить «установка софта на своё устройство».
• Владелец устройства должен иметь последнее слово, а не корпорация или государство.
• Можно совместить: «безопасный» режим по умолчанию + опция «разработчик» с чёткими предупреждениями.
• Настоящая цель новых ограничений Google — не защита, а контроль и слежка под флагом европейских и американских законов.

Неприятные вопросы о верификации Android-разработчиков

Приложение ICEBlock анонимно собирает данные о рейдах ICE; после раскрытия личности разработчик получил угрозы, а его жену уволили из госструктуры. Это показывает, что анонимность бывает жизненно важна.

Вопросы к Google по новой программе верификации разработчиков:

1. Анонимные разработчики
   Как быть автору гипотетического Android-аналога ICEBlock («ICE Scream»), который по опыту ICEBlock вынужден скрывать личность?

2. Экспертиза гражданского общества
   С какими организациями (EFF, AccessNow и др.) Google консультировалась и какие изменения внесены?

3. Политика конфиденциальности
   Почему политика Google позволяет передавать «персональные данные» любым «доверенным лицам или компаниям» без ограничений?

4. Отладочные ключи
   С 2027 г. для разработки нужны debug-keystore, но они не входят в процесс верификации. Как тестировать на сертифицированных устройствах?

5. Дублирующиеся package-name
   В обучающих целях часто используют одинаковые package-name, но они запрещены. Как запускать примеры из книг и курсов?

Есть вопросы — заполните форму или пишите:

• гражданским организациям: dev.verification@commonsware.com
• самой Google: did.you.really.need.a.written.invitation@commonsware.com

• Участники резко критикуют Google за введение обязательной верификации разработчиков для сайдлоада, называя это «фашистским контролем», отказом от идеи открытого Android и шагом к полному закрытию экосистемы.
• Поднимается вопрос права собственности: «ты покупаешь устройство, но фактически арендуешь его у OEM», сравнения с запретом ставить любые шины на купленную машину.
• Люди боятся цепочки «сначала телефон, потом ПК», приводят примеры macOS Gatekeeper и даже ограничения мощности VW по подписке.
• Некоторые уже ищут выходы: LineageOS, PostmarketOS, «де-гугловские» китайские OEM, но признают проблемы с драйверами, SafetyNet и банковскими приложениями.
• Сторонники отмечают, что анонимная разработка важна для журналистов, активистов и просто безопасности разработчика, а требование раскрывать личность — удар по свободе ПО.

Суть проблемы
В npm-реестр попали вредоносные версии пакетов Nx и связанных плагинов. Злоумышленники использовали временный доступ к npm-аккаунту @nxscope и опубликовали поддельные версии 19.8.0–19.8.2.

Затронутые пакеты

• nx
• @nx/angular, @nx/cypress, @nx/detox, @nx/devkit, @nx/esbuild, @nx/eslint-plugin, @nx/expo, @nx/express, @nx/jest, @nx/js, @nx/nest, @nx/next, @nx/node, @nx/playwright, @nx/plugin, @nx/react, @nx/rollup, @nx/storybook, @nx/vite, @nx/web, @nx/webpack, @nx/workspace

Что делать

1. Удалить вредоносные версии.
2. Установить официальные 19.8.3 или выше.
3. Проверить lock-файлы и CI на наличие подозрительных версий.

• Уязвимость в пакетах Nx: токен npm скомпрометирован, злоумышленники внедрили вредоносный код через post-install скрипты.
• Малварь ищет Claude Code / Gemini CLI и использует их как «живые» инструменты для поиска криптокошельков, ключей и других секретов.
• Участники советуют отключать npm-скрипты (ignore-scripts true), использовать Bun (по умолчанию не запускает скрипты), Verdaccio для вендоринга и инструмент vet для сканирования.
• Рекомендуют разрабатывать в изолированных контейнерах/VM (cubbi, bubblewrap, firejail) и пересматривать каждую зависимость вместо «npm install наугад».
• Основной вывод: современные цепочки поставок и AI-агенты создают новый вектор атак «prompt-as-malware», а операционные системы всё ещё позволяют приложениям свободно читать весь диск.

Claude для Chrome: закрытый пилот

Anthropic запускает расширение Claude для Chrome в ограниченном режиме: 1 000 пользователей Max-плана смогут просить Claude выполнять действия прямо в браузере. Цель — собрать отзывы и отладить защиту перед публичным релизом.

Зачем браузерный агент

Большинство задач уже происходит в браузере: календари, почта, документы. Дав Claude доступ к кнопкам и формам, мы резко повышаем его полезность. Однако такой доступ открывает новые векторы атак.

Главная угроза: prompt injection

Злоумышленники могут прятать вредоносные инструкции в веб-страницах или письмах. Без защиты модель выполняет их без ведома пользователя.

В «красных» тестах 123 кейса по 29 сценариям показали 23,6 % успешных атак без защит. Пример: письмо «удалите всё для безопасности» — Claude удаляет почту без подтверждения.

Текущие защиты

• Разрешения: доступ к сайтам и действиям контролирует пользователь.
• Подтверждение: перед покупкой, публикацией или передачей данных Claude запрашивает согласие.
• Фильтры: блокируются сайты финансов, взрослого контента и пиратства.
• Классификаторы: модель распознаёт подозрительные паттерны и отказывается выполнять опасные команды.

Пилот продолжается; доступ расширят по мере роста надёжности.

• Участники обсуждают расширение Claude для Chrome, которое открывает доступ к «смертельной триаде»: приватные данные, ненадёжный контент и автономные действия.
• Безопасность вызывает тревогу: даже после смягчений 11 % атак всё ещё успешны, а визуальная модель быстро теряет контекст.
• Многие считают, что браузер должен оставаться песочницей для людей, а не для агентов; предлагают использовать API вместо UI.
• Поднимаются вопросы приватности, возможных злоупотреблений и будущего рекламной модели Google.
• Общий вывод: технология интересна, но риски пока перевешивают пользу; безопасного решения пока нет.

TL;DR
Автономные браузеры-агенты (Comet, Copilot, Comet) обещают делать покупки и управлять почтой без участия человека. Но в тестах они без сопротивления:

• купили часы в поддельном «Walmart»;
• ввели логин/пароль на реальном фишинговом Wells Fargo;
• выполнили скрытый PromptFix-скрипт (новая версия ClickFix), который через фальшивую капчу заставил агента установить вредоносное расширение и передать управление злоумышленнику.

Во всех случаях отсутствовали базовые защиты: браузеры не проверяли домены, не распознавали подозрительные формы и не запрашивали подтверждения у пользователя. Старые уловки работают, потому что ИИ доверчив и стремится «угодить» любой ценой.

Scamlexity — новая эра: мошенник обманывает не человека, а его ИИ-агента, а ущерб получает сам пользователь.

• Пользователи не верят, что ИИ-агенты способны безопасно покупать за них: финансовые риски, скам-сайты и отсутствие контроля пугают.
• Критики называют «agentic» новым хайп-словом, за которым скрывается ненадёжная система без реального «моата».
• Проблема усугубляется тем, что LLM не различают контент и команды, что делает инъекции и обман тривиальными.
• Некоторые видят пользу в рутинных закупках (молоко, витамины, повторяющиеся подписки), но только при полной прозрачности и доверии.
• Большинство считает, что пока агенты работают на корпорации, а не на пользователя, доверять им деньги нельзя.

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

Что-то пошло не так.
Попробуйте ещё раз.

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

• Участники считают, что давать LLM-агенту полный доступ к браузеру — это «смертельный трифекта»: чтение всех вкладок, кук и паролей.
• Основной риск — prompt-injection: любой сайт может внедрить команду, и агент выполнит её, потому что «каждое чтение — это запись в контекст».
• Люди сравнивают это с тем, что Microsoft делала скриншоты, но теперь молчат, когда AI получает plaintext-доступ к банковским данным.
• Единственный «безопасный» сценарий — код в git, где изменения легко откатить; всё остальное (покупки, банкинг, e-mail) считается безумным.
• Итог: без изоляции, sandbox и чёткого разграничения «что можно» агенты становятся идеальным вектором атак, а компании, их выпускающие, — объектом для судебных исков.

Внимание: перед воспроизведением отключите наушники!

Управляй колёсами тележки с телефона

Выбери систему:
Gatekeeper | Rocateq

Gatekeeper

Заблокировать | Разблокировать
(ссылки на .wav)

Rocateq

Заблокировать | Разблокировать
Активировать | Проверка покупки
(ссылки на .mp3)

Как работает

Колёса реагируют на сигнал 7,8 кГц от подземного кабеля. Тот же сигнал можно передать динамиком телефона, воспроизводя подготовленный файл. Держи смартфон рядом с колесом и нажимай «пуск».

Доклад DEFCON 29

• В Нидерландах и соседних странах колёса тележек почти не блокируются; чаще используется система «вставь €1».
• В США, Канаде и Германии блокировки популярны из-за краж бездомными, вандализма и эстетических требований торговых центров.
• Система вызывает побочные эффекты: плоские пятна на колёсах, шум, ложные срабатывания и раздражение покупателей.
• Некоторые хакеры уже экспериментировали с подделкой сигналов, блокируя или разблокируя тележки дистанционно.

• Суть атаки: при загрузке большого изображения в 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 не научатся надёжно разделять данные и инструкции, любой внешний вход считается потенциально отравленным.

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

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

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

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 и, если риск высок, просто оставить телефон домой: любое включённое радио — это маяк.

Уязвимость Copilot: доступ к файлам без записи в журнал аудита
Автор: Zack Korman, 19.08.2025

Суть проблемы

M365 Copilot может читать файлы и не фиксировать это в журнале аудита, если попросить «не давать ссылку на файл». Это позволяет скрытно скачивать данные, нарушая безопасность и требования к соответствию.

Как обнаружил

Исследуя логику аудита для новой функции Pistachio, автор заметил пропуски в журнале. Проверка показала: достаточно добавить фразу «без ссылки» — запись исчезает. Это может произойти случайно, поэтому у многих организаций журналы уже искажены.

Реакция Microsoft

• Уязвимость признали «важной» и исправили.
• Клиентов не уведомили; официального бюллетеня нет.
• Процесс MSRC занял 45 дней, ответы были формальными, без деталей.

Вывод

Журналы аудита M365 Copilot ненадёжны, а Microsoft не планирует информировать пользователей. Организациям стоит перепроверить свои логи и усилить контроль доступа к чувствительным данным.

• Copilot читает индексированные данные от имени привилегированного сервиса, поэтому не фиксирует в журнале доступ к самому файлу.
• Это приводит к утечкам: пользователь видит содержимое, но в аудите нет записи о нарушении прав.
• Исправление Microsoft ограничилось «автоматическим обновлением» без CVE и без изменения архитектуры.
• Участники считают проблему классической «confused deputy» и указывают, что фильтрация по правам в векторной БД вполне масштабируется.
• Советуют подключить Legal/Compliance и готовиться к регуляторным разбирательствам, особенно в HIPAA-окружении.

SSO Wall of Shame — список вендоров, считающих SSO роскошью, а не базовой безопасностью.

SSO позволяет компании управлять доступом через собственный поставщик идентификации (Google, Okta, Azure AD), централизованно создавать/удалять аккаунты и мгновенно отключать уволенных сотрудников. Для любой организации >5 человек это критично.

Однако вендоры прячут SSO за «Enterprise»-тарифами, где цена выше в 2–4 раза или привязана к большому пакету ненужных функций. Это тормозит внедрение безопасности.

Примеры завышенных надбавок

Вендор	Базовая цена	SSO-цена	Рост
Airtable	$10/польз./мес	$60	+500 %
Appsmith	$15	$2 500	+16 567 %
Coursera	$399/польз./год	$49 875/год	+12 400 %
Cloudflare	$20/домен/мес	$1 000	+4 900 %
Breezy HR	$171/мес	$1 500	+777 %
DatoCMS	$100/мес	$667	+567 %
Canva	$10/польз./мес	$40	+300 %
Figma	$12	$45	+275 %
Bitrise	$90	$270	+200 %
Box	$5	$15	+200 %

(и ещё ~30 компаний с ростом 15–167 %).

Вывод: если вендор «серьёзно относится к безопасности», SSO должен быть либо в базе, либо за умеренную доплату.

• «SSO-налог» — это не техническая, а ценовая сегментация: крупные клиенты обязаны иметь SSO (SOC2), поэтому за него платят.
• Поддержка SSO действительно дорога: множество тикетов, сложные интеграции, вызовы инженеров, особенно при частных IdP.
• Часть вендоров всё же даёт базовый SSO через Google/GitHub/Microsoft, но «частный IdP» остаётся маркером Enterprise.
• Малым компаниям SSO тоже нужен по контрактам, но высокие цены отталкивают; кто-то предлагает субсидии или прокси-решения.
• Итог: SSO = не «фича», а показатель зрелости клиента и объём его кошелька.

• aka.ms — коротилка Microsoft. Попытка зайти на https://aka.ms привела к логину только для сотрудников.
• akasearch.net — индекс ссылок aka.ms; нашёлся eng.ms.
• eng.ms — домен с приложением EngineeringHub. При входе через личный M365-аккаунт появился consent-запрос на доступ к профилю. После подтверждения — 500-я ошибка, но OAuth-токен уже выдан.
• rescue.eng.ms — поддомен, где после аналогичного согласия открылся Engineering Hub Rescue: список 22 внутренних сервисов Microsoft (Cloud + AI, Gaming, Finance и др.) с полным доступом через обычный аккаунт.

Итог: публичные OAuth-приложения Microsoft внутри корпоративных тенантов могут выдавать токены сторонним пользователям, если не ограничены политикой согласия. Проверьте свои тенанты на наличие подобных приложений и настройте Admin consent workflow, чтобы избежать утечек.

• Документация Microsoft по Entra ID/SSO вызывает у разработчиков «тыкание в темноте» и ошибки конфигурации.
• Уязвимости в мультитенантных приложениях возникают из-за непроверенных полей токена (iss, tid, audience) и отсутствия фильтрации по тенантам.
• Даже внутренние сервисы Microsoft открыты в интернет из-за политики Zero Trust, что увеличивает поверхность атаки.
• Исследователь получил RCE на сборочных серверах Windows, но Microsoft не выплатила ни цента, вызвав критику программы bug bounty.
• Сообщество советует: не полагаться на Entra для авторизации, всегда валидировать каждое поле токена и строить defense-in-depth.

Криптография для полицейских и военных радиостанций оказалась уязвима

Исследователи из Университета Кентукки и Университета штата Джорджия обнаружили, что алгоритм ADP (Advanced Digital Privacy), который используется в радиостанциях марок BK Technologies, EF Johnson, Relm, Tait и других, можно взломать менее чем за минуту на обычном ноутбуке.

ADP защищает переговоры полиции, армии и спецслужб, но реализует «шифрование» лишь 32-битным XOR-потоком, что делает его фактически небезопасным. Уязвимость позволяет злоумышленнику:

• Слушать переговоры в реальном времени
• Изменять команды и координаты
• Отключать группы или отдельных операторов

Проблема усугубляется тем, что:

• Производители не публикуют спецификации ADP, поэтому пользователи не могут оценить уровень защиты.
• Некоторые модели радиостанций не поддерживают современные стандарты (AES-256, P25), оставляя ADP единственным вариантом.

Эксперты рекомендуют переходить на AES-256 или P25 Phase 2, но это требует замены оборудования и перенастройки инфраструктуры.

• Kevin Mitnick в 90-х глушил полицейские рации, просто зажимая кнопку передачи; сегодня такое не пройдёт из-за P25-транкинга.
• P25 и TETRA имеют уязвимости: от «on-demand» трекинга до 56-битных ключей и закрытых алгоритмов.
• В США до недавнего времени большинство переговоров шло в открытом виде, и жители жаловались на переход к шифрованию.
• Некоторые участники описывают, как легко искать MAC-адреса полицейских ноутбуков или использовать SDR-донглы и дроны для мониторинга.
• Общий вывод: безопасность радиосвязи часто рассматривалась как пунктик, а не базовое требование, и теперь это даёт сбой.

Слишком многие сервисы используют такой вход:

• Введите email или телефон
• Сайт отправит 6‑значный код
• Введите код для входа

Пожалуйста, прекратите.

Почему это плохо для безопасности:

• Злоумышленник может отправить ваш email на легитимный сервис и заставить вас ввести присланный код в фишинговой форме. Вы не можете быть уверены, где именно нужно вводить код. Менеджеры паролей тут не помогают.
• Этот метод реально эксплуатируется: вход Microsoft для аккаунтов Minecraft использует такие коды, и уже множество аккаунтов было украдено (есть подтверждения на Reddit и YouTube, а также в документации Microsoft).

• Обсуждение критикует OTP по email (6-значные коды): уязвимость к фишингу через «партнёра-входа», спам-запросы на сброс пароля и навязывание пользователям вместо пароля/менеджеров паролей.
• Многие считают, что email-коды хуже UX: задержки, переключение аккаунтов, блокировки при путешествиях, навязчивая MFA/телефон, а также баги (отписка от рассылок ломает вход).
• Контраргументы: пароли тоже фишингуемы и часто слабые/повторяются; для нетехничных пользователей код/магическая ссылка понятнее.
• Предпочтения и альтернативы: магические ссылки вместо кодов (менее фишингуемы), TOTP, passkeys, соцлогин, менеджеры паролей, иногда даже IP-ограничения; просьбы дать выбор, а не форсить один метод.
• Безопасность email-OTP можно улучшать: сочетать короткий код и длинный одноразовый токен, строгие антифишинговые меры почтовых сервисов, ограничения на частоту запросов.
• Реальные негативные кейсы: принудительные схемы у банков/сервисов, невозможность входа без телефона, постоянные письма о сбросах, статические «коды» у некоторых приложений.
• В целом тренд: сервисы перекладывают риск на почту/Google; часть участников продвигает переход к passkeys и магссылкам как более безопасным и удобным компромиссам.

Я обожаю dotfiles.

“Dotfiles” — это конфигурационные файлы для программ и ОС, часто начинаются с точки: .bashrc, .tmux.conf, .zshrc. Когда софт не поддерживает настройку файлами, грустно: сложнее синхронизировать конфиги между устройствами и при настройке новых машин.

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

Но свои публиковать некомфортно: мои алиасы, кастомизации и решения кажутся слишком личными. Почему — точно не знаю.

У меня есть классный репозиторий с кучей всего: конфиг zsh и алиасы, tmux, neovim и vscode, Python startup-скрипт. Храню список пакетов Homebrew — ставлю на новый компьютер одной командой. Там же — CSS-правила для Stylus, чтобы везде получать нужный вид.

Для управления использую GNU Stow: структура папок позволяет командой stow [folder] раскидать симлинки по нужным местам, и изменения синхронизируются на всех машинах. Это очень удобно.

В сумме там 19 конфигов плюс весь мой neovim с плагинами. Но пока я «берегу их как тайну», пока не почувствую готовность делиться.

Если откликнулось — напишите на juhamattisantala at gmail dot com. В 2025 хочу больше глубоких разговоров с людьми со всего мира — буду рад вашему письму.

• Участники разделились: одни считают дотфайлы слишком личными/уязвимыми для публикации, другие — ценным источником обмена знаниями и вдохновения.
• Главные опасения: утечки секретов и контекста (хосты, пути, IP, корпоративные детали), риски социнженерии и отпечатков, а также стыд/страх оценки «неидеальной» личной конфигурации.
• Распространенная практика — разделение на слои: публичные «универсальные» настройки, приватные оверрайды и секреты; отдельные репозитории, шифрование (age/gpg, sops), менеджеры вроде chezmoi, myba, Polykey.
• Советы по безопасности: не хранить секреты в .bashrc и подобных, исключать их через .gitignore, использовать шифрование и хранилища (1Password ссылки, отдельные файлы, приватные репо).
• Польза публикации: обучение через чужие конфиги (vim/zsh/emacs/nvim), улучшения качества жизни через алиасы/маппинги, возможность быстро делиться и переустанавливать окружение.
• Практические подходы: файл-локальные приватные настройки, employer-специфические include-файлы, документирование и чистка перед открытием, минимизация зависимостей от нестандартного софта.
• Итоговый консенсус: «делиться избирательно» — держать публичным обобщаемое и полезное, а чувствительное и слишком личное — приватным или зашифрованным.