План Google ограничить боковую загрузку на Android имеет потенциальную лазейку для пользователей.

На прошлой неделе Google сделало неожиданное заявление о намерении ввести обязательную проверку личности для всех разработчиков, распространяющих приложения на Android, независимо от того, используют ли они Play Store или нет. Начиная со следующего года, приложения от непроверенных разработчиков будут заблокированы для установки на устройствах, сертифицированных с Google Mobile Services. Этот шаг вызвал споры в технологическом сообществе, многие выразили обеспокоенность тем, что Google делает Android более похожим на iOS от Apple в плане контроля и ограничений.

"Просто покупай индекс", говорили они. "Это надежно". Здесь мы обсуждаем, почему это не всегда так, и как жить с вечно красным портфелем.

Поверить в рынок

Google утверждает, что его цель — помешать распространителям вредоносного программного обеспечения скрываться за анонимностью. Однако некоторые подозревают, что у компании могут быть скрытые мотивы, такие как ограничение эмуляции на Android или препятствование развитию Android-основанных электронных читалок. В отличие от этого, Самир Самат, президент Android Ecosystem в Google, заявил, что боковая загрузка является неотъемлемой частью Android и продолжит существовать. Он также уточнил, что новые условия Google не предназначены для ограничения возможностей, а скорее для того, чтобы любое приложение, загруженное от разработчика, независимо от источника, действительно исходило от него.

Заявление Самата не прояснило ключевой аспект – метод, – что оставило людей в неведении. Они понимали намерения компании Google (блокировка Android-приложений от непроверенных разработчиков, начиная с сентября 2026 года и заканчивая 2027 годом, с целью снижения количества вредоносного ПО), но не были уверены, как эта политика будет реализована на устройствах.

Как наблюдатель, я заметил, что Google Play Protect, служба безопасности, доступная на всех сертифицированных Android-устройствах, потенциально может справиться с новыми требованиями Google к проверке разработчиков. Учитывая его роль как системного верификатора пакетов и включение в Google Mobile Services, кажется логичным, что он возьмет на себя эти дополнительные обязанности. Однако последние события указывают на то, что Google может прибегать к альтернативному подходу, который оставляет больше вопросов, чем ответов. Интересно, что есть признаки того, что некоторые существующие механизмы для установки приложений из сторонних источников могут остаться в силе, хотя это потребует использования инструментов разработчика.

Вы просматриваете информационную рассылку ‘Authority Insights’, еженедельное издание, которое раскрывает новые аспекты Android, еще не освещенные в других источниках. Если вы ищете эксклюзивные новости, последние обновления и революционную информацию об операционной системе Google Android и других темах мобильных технологий, то мы вам поможем.

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

Скоро: Проверка разработчика Android

Вместо реализации новых требований к проверке для разработчиков через Play Protect, похоже, что Google создает новый сервис под названием Android Verification Service. Это приложение будет проверять, связана ли установочная программа с разработчиком, который был проверен Google, то есть зарегистрировался в Google через последнюю версию Android Developer Console.

Как наблюдатель, я заметил, что приложение Android Developer Verifier в настоящее время недоступно на большинстве устройств, в отличие от Play Protect, которое интегрировано в Google Play Store. Однако, похоже, что в будущем это приложение будет распространяться, и Google потребует от своих OEM-партнеров предустанавливать его на новые устройства, работающие на Android 16 QPR2 или более поздних версиях.

В чем причина разработки Google отдельного приложения, вместо того чтобы полагаться на Play Protect? Это небольшое различие может привести к значительным последствиям.

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

Вполне возможно, что приложение Android Developer Verifier может каким-то образом взаимодействовать с Play Protect, но, учитывая такое взаимодействие, возникает вопрос, почему они решили сделать его отдельным приложением. Вот несколько теорий о том, почему они могли пойти по этому пути, основанных на моих обсуждениях с независимыми экспертами по безопасности и разработчиками платформы:

1. Разделение ответственности: Отделение процесса проверки от Play Protect позволяет более целенаправленно разрабатывать и оптимизировать каждую систему.
2. Масштабируемость: Наличие выделенного приложения может упростить масштабирование процесса проверки по мере роста использования приложений, обеспечивая эффективную обработку возросшего спроса.
3. Прозрачность: Отдельное приложение потенциально может предоставить разработчикам более четкое понимание того, как проверяются их приложения, способствуя доверию и открытости в сообществе разработчиков.
4. Гибкость: Наличие автономного приложения может обеспечить большую гибкость в плане модификации или обновления процесса проверки без непосредственного влияния на Play Protect.

