Hacker News Digest

Пользователь попросил Muse экспортировать файлы, которые он может видеть, и получил архив размером 2,7 ГБ сжатого и 6,8 ГБ распакованного. В нём оказалась корневая файловая система Linux-среды сессии: системные файлы Ubuntu, внутренняя документация Muse, код интеграций, шаблоны приложений, файлы памяти и журналы агентов, включая SSH-ключи. Автор не публикует архив из-за чувствительности данных.

Большая часть интересных файлов находилась в /home/hatch, /opt/hatch и /opt/hatch-image. В директории agents/ хранились 113 записей суб-агентов в формате JSONL, а в домашней директории агента — файлы вроде SOUL.md, IDENTITY.md, MEMORY.md и др. Документация включала около 20 Markdown-файлов по использованию браузера, платежам, данным, голосовым функциям и расписанию, а также гайды для WhatsApp, Mac, Tailscale и Home Link.

В /opt/hatch/skills/ насчитывалось около 68 директорий навыков, каждая с файлом SKILL.md и связанным кодом — для Google Workspace, соцсетей Meta, Outlook, здоровья, бытовых устройств и генерации медиа. Особенно примечательной оказалась документация по экспериментальной интеграции Home Link (docs/devices/home_link.md), описывающая использование ESP32-C5 с Wi-Fi и BLE для подключения Muse к домашним устройствам через прокси с отдельным шагом одобрения.

Автор отправил отчёт в программу bug bounty Meta, но получил ответ «Not Applicable» без уточнения причин. Он также связался с несколькими сотрудниками, но не добился дальнейших действий. Несмотря на попытки исследовать границы контейнера (например, через 80 открытых сокетов), escape не был продемонстрирован из-за недостатка опыта и осторожности по отношению к продакшен-системе. Для уточнений пользователь предлагает связаться по почте pete@mouse.dev.

Обсуждение уточняет, что предоставление Muse полного доступа к файловой системе виртуальной машины — запланированная особенность, а не уязвимость; поднимает спор о том, что считается «software engineering» в эпоху LLM‐агентов; раскрывает технические детали (изолированная VM на пользователя, 332 МБ Rust‐бинарник, возможный отдельный Postgres вместо SQLite); отмечает готовность Meta выпускать рискованные AI‐продукты без баг‐баунти и даёт практические рекомендации по точному промпт‐инжинирингу и будущей миграции конфигураций в базы данных.

• Спор: Некоторые комментаторы считают, что создание markdown‐файлов — это «software engineering», тогда как другие утверждают, что реальная инженерная работа заключается в оценке этих файлов, а markdown лишь продукт, а не процесс.

• Большинство участников согласны, что каждый пользователь получает отдельную VM и что агент имеет полный доступ к своей файловой системе, что является запланированной функцией, а не уязвимостью.

• Совет: Для получения желаемого поведения от Muse рекомендуется формулировать запросы максимально точно, сравнивая процесс с «взмахом волшебной лампы» — так называют «magic genie engineering».

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

• Тред отмечает, что готовность Meta запускать этически неоднозначные AI‐продукты даёт ей уникальное преимущество по сравнению с другими крупными технологическими компаниями.

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

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

• Пользователь поделился, что основной «harness» Muse представляет собой монолитный 332 МБ бинарник, написанный на Rust, подтверждая значительный размер исполняемого кода.

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

• Несколько комментариев выражают обеспокоенность, что зависимость от AI‐генерируемых markdown‐файлов свидетельствует о деградации традиционных навыков программной инженерии.

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

• Спор: Некоторые считают файлы с SSH‐ключами и внутренними документами чувствительными, тогда как другие полагают, что в контексте изолированной VM они могут не быть строго конфиденциальными.

About 20 Markdown files described browser use, connectors, payments, credentials, data handling, generated files, voice, goals, and scheduling.This the state of software engineering in 2026.Edit: clarified engineering to software engineering, which is more correct — @tolugenius

Два месяца назад меня уволили из Google за разработку Google Workspace CLI, проекта, который мгновенно стал вирусным: он занял первое место в Hacker News, набрал тысячи звёзд на GitHub и привлек десятки тысяч реальных пользователей за пару дней. Среди реакций — вопросы руководства о том, что они могут извлечь из инструмента, и проверка юридическим отделом из‑за использования логотипа и фирменных цветов в репозитории. Я считаю, что причина ухода не в конкретном CLI, а в более широкой тревоге по поводу возможного разрушения текущих процессов Workspace. Ирония усилилась тем, что за два дня до моего увольнения Google объявила о выпуске официального Workspace CLI на конференции Cloud Next.

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

• Уволенный сотрудник Google создал CLI‑утилиту, имитирующую официальное продуктное предложение, что нарушило бренд‑правила компании.
• Комментаторы обсуждают, что подобные проекты часто разрешяются в рамках 20 % времени, но здесь произошёл конфликт с внутренними процедурами и логотипами.
• Мнения разделяются: одни считают увольнение оправданным из‑за риска для репутации Google, другие видят в этом подавление инициатив и потерю таланта.
• Обсуждение поднимает вопросы о гибкости корпоративных правил, возможности официально интегрировать такие проекты и последствиях для морального климата в крупных технологических компаниях.

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

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

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