Hacker News Digest

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.

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

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

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

FreeDroidWarn — приложение для Android, которое отслеживает и оповещает о новых уязвимостях в установленных приложениях.
Использует открытые базы CVE и Google Play, проверяет обновления в фоне и показывает уведомления, если найдена угроза.

Основное:

• Бесплатно, без рекламы, open-source (GPL-3).
• Минимальные разрешения, работает офлайн.
• Поддержка темной темы, экспорт/импорт списка приложений.

Установка:
Скачать APK из Releases или собрать из исходников.

• Google с 2026/27 г. требует от разработчиков Android-приложений передавать личные данные; без этого приложения не будут работать на «сертифицированных» устройствах.
• У пользователей остаются варианты: старые версии Android, альтернативные магазины, рут/ADB, GrapheneOS или Linux-смартфоны, но всё требует компромиссов.
• Банки всё чаще требуют «официальные» ОС, что ограничивает свободу выбора; некоторые предлагают веб-версии или работают с GrapheneOS.
• Обсуждаемая библиотека-уведомление оказалась тривиальной и избыточной; лицензию быстро сменили с GPLv3 на Apache-2.0, чтобы не пугать разработчиков.
• Общий вывод: технические «заплатки» не решают проблему, нужны антимонопольные законы и давление со стороны пользователей и законодателей.