Возможно, это просто организационный вопрос, когда разработку осуществила команда безопасности платформы Android, а не команда GMS (Google Mobile Services).
С точки зрения безопасности, отсоединение от GMS уменьшает площадь атаки. Если вредоносное приложение скомпрометирует GMS, это может повлиять на все, чем управляет GMS. Если Google сделает приложение с открытым исходным кодом, это позволит проводить независимую проверку его кода, в отличие от Play Protect.
Отделив его от GMS, устройства без GMS также могли бы использовать эту службу, при условии, что Google выпустит исходный код. Разработчики пользовательских прошивок, например, могли бы затем изменить приложение, чтобы добавить свои собственные доверенные источники вместо использования только Google. Разработчики, которые не хотят эту функцию, могли бы полностью игнорировать приложение, не затрагивая функциональность GMS.

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

Использование Play Protect упростило бы соблюдение Google новых правил для разработчиков, поскольку эта служба предустановлена на всех сертифицированных устройствах Android. С другой стороны, производителям оригинального оборудования (OEM) потребовалось бы распространять обновления с приложением Android Developer Verifier. На данный момент Google заявила только о намерении внедрить приложение на новых устройствах, не указывая на необходимость его установки на существующих.

Учитывая стремление Google усилить безопасность, было бы логично обязать использовать это приложение на всех устройствах. Однако, принимая во внимание печально известную медлительность, с которой производители оригинального оборудования (OEM) выпускают обновления или вообще игнорируют старые устройства, возникает вопрос, почему такая ответственность ложится на них.

Более того, если Google планирует распространять приложение Android Developer Verifier по беспроводной связи (без необходимости обновления операционной системы, как, например, Android System SafetyCore), то возникает вопрос, зачем просить производителей интегрировать его в свои сборки на начальном этапе?

Внедрение Android Developer Verifier, как уже упоминалось, кажется, создает больше вопросов, чем решений. Хотя это может предложить преимущества для пользователей кастомных прошивок, я задаюсь вопросом о его влиянии, учитывая недавние действия Google в отношении AOSP. Если Google планирует сделать Android Developer Verifier отдельным приложением, которое не будет отключаться при выключении Play Protect, то это потенциально может означать, что обычные пользователи больше не смогут легко устанавливать приложения за пределами магазина Google Play с помощью стандартного установщика пакетов своего устройства.

Два дня назад мы пытались получить комментарий от нашего контакта в Google относительно приложения Android Developer Verifier. К сожалению, мы не получили ответа до публикации нашего материала.

К счастью, похоже, есть потенциальное преимущество! На странице часто задаваемых вопросов Google они упоминают, что с помощью Android Debug Bridge (ADB) можно устанавливать приложения напрямую без проверки. ADB — это инструмент для разработчиков, используемый для управления устройствами Android с компьютера. Чтобы установить приложения через ADB, вам нужно просто загрузить бинарный файл ADB на свой компьютер, получить APK-файл для приложения Android, а затем выполнить команду, чтобы отправить и установить приложение на ваше устройство. Кроме того, существуют инструменты с открытым исходным кодом, которые позволяют запускать команды ADB непосредственно на устройстве, что может позволить нам устанавливать непроверенные приложения без необходимости использования компьютера. Я рад исследовать это дальше!

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

Мы надеемся, что Google сдержит свое обещание и сохранит настройку Android Debug Bridge (ADB). Любые изменения не будут внедрены еще год, что даст компании достаточно времени, чтобы пересмотреть свое решение. В идеале, мы хотели бы, чтобы Google разрешил боковую загрузку через ADB, но мы также понимаем, что компания может в конечном итоге решить ограничить этот метод, чтобы не дать мошенникам им воспользоваться.

Особая благодарность исследователю в области безопасности linuxct за помощь в проверке этой статьи!

Хотите ещё?

«Authority Insights» – это не просто новостная рассылка, это место, где мы собираем и делимся нашим лучшим контентом. Если вы увлечены Android, вам определенно не стоит пропускать наши дополнительные углубленные отчеты.

Если у вас мало времени и вы не можете прочитать все статьи, рассмотрите возможность подписки на наш подкаст ‘Authority Insights Podcast’, где я вместе с моим соведущим С. Скоттом Брауном обсудим и суммируем лучшие материалы из новостей за неделю.

Лучшие аналитические материалы этой недели

В Quick Share грядут большие изменения, включая поддержку iPhone.

Google наводит порядок в приложении Gemini, ленте Discover и библиотеках Google Photos.

Будьте внимательны: Spotify и YouTube Music получат новый дизайн в Android Auto.

Больше…

Другие главные новости

Смотрите также

2025-09-06 15:19