Видимо, последняя часть. Но кто его знает?

Часть 3: почему он мне не нравится

Да, я решил сразу сказать итог. Макс, как выбор для национального средства общения, мне не нравится. Я объясню почему, разумеется. Но хорошо, что ничего не поправимого не случилось и Макс можно вытянуть в решение, которое будет совершенно съедобным. Главное, чтобы безопасность и качество были ПЕРЕД желанием заработка денег.

Это VK (Мейлу Груп)

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

Но это потому что мы здесь, в России, привыкли, что наши разработки прям вообще лучше из лучших. Мировые конкуренты только потому конкуренты, что имеют изначально сильно больше денег, чем любая российская компания и могут убить кого угодно прежде чем тот станет слишком опасным. Это может быть и прямое убийство, как это было с Яндекс.Кит, и насаживание своих решений с блокированием альтернатив (как это было с Виндовс Фон), и совсем умный подход с «мягким» подсаживанием на иглу в течение долгого времени (как это происходило с Windows и MS Office).

В общем, у нас у самих очень серьёзные требования к приложениям. И мейлу.ру, к сожалению, уже давно перестал отвечать им в полной мере. Нет, он вовсе не упал до уровня международного стандарта (читай – днища, пример тому Фейсбук), он упал именно для нас. Лично я виню в этом тех, кто продавливает в продукты:

• рекламу
• неправильный (для платформы) UX

Опишу это на примере RuStore. Потому что он уже не в статусе беты, как Макс.

Реклама

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

ДАЖЕ СУКА ТОТАЛИЗАТОРЫ!!!! МЕЙЛ ВАШУ ЗА НОГУ ВК, ВЫ ОХРЕНЕЛИ ТАМ СУКА ЧТО ЛИ?!?! КАКИЕ СУКА СТАВКИ?! ВООБЩЕ БЕРЕГА ПОПУТАЛИ?! МНЕ ВЕДЬ НЕ ХВАТАЕТ УДОВОЛЬСТВИЯ УДАЛЯТЬ ОШИБОЧНО УСТАНАВЛИВАЕМЫЕ ПАРАШНЫЕ ПРИЛАГИ, АВТОРЫ КОТОРЫХ ВАМ ПРОПЛАТИЛИ И ВЫ СТАЛИ ИХ ПОДСОВЫВАТЬ В РАЗДЕЛЕ ОБНОВЛЕНИЙ. НАДО ЕЩЁ ТУДА СТАВКИ ПИХАТЬ! А ЧЕГО НЕ СЛОТ МАШИНЫ, А, СУКА?! МНЕ УЖЕ ЖДАТЬ ОФИЦИАЛЬНЫЕ ПРИЛАГИ ДЛЯ ГИДРЫ?

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

Неправильный дизайн

Если вы на Android, то вам крайне неудобно работать в Максе. Вы не понимаете, почему сейчас попали на какой-то экран и как быстро вернуться обратно. Вы не отличаете описание от реальной настройки и не понимаете, а какая настройка сейчас выбрана в показываемом диалоге. Это не потому что вы тупой, а потому что дизайнерам запретили делать дизайн под Андроид. Или же дизайнеры никогда не работали с Андроид. Какой бы вариант ни был, результат всё равно один. Макс неудобен, потому что он неправильно свёрстан и использует неправильные вьюхи.

На самом деле проблема может быть и из-за BDUI, конечно, но это всё же решаемо, хоть и требует больше сил. Не считая того, что сам BDUI не нужен, это просто дно, это неуважение к пользователю. Но, к сожалению, это более-менее оправданный подход, когда вы на волоске от удаления из всяких аппсторов. Но ведь BDUI не обязывает вам ещё и свои вьюхи пихать, ужасные, противные. Будьте добры сделать разные лаяуты для разных платформ и использовать нативные вьюхи, а не из вашего упоротого UI Kit.

Это VK (Мейлу Груп) в худшем проявлении

Смотрите какая штука. В предыдущих статьях, а также у себя в бложике в Федивёрсе я поддерживал идею национального мессенджера и постарался объяснить свою позицию. Но я, как пользователь и как человек, который чуть-чуть трогает инфобез, хотел бы национальное средство коммуникации не от конкретно Мейл.ру, а от группы компаний. Где во главе угла была бы безопасность, лишь потом удобство. И вообще бы не участвовал коммерческий выхлоп.

Правильное национальное средство общения

Объявляется конкурс, можно даже среди своих, а не общенациональный (потому что уровень не тот, где Вася может участвовать), где описывается ТЗ.

ТЗ включает в себя тонну требований, включая аудиты безопасности, требования по доступности, нагрузке, поддерживаемым платформам (все из Реестра ОБЯЗАНЫ быть), срокам сопровождения и др.

Отдельно определяется круг тех организаций, которые проверяют выполнение требований. Разумеется, сюда могут попасть только кристально русские, безо всяких «часть бизнеста тут, часть – там».

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

И вот в гонку бы впряглись и Мылору, и Касперские, и Бизон, и Позитивы, и Яндекс и бог знает кто ещё. И чтобы выбрано было бы то решение, которое бы и отвечало ТЗ, и было бы поддержано большинством голосов тайным голосованием. При чём не нужно было бы предоставлять готовое решение. Достаточно было бы выйти с подробным описанием этого продукта и объяснением подходов. Потому что нечего тратить время на то, что потом будет переписано нормально.

И вот мне кажется, что в этом соревновании победил бы не Мейл.ру.

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

Всё ли так плохо

На самом деле нет. Это самый обычный мессенджер, просто неудобный. Но он работает. Разработчики внутри Мылору – это, всё-таки, нормальные такие инженеры. Своё дело они знают и делают его хорошо. Они ведь не взяли какое-то готовое решение, не перекрасили и не выдали за своё. И работали они, я уверен, сверхурочно и с усердием. У меня нет никаких претензий к R&D. И также уверен, что они и дальше продолжат улучшать продукт. К примеру, я жду, когда ширину облачков сообщений сделают правильную, а не как сейчас.

И у нас никуда не делись ни Бизоны, ни Касперские, ни Инфовоч, ни Яндекс, ни Позитивы, ни кто-либо ещё. Взамен на налоговые послабления наши слоняры должны проводить аудиты важных систем, включая средство общения. Вот чтобы это была как работа, а налоговые послабления — это вид оплаты за эти работы.

И в ВК тоже не дураки. Они и сами партнёрятся с безопасниками. К примеру, Макс использует WhoCalls от Лаборатории Касперского для проверки телефонных номеров. В прошлой статье я писал, что классно было бы проверять ещё файлы и ссылки.

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

MAX lib

Было бы интересно, если бы Макс был опубликован как библиотека. Чтобы правильные участники (те, кого перечислял выше) могли бы сделать свою обёртку над библиотекой. То есть обязаны сохранить все фичи, но вправе добавлять своё, что не будет ломать обратную совместимость. А народ бы просто выбирал, какой дизайн им нравится больше. Зачем это тем же Касперским? Потому что в заголовке будет написано, что это Касперы, в инфо. Вот ссылочки на сайт, на другие продукты ЛК.

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

Почему он не нравится другим

Я рассказал, почему Макс не нравится мне. Точнее не нравится, как он стартанул. Очень надеюсь, что будет объявлено о партнёрстве с монстрами ИБ нашей страны и тогда я буду крепче засыпать.

Глобально претензии такие:

• нечестная конкуренция
• читают переписку
• посадят

Нечестная конкуренция

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

Макс объективно тут безопаснее. И дело не только во WhoCalls, который не встроен в конкурентов. Про блокировки SIM я рассказывал в одной из прошлых статей и повторяться не буду.

А вот что действительно плохо — так это то, как были преподнесены блокирования звонков у конкрентов. Бан, а потом отмазки про мошенников. Государство (снова отсылаю к прошлым статьям, где я пояснял, что понимаю под государством) наше совершенно не умеет в правильные формулировки и правильно преподносить новости.

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

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

Чтобы было понятнее. Понадобилось одной стране заткнуть того, кто много говорит — этот кто-то вдруг стал насильником. И одно дело поддерживать правдоруба, а другое дело (для народа, имею в виду) — поддерживать сраного насильника.

В общем, что хочу сказать. Это не Макс ведь блокирует звонки. Вы можете представить, чтобы разраб, который пилит фичу звонков, думал: “Так, надо блокнуть Телегу”? Тут государство делает дичь, а прилетает Максу. Это Государству следует научиться правильно распространять НУЖНОЕ и ВАЖНОЕ программное решение. Макс то при чём? Но дичь уже совершена и отменять её — это ещё более тупо будет. Со временем, разумеется, отменят. Скажут, что всех победили и отменят. Но Макс уже в говне за действия не его повозили и возят до сих пор.

Читают переписку

Нет, не читают, в общем смысле. Но обязаны хранить. Как, собственно, обязаны хранить переписки вообще все во всех цивилизованных странах. Законы такие вот. Как только к Протону пришли правильные люди, тот сразу всё сдал.

Что значит “в общем смысле”. Переписку вашу не читают люди в GMail, скажем, но её вполне читают всякие скрипты Гугла, чтобы знать о вас вообще всё. Аналогично её не читают в общем смысле в Телеге, но её читают скрипты, чтобы продавать нас всех как товар рекламодателям.

Я очень надеюсь, что к национальному средству общения выдвинуто требование, запрещающее использовать переписки пользователей для своих, мылорушных целей. Просто видя, что делают с РуСтором, я опасаюсь, что через несколько лет (сейчас побоятся, но подождите лет 5) будут продавать личности рекламодателям, как это делает Телега.

Посадят

А ты не воруй. Практически в любом популярном средстве общения обсуждать что-то незаконное — это прям тупо. Хочешь незаконное — использую специализированные средства общения типа Briar. Вон, WA на худой конец. Только не Телегу, конечно.

Сегодня законно, а завтра — нет

Давайте закину в ту же тачанку. Если вы поищите все дела, когда кого-то брали за жопу за то, что сначала было законным, а потом перестало, то выяснится, что всякий раз человек продолжал делать нечто незаконное, даже когда оно таковым стало. Спонсируешь терроризм? Ну, ёпти, добро пожаловать на бутылку. И не важно, что закинул 100 рублей. Неотвратимость наказания, вся хурма.

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

Возьмите идиотов из “Отказников Шереметьево”. Их самих просят показывать переписки. Они вправе отказаться от этого. Ну а погранцы вправе не пустить на этом основании. Это в любой стране так.

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

И да, гейские темы в личке вы можете обсуждать с кем угодно — это совершенно законно. Правда до тех пор, пока на вас не пожалуется кто-нибудь, кому это не нравится. Аналогично, к слову, с дик пиками. Пришлёте кому-то хрен, а на вас пожалуются. И, не смотря на то, что это было в личке, это преступление. Со стороны жертвы получат доступ к переписке — вот и причина запросить у ВК другие переписки, т.к. жертва может быть более чем одна. Потом остальных получателей позовут как свидетелей.

Так что дик пики присылайте только если та сторона точно это одобряет.

Заключение

Я надеюсь, что за все эти части смог объяснить свою позицию. Вот она всего в двух пунктах:

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

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

После второй части я честно хотел перейти к третьей, в которой бы описал своё личное отношение к конкретной реализации «национального средства коммуникации» от VK под названием MAX. Однако коллега подкинул очередной «разбор»/«анализ» Макса и не где-нибудь, а на Хабре.

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

Хотя именно в этом “разборе”, мне кажется, ИИ особо не участвовал. Я читал уже удалённый, самый первый, который стал популярным. Вот там вообще ИИ бред был очевиден. Замечание о внешних файлах. Скриншоты я не храню у себя, а буду ссылаться на них в оригинальных статьях. Так что если со временем статья будет недоступна, то и скриншоты будут недоступны.

MAX без оболочки: Что мы нашли в его APK

Доступ к контактам

После того, как я ввел номер телефона и подтвердил его, «Макс» попросил доступ к моим контактам (Рисунок 1). Достаточно стандартное поведение для мессенджера, позволяет находить контакты из списка, зарегистрированных в «Максе»

Рис. 1:

После этого, «Макс» снова запросил доступ к контактам (рисунок 2).

Рис. 2:

Строго говоря, это не является ошибкой разбора. Это кривой UX — реально одна из важных проблем MAX. На первом скриншоте нет никакого запроса доступа, хотя и похоже на него. По рекомендациям Google, перед запросом некоторых (не всех) разрешений, нужно сначала объяснить, зачем они нужны. И то, это правило довольно жидкое. Если пользователю так понятно, зачем разрешение запрашивается, то предварительного объяснения не нужно. Например, пользователь нажимает «Поделиться местоположением». Приложение сразу же может запросить разрешение на местоположение, если оно ещё не предоставлено. Потому что пользователь точно понимает, к чему этот запрос. А вот другая ситуация. Приложение может выполнять автоматические фоновые работы и, важно, может это делать в любых Wi-Fi сетях или конкретных. И тут проблема. Если пользователь желает выполнять фоновые работы только в своей домашней Wi-Fi сети, нужно запросить разрешение на геолокацию. Это происходит потому что получать расширенные данные о Wi-Fi точке можно только при наличии такого разрешения. Но пользователь ведь этого не знает. В этом случае сначала можно написать, что так и так, если выберешь такой вариант, придётся предоставить такое разрешение.

Доступ к контактам — это действительно не самая нужная вещь для средства общения, т.к. он вполне может использовать и свою записную книгу, не зависимую от системы. Так что это нормально — сначала объяснить, что далее будет такой-то запрос и вот почему. Но объяснение нарисовано отвратительно, как и вообще весь UI Макса. Он совершенно не похож на другие приложения и, самое главное, на ОС, в которой работает. Это объяснение действительно очень похоже на запрос разрешения, только в iOS. Но это не оно, это такое кривое объяснение. А вот второй скриншот — это правда системный запрос.

были запрошены доступ к камере, демонстрации и записи экрана (демонстрация экрана в звонке есть, а вот функционала записи я не увидел)

Потому что демонстрация экрана (шаринг экрана, если кому-то так привычнее) — это буквально его запись. Экран записывается и этот видеопоток уже отправляется получателю. В общем, это нормально, так и должно быть.

AndroidManifest.xml — один из самых важных и интересных для исследователя файлов. Он содержит много информации, по которой можно составить представление о приложении, и даже сформировать поверхность атаки. В архиве он представлен в закодированном виде.

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

REQUEST_INSTALL_PACKAGES – может устанавливать другие приложения

Если быть точным, то может запросить разрешение на установку приложений, а его можно и не предоставить. Потому что в Android ни одно приложение не может ставить другие. Это доступно только встроенному PackageManager. Остальные могут лишь просить его что-то установить. Оно потому и называется REQUEST_* К сожалению, очень много приложений объявляют это разрешение без реальной необходимости. Оно есть у Chrome, Firefox, WhatsApp и многих других. Кто-то объявляет его «для удобства», например браузеры. Кто-то — потому что правильно боится, что его могут вышибыть из Google Play, а обновиться как-то нужно.

Эта часть изменена. Мне подсказали, что MAX ведёт себя разумнее других. Старый текст оставлен под спойлером.

Макс, как и другие средства общения, позволяет установить присланный apk из него. Я считаю это плохим свойством именно для национального мессенджера. То есть оно плохое в принципе — ни браузерам, ни мессенджерам, никому, кроме файловых менеджеров или, лучше, специализированных инсталляторов нельзя устанавливать приложения. КОНЕЧНО ЖЕ, это удобно. Удобно то, что скачал файл, тут же запустил и установил. Но это удар по безопасности. Собственно, 99% (выдуманное число, но уверен, близкое к истине) всех троянов распространяются не через официальные магазины приложений, а через присылание их в чаты в мессенджерах и завлекаловок “бесконечные деньги в вашем банке, качайте по ссылке” в браузере. Трояна установить очень легко. А вот скачать, потом найти в файловом менеджере, запустить — это уже сложнее. Так вот безопасность должна быть удобнее опасности. В качестве примера приведу настройку телефона при первом включении. Вы можете пропустить установку пароля, да. Но установить его проще, чем пропустить. При пропуске вам ещё немного поколупают мозг (недостаточно, я считаю). Вот и получается, что безопасно сделать удобнее, чем опасно. Так должно быть и для исполняемых файлов. А для национального мессенджера — так должно быть ОБЯЗАТЕЛЬНО.

К чести Макса, его поведение всё равно лучше, чем у многих других. Если вам прислали apk и не важно, ваш это контакт или ещё кто-то, то при попытке просто загрузить его с сервера будет выдано предупреждение, что это файл опасного типа.

Как должно быть, на мой взгляд: – предупреждение об опасном типе файла, как сейчас – только скачивание и сохранение, без запуска

К слову, я загрузил eicar.com в ТГ и Макс. Оба они не определили в нём вирус. Это означает, что ни тот, ни другой, не используют никаких антивирусных движков, по крайней мере из более-менее популярных. Было бы неплохо национальному средству общения запартнёриться с Лабораторией Касперского и отправлять хеши файлов им. Не файлы, а только хеши. У Лаборатории есть сервис, который по хешу выдаёт рейтинг файла, если тот известен. Это ещё сильнее усилило бы безопасность Макса.

К сожалению, автор «исследования» не озаботился нормальным объяснением и предложением своего подхода.

Резюмируя: стандартное, но плохое (для национального средства коммуникации) разрешение. Apk файлы (и не только, любые исполняемые на всех платформах) нельзя запускать на исполнение, только скачивать. Одного предупреждения (но за него спасибо, без шуток) мало. Нужно понимать, что это НАЦИОНАЛЬНЫЙ МЕССЕНДЖЕР. Если в Госуслугах будут приходить фишинговые письма, это ведь ужас. А тут будут приходить трояны, это 100%

SYSTEM_ALERT_WINDOW – может показывать окна поверх других приложений

Уже не имеет смысла. Это устаревшее разрешение и сейчас, чтобы его получить, нужно прям постараться. На современных версиях Android без помощи Google вообще мало кто сможет понять, как это разрешение предоставить. Я уверен, что это хвост от родителя Макса, кем бы он ни был (Там-Там, Сферум, что там ещё). Современный же способ показывать себя поверх других окон — это использовать полноэкранные уведомления. Они то как раз и защищены разрешением android.permission.USE_FULL_SCREEN_INTENT, о котором исследователь написал ниже. Это критически важное разрешение для любой звонилки (если у неё нет «роли звонилки» — очень специфичное API, который MAX не использует). Без него нельзя показать экран принятия или сброса звонка.

Резюмируя: устаревший и бесполезный. Его нельзя выдать. Разработчики удалят его, когда руки дойдут. Сейчас он просто объявлен, но ничего не делает.

RECEIVE_BOOT_COMPLETED – автозапуск при старте системы

В целом да, но давайте более полно опишем суть этого ресивера. Если он объявлен в Манифесте, то Android, после загрузки и, важно, разблокирования устройства, пошлёт уведомление об этом событии приложению. Приложение не просто запустится. Оно, собственно, не может «запуститься» в терминах Windows, к примеру. Но зато приложение сможет выполнить критические для него действия. К примеру, обновить токен для пушей (иначе пуши отвалятся), пересоздать задачи для фоновых работ. И, важно, делать это приложение может не бесконечно долго. Android уже давно сильно ограничивает работу фоновых приложений. Так что Макс, как и абсолютно все другие, просто выполнят всякие прям критические для них задачи и на этом успокоятся. Запустится, а потом закешируется системой, лишь один и множества компонентов приложения.

Что важно — этот ресивер сам разработчик может иногда даже не объявлять, а оно всё равно будет. Вот пример с моим приложением: https://gitea.myachin.xyz/umnik/SaveTo/src/branch/master/app/src/main/AndroidManifest.xml Вы можете видеть, что получатель не объявлен мною в Манифесте, но он есть в приложении всё равно. Потому что я использую библиотеку для создания задач (чищу кеш периодически) от Google, а вот она уже добавляет ресивер при сборке, т.к. он ей нужен ей самой.

Резюмируя: стандарт. Есть примерно у всех.

DISABLE_KEYGUARD – отключение блокировки экрана

Сразу несколько раз неправильно. Вот правильно: – отключение работаЛО, только если экран блокирования не является безопасным. Другими словами, если пользователь не включил ни пароль, ни паттерн, ничего, то приложение могло обойти экран. Например, тап на уведомление от приложение позволило бы сразу открыть его – отключение работаЛО до Androiod 4.0.3. С тех пор работать перестало

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

Резюмируя: не работает и уже исключено из Манифеста

USE_FULL_SCREEN_INTENT – полноэкранные уведомления

Да. Потому что SYSTEM_ALERT_WINDOW устарел и больше не работает.

Резюмируя: правильный современный способ показать что-то на весь экран. Например экран входящего звонка

READ_CONTACTS, WRITE_CONTACTS – полный доступ к контактам

Да. Чтение нужно, чтобы имена написать на экране, а запись нужна, чтобы добавить свои (в смысле мессенджера) данные к существующим контактам или создать новый. Вы гарантировано видели поля того же WhatsApp в информации о контакте в системной записной книге

Резюмируя: нормальное поведение для обычного, не секретного, средства общения

ACCESS_FINE_LOCATION – точная геолокация. Постоянное отслеживание точного местоположения пользователя в реальном времени.

Да. Нет.

Да — это разрешение для получения более-менее точной геолокации. А ещё оно же нужно для того, чтобы узнать имя Wi-Fi сети, о чём я писал ранее. Этим разрешением много что защищено, к сожалению. Раньше даже обнаружение блютуз устройств им защищалось.

В Максе действительно есть возможность поделиться своим местоположением. Разрешение не запрашивается, пока не попытаешься поделиться впервые. Можно выдать на один раз. Кстати, если не выдать разрешение, то можно увидеть сообщение, которое описывает возможные будущие возможности. Например, поиск собеседников поблизости.

Нет — для отслеживания в реальном времени нужно ещё запросить разрешение на фоновую геолокацию. Иначе как только свернёшь приложение, доступ фиче пропадёт. Разрешение называется ACCESS_BACKGROUND_LOCATION и в последней версии оно не объявлено в Манифесте.

Резюмируя: разрешение нужно для вполне конкретной возможности и используется по назначению. Фоновое получение геолокации невозможно.

CAMERA – доступ к камере

RECORD_AUDIO – запись аудио

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

Резюмируя: очевидно нужные разрешения, запрашиваемые по делу.

READ_EXTERNAL_STORAGE, WRITE_EXTERNAL_STORAGE – доступ к файловой системе

Да, но с оговорками. Оба эти разрешения уже устарели. Посмотрите на скриншот из статьи:

Если что, вот дополнительно скопировал из Манифеста только что:

     <uses-permission
        android:name="android.permission.READ_EXTERNAL_STORAGE"
        android:maxSdkVersion="32"/>
    <uses-permission
        android:name="android.permission.WRITE_EXTERNAL_STORAGE"
        android:maxSdkVersion="28"/>

Обратите внимание, что разрешения ограничены до Android 9 и Android 12. То есть если у вас Android 13 и новее, этих разрешений не будет в принципе. Дополнительно здесь можно снова увидеть, что в приложении остались хвосты родителя. Потому что android:maxSdkVersion="28" говорит, что на версиях 29 и новее (это 9-ка) разрешение не используется, а android:minSdkVersion="29" в этом же Манифесте говорит, что apk в принципе нельзя поставить на Android ниже 10.

Резюмируя: устаревший способ, оставленный для обратной совместимости на уже устаревших версиях Android.

READ_MEDIA_IMAGES, READ_MEDIA_VIDEO – доступ к медиафайлам

Да. Это современный способ, который появился в Android 13. Его прелесть в том, что он не даёт приложению просто так ходить по вашей файловой системе. Система отдаёт вам на управление, какие файлы приложение может получить, какие не может.

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

READ_PHONE_NUMBERS – доступ к телефонным номерам

Резюмируя: разрешение уже удалено в последней версии.

GET_ACCOUNTS, AUTHENTICATE_ACCOUNTS, MANAGE_ACCOUNTS, USE_CREDENTIALS – полный доступ к аккаунтам. Может получить список всех аккаунтов (Google, соцсети, почта) на устройстве и манипулировать ими.

Сразу же скажу, что это удалено уже из кода, потому что устарело сто лет назад. Но хочу обратить внимание на качество исследования.

GET_ACCOUNTS — это действительно разрешение. Оно нужно для получения списка учётных записей. Вполне себе обыденное действие для любого приложения, которое эти учётные записи в системе создаёт. Обращали внимание, что одно приложение часто позволяет авторизоваться сквозь другое, а иной раз без необходимости вообще что-то делать, кроме как нажать “Войти”? Вот этот механизм работает через учётные записи. К примеру, приложения Яндекса создадут вам учётную запись и все новые приложения от Яндекса в вашей системе попытаются найти, может уже есть авторизованная учётка. Если да — переиспользуют её.

AUTHENTICATE_ACCOUNTS, MANAGE_ACCOUNTS и USE_CREDENTIALS – это вообще адок. Google УДАЛИЛ эти разрешения из системы. Не объявил устаревшими, а вообще удалил, будто их никогда и не было. Вы можете до сих пор встретить их в уже устаревшей документации, но вы не найдёте их среди известных даже с пометкой Deprecated.

Резюмируя: разрешения уже удалены из кода в последней версии.

USE_FINGERPRINT – доступ к биометрии

Как-то странно сформулировано. Это не доступ к биометрии, а возможность повесить биометрию как способ разблокирования приложения. Думаю, блокировку приложения через биометрию вы все видели миллион раз.

Это, кстати, устаревшее, хотя и работающее разрешение. Оно устарело в Android 9 (напомню, Макс требует минимум Android 10) и на смену ему пришло USE_BIOMETRIC. И в Максе оно тоже объявлено в последней версии приложения. Значит устаревшее скоро удалят, просто руки ещё не дошли.

Резюмируя: нормальное разрешение для средств общения. Уже заменяется на актуальное USE_BIOMETRIC.

INTERNET – полный доступ в интернет

Да. Только не понимаю, к чему тут слово «полный». Это разрешение одинаково хоть для полного, хоть для частичного. Если используешь сетевые запросы хоть в каком-то виде, будь добр объявить это разрешение.

Резюмируя: нормальное разрешение для средств общения.

ACCESS_WIFI_STATE, ACCESS_NETWORK_STATE – мониторинг сети

Ну, вроде и не соврал, но как-то сформулировано гаденько, учитывая тон статьи. Эти разрешения нужны чтобы просто понять, можно ли в этой сети работать или нет. При чём сам Google говорит, что это не опасные разрешения и Android выдаёт их автоматически. Они не позволяют понять, где ты находишься, к примеру. Но позволяют узнать, жива ли сеть, платная ли она. Эти разрешения даже не обязательно объявлять вручную, см. пример выше с получателем уведомления о загрузке. Эти разрешения автоматически добавляют библиотеки Google для всяких фоновых работ. Потому что может быть тяжёлая задача, типа отправки файла в фоне на полгига. Хорошо бы её выполнять в нетарифицируемой (бесплатной) Wi-Fi сети. Приложение, когда создаёт задачу, выставляет такие флаги и библиотека берёт на себя понимание, подходит ли конкретно та сеть, к которой подключены прямо сейчас, для задачи или нет. При чём второе разрешение нужно для тех же мобильных сетей. Скажем, не грузить файлы в роуминге.

Резюмируя: нормальные разрешения для средств общения, где может быть большой трафик.

Bluetooth разрешения – полный контроль Bluetooth

Сначала дам скриншот из статьи:

Во-первых, разрешения уже режут, т. к. часть из них устарела или не имеет смысла:

    <uses-permission
        android:name="android.permission.BLUETOOTH"
        android:maxSdkVersion="30"/>
    <uses-permission android:name="android.permission.BLUETOOTH_CONNECT"/>

Во-вторых это не полный контроль, а просто подключение беспроводной гарнитуры для общения голосом. В-третьих уже устаревающий, но ещё живое разрешение android.permission.BLUETOOTH ограничено сверху и не существует на Android 12 и новее. Там уже используется современное android.permission.BLUETOOTH_CONNECT.

Резюмируя: нормальные разрешения для средств общения.

CHANGE_WIFI_STATE – изменение состояния Wi-Fi. Могут мешать работе сети, перехватывать трафик.

1. Уже удалено, его нет сейчас в Манифесте
2. Даже если бы не было удалено, Андроид уже давно не позволяет управлять Wi-Fi сетями. Приложение может управлять Wi-Fi сетью, только если оно само её и создало (не считаем всяких админских прав и системные приложения). Остальные идут лесом

Резюмируя: уже удалённый хвост. Использовался когда-то для просто понимания состояния сети.

[Подозрительный] Сервис для звонков с доступом к камере и микрофону

        <service
            android:name="one.me.calls.impl.service.CallServiceImpl"
            android:exported="false"
            android:foregroundServiceType="microphone|camera|mediaProjection|mediaPlayback"/>

Думаю, иметь сервис для звонков для звонилки — это не подозрительно. Но разберём, что тут написано, потому что это просто полезно.

Для начала нужно понять, что такое foreground service (сервис переднего плана). Сервис — это такой компонент приложения, который не имеет UI и используется для длительных работ. К примеру, нужно вам скачать файл — имеет смысл переложить эту задачу на сервис. Сервисы могут быть фоновые (background) и переднего плана. О существовании фоновых пользователь не знает и не видит их. А вот сервисы переднего плана обязаны создать видимое пользователю уведомление. Если его не создать, Андроид сразу убьёт приложение. Типичный пример — музыкальный плеер. Они не просто так уведомления вешают, хоть это и удобно. Если не повесят — они не смогут работать в фоне.

Современный Андроид работает так, что если пользователь чего-то не видит и это что-то не системное или не имеет особенных, очень сложно получаемых прав, то это что-то будет убито.

• android:name="one.me.calls.impl.service.CallServiceImpl". Это путь к самому сервису звонка. Иначе Android не поймёт, где его искать
• android:exported="false". Сервис недоступен внешним приложениям. Его запустить может только сам Макс или Андроид. Это правильный флаг безопасности, так и надо делать
• android:foregroundServiceType="microphone|camera|mediaProjection|mediaPlayback". Начиная с Android 14, приложение обязано уведомить, для чего вообще используется сервис переднего плана. И вот вы, читая эту строку в Манифесте, тоже понимаете, для чего сервис используется. Звонилке он нужен для того, чтобы она имела доступ к микрофону, к камере, могла транслировать экран телефона и воспроизводить звук

Резюмируя: абсолютно корректное объявление необходимого сервиса переднего плана

[Подозрительный] Сервис медиа-проекции (может записывать экран)

        <service
            android:name="ru.ok.tamtam.android.calls.MediaProjectionService"
            android:exported="false"
            android:foregroundServiceType="mediaProjection"/>

Хотя фича трансляции экрана есть и даже используется в CallServiceImpl, я не нашёл в коде приложения вызова этого сервиса. Больше всего это похоже на хвост от ТамТам, который будет удалён в будущих версиях. Сейчас это просто мёртвый код, никем не вызываемый. Т. к. android:exported="false", то можно быть уверенным, что и сторонние приложения этот код не смогут вызвать.

Резюмируя: скорее всего мёртвый код, который ещё не удалили. Актуальный код находится в one.me.calls.impl.service.CallServiceImpl.

[Опасный компонент] LinkInterceptorActivity с возможностью перехвата deeplinks

android:exported="true" (Критическая уязвимость). Эта активность может быть запущена извне — другим приложением на устройстве или даже из браузера по специальной ссылке.

Нет, это не уязвимость, а нормальное поведение для глубоких ссылок/дип линков (deeplink). Они для этого и созданы.

android:excludeFromRecents="true" (Тактика скрытности). После того как пользователь завершит работу с этой активностью, она не появится в списке последних приложений (который вызывается кнопкой “Недавние”).

Это рекомендуемое поведение для глубоких ссылок.

Давайте разберёмся, что такое глубокие ссылки. Странное название, правда? Вот простая ситуация: вам нужно объяснить человеку, как найти в RuStore какой-нибудь MAX. Нужно объяснять, как запустить РуСтор, что написать в поиске, какое из найденных приложений выбрать. А можно просто прислать ссылку market://details?id=ru.oneme.app и Андроид спросит, каким Магазином её открыть. Выбери хоть Google Play, хоть RuStore — откроется сразу правильный экран. Глубокие ссылки позволяют открыть сразу нужный экран приложения, в какой бы жопе этого приложения он не был. Можно даже сделать экраны, которые кроме как по глубоким ссылкам недоступны.

Теперь понятно, почему android:exported="true"? Иначе же внешние приложение не сможет экран открыть. И очевидно, что в списке Недавних экраны сотой глубины вложенности не нужны. Потому вполне разумно их исключить.

Вот как на самом деле выглядит код, кусочек которого предоставил автор:

        <activity
            android:theme="@style/OneMe.Theme.Transparent"
            android:label=""
            android:name="one.me.android.deeplink.LinkInterceptorActivity"
            android:exported="true"
            android:excludeFromRecents="true"
            android:launchMode="singleTop"
            android:configChanges="orientation"
            android:windowSoftInputMode="adjustResize|stateHidden">
            <intent-filter
                android:label="max"
                android:autoVerify="true">
                <action android:name="android.intent.action.VIEW"/>
                <category android:name="android.intent.category.DEFAULT"/>
                <category android:name="android.intent.category.BROWSABLE"/>
                <data android:pathPattern="/..*"/>
                <data android:scheme="http"/>
                <data android:scheme="@string/web_scheme"/>
                <data android:host="@string/app_host"/>
            </intent-filter>
            <intent-filter android:label="max">
                <action android:name="android.intent.action.VIEW"/>
                <category android:name="android.intent.category.DEFAULT"/>
                <category android:name="android.intent.category.BROWSABLE"/>
                <data android:scheme="@string/app_scheme"/>
                <data android:host="@string/app_host"/>
            </intent-filter>
            <meta-data
                android:name="android.app.shortcuts"
                android:resource="@xml/shortcuts"/>
        </activity>

Не буду разбирать построчно, просто соберу в итог. «Андроид, закрепи за мной ссылку http[s]://max.ru/*. Если кто-то попытается эту ссылку открыть, то я её обработаю вот этим экраном».

Разумеется, в Google не совсем дураки сидят и просто так закрепить за собой ссылку ты не можешь. Ты должен по указанному адресу положить специальный файл (https://max.ru/.well-known/assetlinks.json; желающие могут убедиться, что он там лежит и даже увидят уши дев сборки), который позволит удостоверить, что ты действительно имеешь право на перехват этих ссылок.

Например, если вы установите альтернативный YouTube клиент, вам вручную нужно будет назначать ссылки для перехвата. Они объявлены в Манифесте, но Андроид их не включит, вы должны сделать это руками.

В общем, в этом примере Андроид передаст Максу ссылки только на его собственный сайт.

Резюмируя: нормальное поведение для множества приложений.

[Опасный компонент] CallNotifierFixActivity с возможностью показа на экране блокировки

Кажется, уже по названию можно догадаться, что это такое. Вот код:

        <activity
            android:theme="@style/CallNotifierFixActivityTheme"
            android:name="one.me.android.calls.CallNotifierFixActivity"
            android:showOnLockScreen="true"
            android:turnScreenOn="true"/>

Использовалось когда-то для показа уведомления о звонке. Код немного изменят, т.к. showOnLockScreen объявлен устаревшим ещё в API 23. Напомню, что Макс не установится на API ниже 29.

Резюмируя: скорее всего устаревший костыль.

com.google.android.gms.permission.AD_ID – доступ к рекламному ID

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

Резюмируя: иногда что-то может быть не тем, чем кажется

Отключено резервное копирование (allowBackup="false")

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

Тут прям всё не так.

1. Очень многие приложения, практически все, где есть учётные записи, запрещают резервное копирование
2. Разработчики несколько отстали от современности. Они выключили резервное копирование в облако (читай – в Google Drive). Но на переезд с одного устройства на другое эта настройка не влияет для всех современных устройств. То есть если вы возьмёте Pixel 8 и переедете по кабелю на Pixel 9, то приложение переедет. Вполне возможно переедет поломанным и нужно будет вручную чистить ему данные
3. Вредоносные приложения отключают, потому что зачем оно им. На их анализ это вообще никак не влияет

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

Включен нативный код (extractNativeLibs="false")

Указывает системе не распаковывать нативные библиотеки (.so файлы) из APK. Это может использоваться для затруднения статического анализа кода антивирусами и исследователями, так как часть логики спрятана в скомпилированных бинарниках.

Палю крутой способ достать .so файлы — архиватор, работающий с zip архивами.

На самом деле это рекомендуемое поведение. Оно говорит Андроиду, чтобы тот не извлекал нативные библиотеки, а просто читал из прямо из apk файла. Кроме того, этот флаг используется системой сборки gradle. Он говорит гредлу, чтобы тот не сжимал нативные либы, т.к. при сжатии прямого чтения из apk не получится. В итоге имеем бОльший размер apk, но бОльшую скорость чтения натива во время работы.

Резюмируя: обычное поведение.

DOWNLOAD_WITHOUT_NOTIFICATION – скрытые загрузки

На самом деле никогда не работало так, как вы того ожидаете. Даже в древние времена. А сегодня он вообще не работает. Как результат — в текущей версии Макса этого разрешения нет.

Резюмируя: не рабочий хвост старого приложения. Уже удалён.

FOREGROUND_SERVICE_DATA_SYNC – фоновая синхронизация данных

Позволяет запустить foreground-сервис для “синхронизации данных”. Это механизм для длительной фоновой работы под видом полезной деятельности, чтобы постоянно собирать данные

Вон чё. Вообще это разрешение, которые разработчики ОБЯЗАНЫ объявить, если используют сервис переднего плана с типом dataSync. Таких сервисов у них два: one.me.android.media.service.OneMeDownloadService, отвечающий за загрузку и androidx.work.impl.foreground.SystemForegroundService, который вообще не их, а пришедший к ним из гугловой библиотеки WorkManager, которую используют вообще все, кто использует фоновые задачи.

Резюмируя: вполне обычная ситуация

Автозапуск: Receiver для автозапуска при включении устройства

Пусть вас не смущает, что вы уже видели это выше. Выше было разрешение на получение этого бродкаста, а тут уже сам получатель (ресивер). И автор переживает, что у него три типа:

BootCompletedReceiver с тремя разными действиями (BOOTCOMPLETED, QUICKBOOTPOWERON) — это гарантирует, что запуск выполниться автоматически при любой возможности сразу после включения телефона, даже до его разблокировки.

Но на самом деле всё просто. Работает реально только первый тип. Второй давно никто не может получить (можно сказать, что его не существует), а третий так вообще только БЫЛ когда-то у HTC. То есть второй и третий — это хвосты ТамТама.

Вот, кстати, код целиком:

        <receiver
            android:name="ru.ok.tamtam.android.services.BootCompletedReceiver"
            android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.BOOT_COMPLETED"/>
                <action android:name="android.intent.action.QUICKBOOT_POWERON"/>
                <action android:name="com.htc.intent.action.QUICKBOOT_POWERON"/>
            </intent-filter>
        </receiver>

Предлагаю VK пересмотреть android:exported="true". Экшен android.intent.action.BOOT_COMPLETED кроме системы никто послать не может, а два других уже давно сдохли. Думаю, имеет смысл выставить в false этот параметр.

Резюмируя: частично устаревший код. Будет исправлен в будущем.

Заключение исследователя

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

Не выявил

Однако нашлось и множество «спорных» возможностей, которые выходят далеко за рамки обычных возможностей мессенджера

Не нашлось

Автозапуск при загрузке, скрытые загрузки, отключение резервного копирования и сложность анализа кода (extractNativeLibs=“false”) — это приемы, которые чаще ассоциируются с вредоносным ПО, стремящимся закрепиться в системе и скрыть свою деятельность.

Нет

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

Перед нами типичный современный мессенджер с очень плохим GUI, не соответствующим Android.

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

Опустим пафос в начале и остановимся на “наблюдать через камеру”. Важно понимать, что камера и микрофон НЕДОСТУПНЫ приложениям в фоне. Скрыто их запускать нельзя. Вы обязаны хотя бы держать сервис переднего плана, который обязан создавать уведомление. А ещё Android нарисует индикатор использования камеры или микрофона.

Мои предложения разработчикам MAX

• видно, что вы чистите устаревший код. Но я считаю, что именно на чистку стоит забить болт. Не, если чистка происходит на халяву по человеко-часам, то да, можно. Но специально выделять на это ресурсы не нужно, важнее усилить безопасность продукта
• запретите обработку исполняемых файлов. Не нужно создавать интент для apk и запускать его. Если это файл опасного типа для данной платформы, то пусть файл будет только сохраняться. При этом предупреждение оставить нужно, за него спасибо. Я считаю это критически важным только потому что мы имеем дело с национальным средством связи. Оно должно быть заточено на безопасность пользователей в первую очередь. Даже в ущерб некоторым привычкам. Особенно если эти привычки вредные
• ваш безопасный режим должен быть включен по умолчанию. Причина всё та же — вы не рядовой мессенджер и к вам другие требования
• вам нужно расширить партнёрство с ЛК. Сейчас вы уже используете WhoCalls. Договоритесь использовать ещё и их сервис репутации. Разумеется, проверки делайте только через запрос хеша, у них есть такой режим. Все http[s]://* тоже нужно проверять через этот сервис. Можете не переживать за то, что параметры ссылки передаются — у ЛК ссылки очищаются от параметров. Я сам это тестировал когда-то :) Кстати, у ЛК ещё и антиспам есть, если вы понимаете к чему я

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

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

1. Система вообще не нужна, так как есть TG и WA
2. Не решена основная проблема, о которой говорили: мошенничество
3. Государство запретит всё, кроме национального средства общения и будет следить за всем, происходящим в национальном средстве общения
4. Мылору не может сделать ничего нормально. Всё, чего оно касается, становится чем-то мерзким

Если я что-то пропустил, то добавьте в комментариях в вашем блоге в федивёрсе, упомянув меня (@umnik@x.myachin.xyz), или в комментариях в ТГ канале.

Система вообще не нужна, так как есть TG и WA

Это удобные средства общения и глупо с этим спорить. Когда-то VK заменил людям весь Интернет, потому что в нём было всё. Сейчас для подобных людей TG заменил весь Интернет. Есть каналы под любые запросы, есть чаты, есть звонки и видосы. Даже файловое хранилище есть.

WA тоже неплох. Чат с одноклассниками у меня именно в WA и многих из них в TG просто нет. Ну не нравится он им, неудобный, непонятный. Вообще, как я заметил, есть много людей, которых TG раздражает как раз тем, что в нём есть всё и сразу, а это не нужно. Много всего — это непонятно.

В отличие от TG, WA реализует оконечное шифрование при общении. Другими словами, ваша переписка недоступна Meta. В то время как в TG всю переписку целиком можно продавать любому, кто заплатит нужное количество денег. А чтобы люди точно держали вообще всё, что возможно, в том виде, которое удобно для обработки и продажи, мы засунем секретные чаты в такую жопу и сделаем их такими неудобными, чтобы ими не пользовались.

То есть WA, в целом, выбор и неплохой. Ровно до тех пор, пока они на самом деле реализуют всё то, что заявили. Однако, по какой-то непонятной причине:

• нет исходного кода клиента
• приложение обфусцировано не стандартным обфускатором, который есть у всех, а чем-то более хардкорным
• то и дело именно через него «заходят» в телефоны жертв службы «цивилизованных» стран
• только это приложение (из популярных) использовало уязвимость CVE-2022-20551, обнаруженное нашей командой. По интересному совпадению, Google не исправлял проблему несколько месяцев, а потом резко поднял ей приоритет и срочно поправил
  • обещанных денег нам так и не заплатили. Оплату они провели через SAP, который, разумеется, с Россией не работает. А все последующие мои попытки связаться с Google автоматически закрывались с комментарием «вопрос закрыт»
• Meta никогда не славилась хоть каким-то переживанием о пользователях. Цукенберг настолько привык, что к ним в офис приходят ФБР и другие, что спокойно рассказал об этом на подкасте (не помню чьём), когда речь зашла о ноутбуке Хантера Байдена. Нет никаких «по решению суда» или прочей чепухи из кино. Просто ФБР пришли в кабинет к нужным людям (даже не к самому Цукеру) и сказали, что и как надо делать
  • И Цукер рассказал это только потому что был период, когда было модно показывать дружбу с Трампом и рассказывать, как плохо вёл себя режим Байдена. Когда ветер поменяет направление, этот нос развернётся и расскажет нам о режиме Трампа

Да, всё это «косвенные улики», так сказать. Это не говорит о том, что в WA сидят товарищи капралы, которые сделают всё, что нужно для того, чтобы только правильным странам было комфортно, а неправильные жили под строгим контролем Пяти глаз (ибо, конечно, неразумные). Всё это случайные совпадения.

Да только даже если мы примем, что всё это просто совпадения, что это вовсе неправда, что Meta живёт исключительно в рамках закона лучшей в мире страны. Она всё равно подчиняется США и просто обязана делать всё, что скажут специальные люди со специальными должностями. Уж с этим, думаю, спорить никто не будет.

Про то, как некого Павла тоталитарное государство просто взяло в плен (вроде так принято писать в «независимых СМИ», когда говорят о «неправильных странах»?) и указало ему, как надо жить, доверять TG тоже опасненько.

Это приводит нас к тому, что средство коммуникации будет полностью зависеть от тех, кто уже несколько лет мешает жить лично нам.

Давайте возьмём в пример SWIFT. Это частная организация, не государственная. При чём она даже не из США, а из Европы (кажется, Бельгия). Однако:

• частной компании указывается, с кем работать, а с кем – нет
• ЦРУ, ФБР имеют прямой доступ ко всем финансовым операциям, проходящим в SWIFT. Весь мир находится под пяткой этих организаций уже более 20 лет (это публично известных 20 лет, а сколько было на самом деле?)
• США напрямую управляют деньгами внутри SWIFT. Что интересно, не смотря на утверждение SWIFT, что операции ЕС не отправляются США, те всё равно заблокировали внутреннюю операцию между странами ЕС и просто забрали себе все деньги. А чего бы и не забрать?

Следовательно, нам нужна независимая система. И она есть внутри страны. Потому карточки продолжили работать, а банки продолжили проводить операции внутри страны. Банковский сектор не рухнул, как того ожидали. Но вот выезд за рубеж нам пытаются ограничить. Всем нам, всем и каждому. И есть система МИР, которая пытается сделать нашу жизнь проще. За что её те же США пытаются блокировать, угрожая санкциями всем странам, куда она пытается войти.

Вообще, НСПК (национальная система платёжных карт) — это отличный пример, для чего нужны национальные сервисы. Они как раз и нужны для независимости, для устойчивости, для нашей нормальной жизни. Если кто не знает, что такое НСПК, то вот описание с официального сайта:

НСПК обеспечивает обработку операций по картам «Мир» и картам международных платежных систем, развитие продуктов и сервисов ПС «Мир», совместно с Банком России развивает Систему быстрых платежей, а также обеспечивает удобные и безопасные платежи по универсальному QR-коду и с помощью биоэквайринга

Мы так привыкли к СБП, нам настолько обыденно то, что всё просто работает, что многие из нас даже не придают этому значения. А ведь аналогов НСПК в мире не так, чтобы много. Буквально в десятке стран вообще есть хоть какие-то аналоги, а полных, которые бы обеспечивали весь набор возможностей НСПК, практически нет. Кажется, только RuPay (Индия) полностью соответствует всем возможностям НСПК. Потому что тот же UnionPay (Китай) не имеет аналога СБП. Но проверьте за мной, возможно мои данные устарели.

Исходя из этого примера (повторю, взят только SWIFT, потому что у США были большие надежды на него — не зря они грозили этим несколько месяцев, но не применяли), я надеюсь, каждый согласен, что любое государство, если желает остаться независимым и продолжать функционировать без каких-то заметных сбоев, обязано обеспечить себе независимость во всех важных сферах. И системы быстрой доставки информации к ним тоже относятся.

Нам, как и абсолютно любой другой независимой стране, нужны свои DNS серверы, устойчивость к вдвиганию кривых маршрутов (если кто забыл, как Google положил Японию), свои центры сертификации и всё-всё-всё, вплоть до роутеров (железо) и браузеров (ПО). Всё это должно быть своё, на сколько это вообще возможно; как в смысле физического расположения, так и в смысле способности производства.

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

Балансируя между доступностью и независимостью, всё же приходится часто делать выбор в пользу своего, но более дорогого. Собственно, лично я и лично для себя не считаю проблемой платить больше за то, что произведено в России, если это что-то имеет высокое качество и закрывает мои потребности. Я вчера купил розеток и выключателей на 60 тыс рублей, но российских (каждая от двух до ПЯТИ!!! раз дороже китайских).

Это понимают и в США, из-за чего прикладывают усилия для переноса производства всего, что возможно, внутрь страны. Пусть это стоит дороже в итоге, но даёт независимость, а это выигрыш в долгосроке.

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

Средства связи являются столь же критическими системами, сколь ими являются производство обуви. Это такое, о чём особенно не задумываются, потому что они просто есть и всё и вообще их полно. Но вот закрой рынки и окажется невероятное — кто-то жить не может без Найков и посрать не сможет без мемов в ленте.

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

В общем, с этим я почти закончил. Дополнительно напомню, что всё это до сих пор не понимают даже многие чиновники и огромная масса исполнителей. Государство (ранее я указывал, что под «государство» понимаются абсолютно все, хоть как-то связанные с госухой люди, организации или действия) слишком разношёрстное и в нём полно и тех, кто понимает проблему, и тех, кто не понимает и даже тех, кто просто дурачок или вообще саботажник. Давайте вспомним, как МВД использовали WA для обсуждение перемещения президента лично и других, помельче. И это в то самое время, когда США считают вообще нормальным просто прослушивать Меркель и других своих «партнёров». Как там говорил Киссенджер? «Быть врагом США опасно, а другом — смертельно», — так кажется?

Не решена основная проблема, о которой говорили: мошенничество

Одно из важных отличий национального средства коммуникаций от прочих — он точно будет подчиняться законам России. Как подчиняется WA законам США или TG законам Франции (сразу после того как специальные службы через специальную шлюху привели Пашку в обезьянник) и законам каких-то арабских шейхов, которые Пашку танцуют. Это значит, что вход, переписку, звонки — всё можно обрабатывать. Жесть про «утром в Максе = вечером в тюрьме» оставлю на потом, т. к. тут тема другая.

Уже давно мошенники сначала из тюрем, а позже из Украины разводили наших граждан по телефону. Сейчас этот подход почти угас. Нет, он ещё имеется, но вообще не тех объёмов, что раньше. Потому что звонки и SMS государство может контролировать. Оно может надавать операторам связи по жопе и обязать отсекать мошенников. Параллельно начали регулировать канал, который особо раньше не трогали — SIP. Сегодня вам скорее позвонит банк с офигенными тарифами по кредиту, которые больше похоже на микрозайм, чем мошенник.

Потому что:

• SIP попал под новые правила. Вы можете прочитать сообщения дурачков в Интернете о его блокировании, но на то они и дурачки в Интернете. Блокировки нет. Просто теперь вы, как оператор, предоставляющий услугу, обязаны оторвать жопу от стула. А как пользователь — просто продолжаете работать, вас это не касается
• SIM карты начали, наконец, действительно проверять. Раньше они были по паспорту лишь на бумаге, но была куча вариантов приобрести их и без паспорта. Сейчас эти лазейки закрывают. Параллельно блокируют те SIM, владение которыми не доказано. К середине августа 2025 года было заблокировано 15 миллионов симок. А ещё теперь вы видите свои SIM в Госуслугах. Даже если это корпоративные SIM
• При перевыпуске SIM банки обязали блокировать операции на некоторое время (давно) и сообщать в приложении об этом
• Банки обязали проверять операции снятия в банкоматах на признаки, которые можно трактовать как действия, совершённые под воздействием мошенников: https://cbr.ru/Crosscut/LawActs/File/10070 И человек может вернуть деньги, если банк проявил халатность
• Банки также обязали (ещё в прошлом году) возвращать деньги, похищенные мошенниками, если перевод попал под указанные ЦБ условия
• тонна других изменений:
  • пометки звонков для бизнеса и ИП. Юрлица и ИП будут помечаться самими операторами связи и будут написаны на экране на любом современном телефоне вне зависимости от приложения звонка и производителя устройства
  • пометки звонков с иностранных номеров
  • запреты передачи SIM (но родственникам – можно) и учётных записей
  • ограничения на количество SIM карт — не более 20 активных. Этого гарантировано хватает нормальному человеку и мало для спамеров и мошенников, ведь как только в МВД придёт заявка о мошенничестве, они помечают этот номер, как возможно мошеннический и теперь любые операции на нём блокируются, а переводы на него невозможны (см. ниже статистику)
  • добавление доверенных лиц для совершения банковских операций. Если вы переживаете, что кто-то из ваших родственников, или даже вы сами, можете попасть на уловки мошенников, можно добавить доверенные лица, с которыми банк будет связываться для подтверждения некоторых операций
  • запрет на массовые рассылки и звонки, кроме явного согласия. И его можно будет отзывать через ГУ
  • самозапрет на регистрацию SIM, чтобы на вас не смогли сделать дубликаты (снять можно в МФЦ)
  • запрет на доставку SMS от ГУ во время звонка. То есть бесполезно говорить «вам сейчас придёт SMS, продиктуйте код», потому что оно не придёт
  • запрет на активацию телефонов с IMEI из списка запрещённых. Давно есть во многих странах мира и, наконец, появляется у нас
  • ограничения на количество банковских карт, что важно для мошенников, которые пытаются раскидывать переводы по разным счетам
  • увеличение сроков государственной регистрации недвижимости, если есть признаки мошенничества. Вспоминаем две недавних истории с мошенническими сделками по недвиге и миллион историй «той» России с её «чёрными риэлторами»
  • в разработке информационная система «Антифрод», которая создаётся специально для борьбы с мошенничеством

К слову, НСПК также предоставила бесплатный сервис похожей направленности: https://www.nspk.ru/press-center/details/a1c615f2-0bfb-449a-b47d-547497f05e78

По какой-то причине мы не находим новостей, что тысячи операций мошенников были отклонены. Возможно потому что владельцам СМИ не интересно сообщать о том, что что-то работает хорошо и правильно, зато интересно написать о единичных провалах. Чтобы вы понимали, по статистике Службы по защите прав потребителей и обеспечению доступности финансовых услуг Банка России, банки сейчас блокируют 99% новых мошеннических операций и 100% тех, которые уже засветились ранее и попали в базу МВД.

Другими словами, с мошенниками борьба идёт очень серьёзная и не первый год.

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

Также национальный мессенджер обязан будет связываться с ГУ. Вообще это будет правильной практикой — либо не давать заходить без проверки по ГУ, либо как-то помечать значком недоверия тех, кто отказался от проверки по ГУ. Первый вариант лично меня бы полностью устроил, т. к. ДЛЯ СЕБЯ я не вижу причин общаться в национальном мессенджере с иностранцами. Но другим может быть удобен второй вариант. Как бы то ни было, связь быть обязана. Национальный мессенджер обязан проверять учётные записи, потому что без этого не удастся быстро и просто вычислять мошенников или хотя бы идиотов-мулов.

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

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

Желающие могут ознакомиться с видео, как люди смогли разоблачить мошенников в Индии и как на это всем наплевать: https://www.youtube.com/watch?v=xsLJZyih3Ac Хотя страдает от индийцев вторая по святости нация.

Государство запретит всё, кроме национального средства общения

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

Государство говорит, что вот эти помидоры вдруг, со вчера, обзавелись спидораковой палочкой и запрещает их — народ принимает, хоть и всё понимает. Государство говорит, что в этой детской больнице может быть (а может не быть) один плохой человек и бьёт туда ракетой, прям по детям — народ принимает (понимает? поддерживает?). Если кому-то что-то не нравится — есть выборы. А до выборов и помидоры будут то плохие, то хорошие, и «сопутствующие потери» будут нормальной платой.

Запретит ли государство другие средства общения? Да фиг знает. Даже если бы я сам работал «в государстве», я бы всё равно не знал ответа. Потому что это множество людей с кучей мнений. Буду ли я страдать от запрета? Нет, я — не буду. Хочется ли мне, чтобы запретили? Конечно не хочется. Но, думаю, до окончания СВО, а ещё какое-то время после, послаблений не будет.

И здесь же:

[Государство] будет следить за всем, происходящим в национальном средстве общения

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

Это знаете дурачков, которые в ChatGPT всякую уголовную фигню спрашивали, а теперь узнали, что это будет учтено в суде, если что? Так и тут. Старайтесь не быть идиотом, это может помочь жить.

Национальные/государственные инструменты работы используйте по прямому назначению и будет хорошо. Переводить по СБП деньги террористам нельзя, например. Следует это учитывать.

Мылору не может сделать ничего нормально

И вот тут я остановлюсь, потому что это уже третья часть. Я хочу вынести отдельно, потому что это единственный пункт, который связан не с абстрактным инструментом «национальный мессенджер», а с вполне конкретной реализацией «MAX»

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

А, да. Если вы придерживаетесь позиции «если в России — то это только чтобы посадить и убить», то сразу идите лесом. Это не конструктивно и это буду игнорировать. А ещё буду в голове проговаривать, какой вы дурачок.

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

Т.к., оказывается, люди читают не то, что написано:

Национальный мессенджер – отличная вещь. Та, которая должна была быть очень давно. Нам нужен свой вичат. …а что-то в своём воображении, то здесь я раскрою то, что хотел сказать. Заодно напишу конкретно о Максе (хотя про него не говорил ни слова) и отвечу на уже вброшенные претензии, благо это всё одни и те же по кругу.

Начну со своих изначальных утверждений:

Национальный мессенджер – отличная вещь

Почему это так? У нас уже есть «Госуслуги», при чём сбоку к ним прицепились подвиды типа «Госуслуги Авто», «Госключ», «Госуслуги Дом» и другие. У нас появились всякие МФЦ, появилась возможность даже не подавать показания приборов учёта электроэнергии, к примеру, потому что это происходит автоматически.

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

Но даже когда что-то работает хорошо, упираемся в первую проблему: доставить сообщение. Давайте отсюда и далее я объеденю всё-всё-всё, что связано исполнительной, судебной, законодательной, управляющей системами и вообще всё, что существует подобное под одним словом «государство». Здесь будет и сотрудник, первый день работающий в службе единого окна, и полиция, и Верховный суд.

Проблема уведомлений

Чтобы сообщить человеку о каком угодно событии, у государства есть два способа. Можно было бы сказать, что три, но на самом деле два из них — половинчатые и в сумме дают один. В общем:

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

Давайте разберём каждый из них.

Телефон, SMS

Проще всего с телефоном. По телефону просто нельзя отличить, звонит тебе мошенник или действительно вас беспокоят из «Главного управления МВД России», ага. Ты, читатель этой записи, разумеется, за километр чувствуешь запах мошенничества и, конечно, никогда не попадёшься на эту удочку. Но лично ты, читатель, точно также будешь блокировать и настоящие звонки по той же замой причине. И лишь если тебе не лень, потратишь время и разберёшься, настоящий это звонок или нет. В общем, телефон — самый худший способ связи из существующих.

Электронная почта

На первый взгляд тут дела получше. Прилитает письмо с Госуслуг (ведь ты, читатель, подключил «Госпочту», разумеется) и всё норм. Но давайте посмотрим на людей уже вокруг себя — на своих родителей, на своих друзей и в особенности на тех, кто уже на пенсии.

• Отличат ли эти люди фишинг от настоящего письма? Я даже не буду говорить о ситуации, где в поле from стоит настоящий адрес Госуслуг, пусть там даже написано gosuslugi-tehpodderzka@mail.ru — все эти люди точно справятся?
• Пользуются ли все эти люди электронной почтой? Скажем, моя мать — бухгалтер и с электронной почтой она хорошо знакома и активно её использует. Но вот мой отец, хоть и имеет ящик, просто потому что когда-то регистрировал учётную запись Google, вообще даже не знает ни адреса, ни тем более пароля от неё. Другими словами, электронная почта как бы есть у миллионов граждан, но по факту её у них нет.

Физическая почта

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

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

• Физические письма тоже могут быть поддельными. Я пока не слышал, чтобы подделывали судебные, скажем (но не исключаю, что это могло быть), а вот квитации об оплате коммунальных услуг подделывали только в путь. Люди думали, что оплачиают коммунальные платежи через QR, а на самом деле переводили деньги мошенникам.
• Письма могут идти очень долго. Это объективная проблема, связанная с нехваткой кадров у Почты России
• Многие люди имеют регистрацию по одному адресу, а проживают по другому. Так как глобально это не мешает, то многие и не меняют регистрацию. Или не меняют осознано по каким-то своим причинам

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

Единое решение

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

Единое решение будет получать все сообщения ото всех госучреждений прямо на устройство пользователя. И в целом такое решение есть — Госуслуги. Поставишь его и получаешь уведомления — красота. Для меня это видится пока лучшим вариантом. Ну а кто не желает – пусть получает уведомления по физической почте — их право. Пусть только помнят, что вручение для некоторых писем будет не по фактическому вручению, а по дате, проставленном в отделении. Ну, не донёс почтальон письмо за две недели — ну что поделать. Ты за его зарплату поноси.

Теперь давайте развивать существующее решение, потому что нет предела совершенству.

• нужно связаться с УК своего дома, чтобы выяснить, почему начислили что-то не то. Ситуация не абстрактная, мне уже несколько раз это приходилось делать. В этом случае придётся переходить куда-то на внешнюю площадку, т.к. Госуслуги — это не социальная сеть. Поддерживать её как социальную сеть будет ну очень сложно и дорого
• нужно связаться с соседями просто-напросто. И тут стреляет неожиданное — админ группы дома тебя блокирует, за то, что ты состоишь ещё и в группе подъезда! И я снова не придумываю. Практически весь наш подъезд забанен в общей группе дома. А если бы использовалось общее решение, навязанное сверху, дурости бы не было, ведь общая группа в едином решении принадлежала бы не обиженному жителю
• а летят на голову птицы железные с бомбами внутри если? Нужно ещё приложение, выходит. Да ещё как-то обязать установить, а это время
• хочу новости почитать, но так, чтобы это была с одной стороны не Труха Украина, а с другой — не Соловьёв. Ну вот конкретно они мне не нравятся. А нравится мне Стас Ай Как Антонов. Ещё приложение нужно, значит. А того, что нашёл — это настоящий или нет? [Имена специально подобраны, чтобы кого-нибудь раздражать при чтении]
• нашёл нужного, а его завтра нет. Почему? Да он чёт нехорошо высказался про пидоров. И мнение высказал своё, а нарушило правила какой-то другой страны. Вроде я с той страной и не связан, но она снесла мне источник
• встретился с другом, с которым со времён школы не виделся. Давай связь держать. Давай! Я в А сижу, в Б никого нет. А я в Б сижу, в А никого нет. А будь единое решение для страны, то оно практически гарантировано было бы у каждого
• коммуникация со всеми производителями продуктов и услуг. При существовании единого решения вполне себе можно обязать условные Азбуки Вкуса и Пятёрочки иметь представительство в этом едином решении, куда можно сообщить что-то или пожаловаться. То есть ты видишь магазин или парикмахерскую — ты знаешь, что они есть в этом едином решении. Зашёл просто к ним, а тебе сразу вот часы работы, вот сюда жалобы и предложения, здесь посмотреть ассортимент
• общественные приёмные государственных работников. При существовании единого решения вполне можно обязать чиновников и отчитываться о проделанной работе, и вести приём заявок

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

Но почему таким центром не могут быть Госуслуги? К сожалению, все описанные сценарии — это социальные сети. А их и делать не так, чтобы прям просто (Google не смог, MySpace умер, Fb — это аналог Одноклассников в плохом смысле, Твиттер не понятно, смог ли вылезти из долгов, остальные даже не стараются). Но при этом сама концепция социальных сетей уже несколько устарела. Сейчас это перползает в мессенджеры.

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

Почему не Телега?!

Телега — неплохое решение. В нём есть почти всё, кроме самого главного — он не подконтролен государству. И не в том плане, что наши переписки так хотят читать (хотя это тоже), а в том, что Россия довольно мягко себя ведёт с теми, кто наплевательски к ней относится. Из-за этого в Телеге есть просто тонны того, чего ни в коем случе не должно быть в приложении, которое должно быть у всех, от школьников до пенсионеров. Как нужно себя вести показывает ЕС, показывает Франция. Нужно взять за жопу, воткнуть руку поглубже в анус и пусть теперь делает то, что сказано.

То есть Телега плоха тем, что бесконтрольна. Если у вас возле дома ещё не успели замазать рекламу наркомагазинов (тоже неплохо бы иметь группу для быстрого сообщения об этом в едином средстве коммуникации, а?), то там вовсе не Briar и даже не Matrix, хотя для этих целей они были бы лучше, не находите? Конечно, на это можно жаловаться. И я жалуюсь. Каналы блокируются и открываются дубликаты тут же. Телеграму настолько пофиг, что работает даже простое добавление 2, 3, ... к названию. Не потому что Телеграм плохой и лично Пашка с Колей такие негодяи. Просто им наплевать, вот и всё. Их это не беспокоит. Звёздочки с подарками продаются, реклама покупается — значит всё хорошо. Единственная цель существования Телеграма — это заработать деньги инвесторам. Просто будьте честны сами с собой. Ведь заработать, предоставляя вполне хороший сервис — это не зло. Просто вот это всё в совокупности не может быть тем, что серьёзно используется государством.

Продолжение следует

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

Вводные термины

• релиз кандидат, release candidate: сборка, смотрящая на прод серверы, без логов, с обфускацией, в финальном состоянии. В общем случае подразумевается, что в ней не будет никаких новых проблем выше 4-го уровня. Эта же сборка потом раздаётся пользователям

• код фриз, code freeze: этап, на котором в продукт и его компоненты не вносится никаких изменений. Каждая найденная проблема обсуждается, можно ли её отложить до следующего релиза или до хот-фикса. Проблемы от 4 уровня и ниже всегда переносятся на потом и пересборки из-за них быть не может. Даже если это совсем точечное изменение, даже если это кажется ерундой

• хот фикс, hot fix: сборка с устранением проблем, накопленных ранее, но сумма которых не тянет на новую полноценную версию продукта. Хот-фиксы гарантировано имеют малый потенциальный урон (impact) и дёшевы в разработке и тестировании.

Если урон большой — это уже не хот-фикс, а полноценный релиз с соответствующим выделением ресурсов и закладкой сроков. Отсюда следует, что нельзя даже простые задачи включать в HF просто потому что можем. Меньше задач – острее внимание

• критикал фикс, critical fix: сборка с устранением одной конкретной проблемы, о которой на момент выпуска релиза не было известно. Это может быть и пропуск проблемы со стороны QA, и просто новые обстоятельства, например вынужденные переезд на другие серверы.

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

• мейтененс релиз, maintenance release: релиз продукта с устранением самых разных проблем, но без добавления новых фич. Планируется как полноценный релиз. Если HF жирнеет, то он превращается в MR.

MR ничем не отличается по работам от обычного релиза. Разница только в том, что в MR нет новых фич. Либо что-то есть, но это что-то было сделано только ради исправления проблем

UI/UX: отвечают за взаимодействие пользователя с продуктом. UI – это есть ли кнопка на экране, на которую можно нажать, а UX – это очевидно ли пользователю, что на кнопку можно нажать и удобно ли ему это сделать

Термины, связанные с тестированием, будут дальше.

Задачи тестировщика

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

Следовательно, тестировщик должен сообщать (читай – «записывать в багтрекер») обо всех, даже незначительных проблемах. Разумеется, это породит ворох задач, которые никогда не будут исправлены. Но знать о них всё равно нужно. Простое удерживание в голове знания о какой-нибудь мелочи заставляет ответственного разработчика учитывать её, когда он работает над областью, в которую эта проблема попадёт. Ответственный разработчик воспользуется возможностью устранить мелочь. Eсли это не создаёт новых проблем.

Замечание: описанное выше роляет лишь при условии, что не используется Zero bug policy. Т.к. мы решили, что нам он не подходит, то альтернативное мнение и не описываю.

Тестировщик может и должен полагаться на выработанные привычки взаимодействия с ПО и сообщать, что где-то UX сломан для текущей платформы или где-то UI «некрасивый», не смотря на субъективность. Но тестировщик должен показывать примерами, что такое хорошо. В идеале он должен давать ссылки на объяснения, почему так, а не иначе.

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

Чтобы не было недопониманий. Тестировщик отвечает за то, на сколько хорошо (внимательно, глубоко, разносторонне) он проверяет продукт.

Приоритизация

В общем случае тестировщик присваивает заведённым дефектам только важность (severity). Однако иногда важность не отражает имиджевое влияние, влияние на «очень важного заказчика» или наоборот, не играет роли в текущей ситуации и тогда менеджер меняет приоритет. По умолчанию считаем, priority = severity. На приоритет ориентируется разработчик при планировании рабочего дня.

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

В общем случае значение чисел такое: – 0-2 – критично или очень серьёзно. Блокирует релиз – 0 — редкое явление, означающее, что использовать сборку нельзя. И не важно, потому что она не запускается или потому что при её использовании ломается будущая совместимость. Это просто маркер, означающий «пока не сказали, что поправили, не ставьте промежуточные сборки» – 3 – продукт может пойти в релиз, если это не привнесённая проблема. Если привнесённая, то релиз блокируется до тех пор, пока менеджер не понизит приоритет, например до 4. Допустимо делать релиз с 3 для привнесённых, если следом уже планируется хот-фикс – 4 – релиз не блокируется, вне зависимости от того, привнесено это или нет. Однако, если привнесено, то в следующей итерации нужно либо поднять приоритет до 3, чтобы исправить (или снова отложить – так бывает, хотя и ставит под сомнение реальную важность), либо опустить до 5, чтобы забить болт – 5-7 – разные уровни малозначимых проблем. 5-ки ещё могут подняться вверх во время триажа, но 6 и 7 – это просто кладбище, куда складываем то, что знаем, но чему в нашей жизни решения, скорее всего, не будет

Расчёт важности

Чтобы рассчитать важность, нужно ввести ранжирование сценариев (юз кейсов)

«Абсурдный» не означает «бессмысленный». В основном это ситуации, которые просто не планировались, не обсуждались. Но то, что сегодня абсурдно, завтра может стать новой задачей. А может и не стать.

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

Да, серьёзность надписи Mikrosoft прямо на главном экране продукта – это 5: не функциональная область, обычное использование, не мешает пользователю вовсе. И тут менеджер уже должен менять приоритет. Тестировщик может попросить менеджера это сделать.

Виды тестирования

Глобально:

Полное регрессионное

Оно же «фул регрес»: продукт проверяется от и до без учёта того, что в нём менялось или не менялось. Включает как функциональное, так и не функциональное тестирование. Очень дорогое (в человекочасах), потому не может проводиться постоянно. Согласовываем фул регресс на 2-3 раза в год. Чаще нет смысла из-за во-первых дороговизны, во-вторых не накапливается достаточно изменений, которые бы могли задевать разные области.

У фула две задачи: – сформулировать текущее состояние продукта и создать этим отправную точку будущих проверок. Чтобы не было «да туда 100 лет не заглядывали, может оно уже 10 релизов как не работает» – обнаружить накопившиеся проблемы, которые не были обнаружены в промежуточные проверки

Регрессионное

Обычный “регресс”. Разработчик ставит что-то в InTest и, если считает нужным, добавляет в комментариях, что ещё нужно проверить дополнительно к тому, что описано в самой задаче изначально. Вне зависимости от того, оставил разработчик свою просьбу или нет, тестировщик проверяет исправление/реализацию как того, что прописано в задаче, так и «окружающей функциональной области». Короткий интест может занять часы проверок, если задевает несколько областей разом.

При регрессионном тестировании тестировщик также делает функциональные и часто, но не всегда, не функциональные тесты. Например, если правилось падение, то тратить время на вычитку текстов не нужно.

Все промежуточные (между фул регрессами) тесты – это обычные регрессы. Потенциально, из-за того что проблемы могут появиться в местах, о которых ни тестировщик, ни разработчик не подумали, приходится несколько раз в год делать фул. Или раз в пару лет, если дела идут прям хорошо.

Финальное

Не является общепринятым термином, но его всё равно часто используют. Под финальным подразумевается достаточно поверхностный регресс после код фриза. Поверхностный он потому что проверка доработки замечаний, выявленных при регрессионном делается тоже обычным регрессионным. То есть финальное лишь отвечает на вопрос, успело ли что-то отъехать глобально. Такое бывает в сложных системах, когда для сборки, пригодный для финального теста, потеряли какой-нибудь коммит, перепутав ветки или что-то в таком роде. Как избегать эту проблему – это головная боль разработчиков, тестирование этого не решает.

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

Для финального тестирования создаётся набор тест кейсов, который называют импакт планом и в таком роде. Само формирование набора – это часть импакт анализа.

ВАЖНО 1: в ситуации «потеряли коммит», когда финальное тестирование этого не обнаружило в виду низкого его погружения, QA не несёт за это ответственности. Потому что QA не отвечает за процессы других команд.

ВАЖНО 2: и хотя фиксы после финального могут быть и их могут включить в релиз, нужно искать причины, почему эти фиксы понадобились вообще и устранять причины. Они хоть и могут быть, но это очень плохая практика. Лучше планировать сразу HF или даже MR. Ситуацию, когда финальное не находит вообще ничего, считаем маловероятной

Импакт

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

Далее тестировщик проверяет эти сценарии. Это называется импакт тестирование или тестирование по импакту. Но все говорят просто импакт, подразумевая как раз это.

Приёмочное

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

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

В идеальном случае финальное тестирование не проводится. Сразу после перепроверки фиксов после фриза, выкатывается RC.

В общих чертах:

• Функциональное: как работает техническая штука. Запускается ли вообще приложение, работает ли звонок, ходят ли сообщения. Здесь не учитывается UI и UX, даже если всё совсем плохо. Функциональное нужно, чтобы убедиться, нужно ли копать вообще или пока копать рано. Либо, если фича существовала раньше, проверяется, не сломалась ли она

• Не функциональное: подразумеваем UI и UX в основном. Потому что околотехнические тесты лучше выделить в свои виды. Главное, что здесь имеется в виду — проверяется, что уже работающая фича удобна, очевидна, красива. Нет никакой нужды делать нефункциональное до реализации фичи. Даже когда речь о «там просто баг, сейчас поправлю» – всё равно не нужно проверять. Потому что часто вдруг оказывается, что просто так не поправить и нужны значительные доработки или даже переделки. А значит время, затраченное на сверку с макетами было потрачено зря

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

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

  • RLT. Например, арабские языки. Хотя тексты развернуть не проблема, часто стреляет то, что некоторые надписи являются картинками и про них тоже нужно помнить. Кроме того, нужно согласовывать, разворачивать ли интерфейс приложения (обычно нет)

    • вторая проблема RTL в том, что один участник может собою развернуть других. К примеру, его имя написано с управляющим символом RTL юникода. Если его имя попадает в абзац текста (или, например, в перечисление «А, Б, В печатают…»), может развернуть всех
    • стрелки «Далее» и «Назад» в мастере первоначальной настройки может развернуть, опять же

  • часто разработчики могут несколько раз вставить одно и тоже слово, скажем «Да», а потом найти, что оно уже есть и переиспользовать ранее существовавший ресурс. «Осиротевший» ресурс остаётся на месте и может получиться, что уточнили перевод сироты, а вот реально используемый потеряли

  • смежная ситуация: переиспользуется ресурс, который в одном языке означает одно и тоже, но в при переводе нужно разделить ресурс на более чем одно значение. Например удалённый: remote и deleted

  • переводы делаются, в основном, не видя реально приложения. Так что нужно проверять не только что фраза переведена, а что она переведена с учётом контекста

  • при расчёте сроков нужно держать в голове, что придётся все задетые ресурсы как-то вызывать. Это не просто «ну гляньте за полчаса». Некоторые ресурсы вообще нельзя будет вызвать со стороны тестирования без привлечения разработчиков и даже инфраструктуры

• Тестирование производительности: включает все виды проверок от просто «по ощущениям», до нагрузочных и стресс тестов. Расчёт потребляемого трафика тоже здесь. Не может быть обыденной проверкой, по типу функционального тестирования. Для перформанс тестов нужно заранее подготавливать окружение. А для этого нужно заранее понять, что хотим узнать. Для этого придётся проговаривать всё словами и, в итоге, сформулировать цели. Способы же проверки формулируются только после формулирования целей

По пониманию продукта:

• Чёрный ящик: когда ничего не понятно, и нужно разобраться, как это работает. Выпускаемый нами самими продукт НИКОГДА не может проверяться как чёрный ящик. Каждый тестировщик должен разобраться в каждой фиче продукта и понимать, как именно это должно работать и как оно работает на самом деле. Если тестировщик не желает разбираться, тестировщик не должен работать в команде

• Белый ящик: когда тестировщик понимает, что к чему. В пределе, но не обязательно — читает и понимает исходный код. В целом достаточно того, что тестировщик представляет механизмы работы ОС и продукта. Это помогает предполагать опасные/сложные места и начинать проверку с них. Как правило, в простых местах разработчик не ошибается, а опасные как раз может не учесть. Как итог – ошибки находятся сразу же

Задача лида – сделать продукт понятным тестировщику. Задача тестировщика – приложить усилия, чтобы разобраться в продукте и в его взаимодействии с ОС.

Задачи

Жизненный цикл задачи

Вне зависимости от типа задачи – задача, пожелание, баг – она проходит один и тот же жизненный цикл.

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

• принятие решения о реализации. Вполне может быть, что задачу нельзя, невозможно, нет смысла и т.п. реализовывать и ответственное лицо (в основном разработчик, если речь про баги) может отклонить задачу или запросить больше информации. Нужно написать, почему именно отклонено или какую информацию нужно добавить и выставить в InTest. Разработчик не может закрыть баг, даже если не согласен. Его инструмент – отклонение с объяснением

• реализация, если принято решение о реализации

• отправка на проверку. По умолчанию все проверки делает QA, вне зависимости от того, кто задачу создал. Так что разработчик ставит InTest и отправляет на тестировщика

• проверка. Тестировщик, если может, проверяет реализацию. Если автор не он, то он общается с автором (если возможно) и всё равно проверяет сам. Если задача была очень специфична и явно не для QA, то тестировщик вешает её на заказчика со своим комментарием, почему это сделано.

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

Просьбы

Нормальным и даже рекомендуемым поведением является оформление просьбы что-то проверить в виде задачи. Чаще всего просят тестировщика что-то сделать. На созвоне или в переписке о чём-то просишь и, если тестировщик говорит, что да, может это сделать, то завести ему соответствующую задачу и поставить в InTest.

Благодаря такой формализации тестировщик и вряд ли забудет о задаче, так ещё сформулирует ответ в ней же. А значит все смогут этот ответ прочесть. К тому же всегда можно будет вернуться к задаче и вспомнить детали.

Просьбы оформлять в виде задач в багтрекере – это хорошо и правильно.

Триаж

Задачи в баг трекере будут накапливаться. Некоторые будут решены, некоторые решены не будут. Раз-два в год, чаще нет смысла, нужно проводить триаж. То есть проверять, актуальны ли ещё задачи и нужно ли что-то поднять из подвала наружу.

Этап 1. Тестировщики проверяют все открытые задачи.

Те из них, которые более не актуальны, закрываются.

Те, которые актуальны, обновляются с указанием, на какой версии проверено.

Те, которые актуальны, но чуть изменилось воспроизведение (например с тех пор изменился экран или экран переехал и теперь надо иначе его вызывать), обновляются под новую реальность.

Если удалось найти ещё способы получить эту же проблему, кроме той, что записано, это также добавляется.

Если новое поведение проблемы таково, что её важность повышается, она добавляется в список проблем, на которые нужно обратить внимание.

Этап 2. Лиды и PM рассматривают сначала список проблем. на которые нужно обратить внимание, даже если тег Triaged установлен. Если окажется, что проблема действительно стала более важной, тег снимается. Задача рассматривается как новая. Имеется в виду, что, возможно, нужно будет ещё и приоритет переопределить

Далее просматривается список оставшихся в живых проблем без тега Triaged и принимаетя решение, что с ними делать.

Если проблема такая, что точно никогда ничего делать с этим не будем, на неё ставится тег Triaged. Таким образом тестировщики её будут актуализировать каждый год, но на второй этап она никогда не попадёт (если у неё не изменилось поведение и она не попала в список “обратите внимание”).

Если проблема такая, что её бы хорошо поправить, она добавляется в скоуп релиза. Релиз не обязательно ближайший. Это может быть отдельный релиз, MR, к примеру.

Философия

В этом разделе попытаюсь ответить на вопросы, которые возникают в головах и иногда проговариваются вслух.

Почему тестировщик находит проблемы в ранее проверенном

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

В самом простом случае тестировщик просто правда плохо работает. С такими нам не по пути. Но хороший тестировщик тоже допускает такие косяки. Основные причины:

• ранее устранённые проблемы освобождают время проверок. Скажем, из-за некой баги пришлось потратить 3 часа на её воспроизведение, на анализ. Эту проблему устранили и теперь как бы появилось «лишних» 3 часа в обычном рабочем дне, которые тестировщик непременно инвестирует сюда же – в проверки.

Может звучать не правдоподобно, но это действительно самая популярная причина. Собственно, почти все обнаруженные на поздних этапах проблемы – это «лишнее» время. В том числе потому HF и MR существуют и потому они планируются заранее, ещё до самого основного релиза.

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

• устранение ошибки приводит к раскрытию другой. Не редка ситуация, когда одна ошибка маскирует другую

• люди устают. Могло быть так, что в прошлый раз тестировщик был уставшим и с рассеянным вниманием. Отличие от тех, с кем нам не по пути в том, что хороший тестировщик может иногда уставать и каждый раз это прям новость. “Ничего себе, как так?!”

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

Личное замечание. Оно наверняка считается сексистским и каждый с ним вправе не согласиться. Девушки теряют интерес сильно позже, чем парни. Они лучше выполняют одни и те же работы и сильно дольше остаются внимательными к деталям. Что, разумеется, не означает, что им не нужно давать новое.

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

• слишком хорошее знание продукта. Когда тестировщик слишком хорошо изучит продукт, он начинает предсказывать его поведение. Это очень помогает в обнаружении проблем новых фич, но мешает в обнаружении проблем в достаточно привычных сценариях. «Ну да, падение, если поворачивать телефон во время удаления контактов, ну а чего вы ждали, особенности работы». Только пользователи ждали не понимания причин, а чтобы просто не падало

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

Почему не проверили вот это, это же было быстро

Каждую отдельную ситуацию проверить быстро. Но секунды создают минуты, затем часы и дни. Отдельных сценариев прям много, прям сотни. А когда релиз делается ради фичи X, то фичу Y будут проверять сильно реже и вообще потом. Если нужно вклиниться в список задач тестировщика, лучше всего просто попросить об этом. А когда просишь – нужно убедиться, что просьба услышана.

Повторюсь снова: не грех и напоминать о просьбе. У тестировщика тоже есть работа и жизнь и он может просто забыть об обещании. Напоминание его не оскорбит, зато поможет проекту

Ну и лучше всего прочитать раздел Просьбы и сделать так, как там написано

Не так давно в RuStore завезли Signal. И это (по крайней мере сейчас) оригинальное приложение. Я даже упоминал об этом на lor.sh, и люди посчитали, что это поддельное или пропатченное приложение. Но нет, обновление из RuStore без проблем установилось поверх существующего оригинального приложения, что означает, что это тоже оригинальное. Ну, либо VK смогли украсть закрытый ключ подписи, конечно. Всё было ничего до недавнего времени, пока не появилось обновление Signal, несовместимое с текущей версией. И я испугался, что VK пытается сейчас уже раздавать подделку, из-за чего и сел разбираться.

Вытянул приложение с личного телефона, с эмулятора и из RuStore и сравнил их. Приложение в RuStore имеет оригинальную подпись производителя:

Да что там говорить, это буквально один и тот же файл, который я добыл из GPlay:

Но что за файл? Почему люди подозревают, что что-то здесь не так, почему приложение не устанавливается и RuStore пишет сообщение о несовместимости?

Дело в том, что приложение в RuStore было загружено из стороннего магазина — из Aptoide. Что, кстати, немного забавно, ведь сам RuStore защищается от того, чтобы из него приложениях могли тянуть.

Так вот в Aptoide была загружена версия более старшая, чем у пользователей, но под архитектуру Intel:

Таких смартфонов сейчас уже не осталось, на сколько я знаю, а значит это версия скорее для эмуляторов. Кто-то вытянул с эмулятора Signal и загрузил в Aptoide. А RuStore спёр её к себе. Только ошибка VK заключается в том, что они не умеют разделять версии по архитектуре процессора (важно для нативного кода) и просто всегда отдают самую старшую.

Итог закономерен — RuStore предлагает версию с бОльшим version code, но под другую архитектуру процессора. И у пользователей она не устанавливается. Понятное дело, что в GPlay такого нет и тот отдаёт всегда правильную. Но мало того, свободный F-Droid тоже умеет понимать архитектуру и отдаёт правильную. А бедная инди компания VK не смогла это учесть. В общем, хочу успокоить пользователей — приложение не поддельное. Это просто VK вот так работает.

Пока писал эту статью, произошли изменения:

• Aptoide убрал Signal под x86_64

• RuStore, видимо, убрал вслед за ними. Либо, как вариант, мне прилетела более старшая версия из GPlay и только поэтому RuStore перестал предлагать обновиться

  Резюмируем. Signal в RuStore настоящий (пока?), но магазин пока не готов к реальности :)

Это привело к небольшому, но полезному спору. На одной стороне я, с фразой в более 90 символов, на другой стороне уважаемый (не ирония, не шутка) в своих кругах человек, считающий, что это бессмысленно. Кстати, рекомендую подписаться на канал этого человека, если вы связаны с ИБ, он правда хорош (нет, не реклама :); да и какая реклама, если у него почти 8k человек): https://t.me/infosecmemes Предполагаю, что оппонент отталкивается от, в общем-то, правильного утверждения, что 18+ символов — это великолепный пароль, который уже не перебрать за разумное время.

О парольных фразах

Однако у меня не пароль, а парольная фраза (пассфраза). В чём разница:

• все слова, составляющие фразу – словарные. И хотя руками я их почти не ввожу, но если придётся — не будет с этим проблем. Читаешь следующее слово, скажем синий и просто пишешь, не ломая пальцы, вводя всякие !"№;%:?*¡½^@#$¿⅛′˝ типичных паролей. Более того, читать можно много слов за раз: синий верблюд летит на запад. А ещё нет проблем использовать пассфразы в скриптах, т.к. не приходится переживать за экранирования
• для пассфраз запоминаемость не является плохим свойством! Вместе с ассоциативностью связи с целевым ресурсом, это позволит вспомнить пассфразу без привлечения менеджеров паролей. Скажем, есть у вас контейнер VeraCrypt. Создали ассоциацию с Вера и сразу извлекаете из своей памяти пароль: Вера, Надежда, Любовь и мать их София. Жили в Риме. День памяти - 30 сентября.

В общем-то всё такое же можно применить и к паролям, но:

• паролям характерно требовать использование разных регистров букв, чисел, иногда специальных символов. В пассфразах же главное — это БОЛЬШАЯ (с точки зрения паролей) длина, а не сложность. Пассфраза в 18 символов – это очень плохая пассфраза, никуда не годится
• паролям характеро быть плохо запоминаемыми. Если пароль вводится каждый день и несколько раз в день – запомните без проблем. Но забудете, когда перестанете использовать. Личный пример: когда-то я работал в компании с доменными политиками и вводил доменный пароль много раз в день. Конечно я помнил свой последний пароль ещё несколько недель после увольнения. Но сейчас не могу вспомнить даже в совсем общих чертах, даже примерно. Не смогу даже сказать, был ли там восклицательный знак или цифра 3

О рекомендациях NIST

Предлагаю просто обратиться к рекомендациям NIST. Опираться буду на ещё черновую версию NIST SP 800-63 Digital Identity Guidelines. Если кому-то надо текущую, а не черновую, то -4 в ссылке замените на -3. Но всё равно эта черновая всё же станет стандартом, а ссылка не изменится.

Нам нужен NIST Special Publication 800-63B

Запоминаемый секрет — это то, что мы привыкли называть паролями или, если речь о цифрах, – пинами. Это всё то, что вы знаете (или способны заучить, будучи обычным человеком). Секретам нужно быть достаточно сложными, чтобы их было сложно распознать. См. раздел 5.1.

• минимальная длина должна быть не менее 8 символов
• секреты длиной от 64 символов обязаны приниматься и корректно обрабатываться
  • ограничения сверху NIST не накладывает, но наоборот, говорит, что должно принимать от пользователя столько, сколько пользователю удобно
• должны приниматься все печатные символы ASCII, пробелы, а также символы юникода
• допустимо (то есть не запрещено, но и не обязательно) отбрасывать вайтспейсы в начале и в конце ввода, как защиту от возможных опечаток. Но тогда и проверка на длину должна быть после отбрасывания
• допустимо проверять пароль в обоих регистрах для первого символа, как ещё один способ исправления опечаток. Обращаю внимание – проверять оба регистра, а не безусловно приводить первый символ к какому-то регистру
• проверять нужно каждый символ секрета, отсечка по длине недопустима
• ЗАПРЕЩЕНО требовать секреты в смешанных регистрах
• ЗАПРЕЩЕНО требовать специальные символы
• ЗАПРЕЩЕНО требовать периодической смены секретов
  • но если была утечка или выявлена компроментация – необходимо требовать смену секрета

Для запоминаемых секретов NIST не выдвигает никаких требований к энтропии самих секретов, перекладывая отвественность на бэкэнд при их хранении (и к алгоритмам шифрования ещё)

Почему так?

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

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

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

• совсем говно должно отсекаться чёрными списками + правилами запрета повторений и последовательностей
• длина паролей ограничивается снизу. Нет никаких запретов требовать от 16 символов, например. Главное, что не менее 8 и нет ограничений сверху

Такие мягкие рамки подведут пользователя к как раз парольным фразам и менеджерам паролей. Второе опустим, а вот профиты первого:

• простота запоминания приведёт к тому, что пользователь не будет писать фразу на бумажке и класть под клавиатуру
• он не будет перепробовать десять вариантов, как же он задавал, вторая заглавная или третья, или ещё как-то
• пользователю будет не сложно запоминать даже достаточно длинные фразы
• пользователю не нужно разбираться, 0 это или О. I это или l
• их проще копировать. Выделение простых слов не вызывает проблем
• их можно легко передать голосом другому человеку
  • сколько угодно можно говорить, что диктовать пароль никогда не пригодится, но это до первой необходимости объяснить что-то своей матери

Пример выше с Верой – это более 70 символов, но слушатель радио “Вера” уже запомнил его.

Есть у парольных фраз ещё одно очень важное преимущество – их легко писать на “проблемных” устройствах. Например, попытаться залогиниться в веб сервисе на телевизоре или какой-нибудь PlayStation без подключения клавиатур и подобного. Потому что и в современных телевизорах, и в приставках, есть подсказки слов их остаётся только выбирать из предлагаемых.

NIST прямо указывает, что нужно принимать 64+ символа и это нужно для фраз: https://pages.nist.gov/800-63-4/sp800-63b.html#memorizedsecrets При том что для русского языка это всего в среднем 9 слов и 8 пробелов между ними (при средней длине слова в 6 букв).

Но парольные фразы не идеальны, есть у них и проблемы, часть из которых худо-бедно можно приуменьшить:

• они, блин, длинные
  • не считая менеджеров паролей, тут немного помогают клавиатуры смарт-устройств, которые без проблем позволяют добить слова. При чём это дёшево и работало даже на древних тупофонах и называлось T9 (земля ему пуховик)
• эти же самые клавиатуры умных устройств могут заучивать последовательности слов (такое бывает, если софт писан жопой и автор не соблюдает правил ОС, под которую пишет)
  • достаточно большое количество слов (9+ для русского языка при 64+ символах) во фразе помогает снизить или вовсе убрать урон
  • от говнософта не спасут и пароли. Было время, когда Samsung устройства на Android охотно подсказывали пароли, потому что заучивали всё, что пишут с них, включая поля паролей. И понять, что это пароль всё же сильно проще, чем понять, что это одно из слов парольной фразы (кстати, это слово может быть и из серидины фразы)
• парольные фразы тоже бывают очевидными и предсказуемыми
  • NIST нигде не говорит, что стоп списки паролей не должны применяться и к фразам
  • здесь, кстати, меньше 64 символов

Фразы лучше паролей?

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

То есть если лично ты делаешь всё по красоте – 18 символов пароля с самыми извращёнными символами из юникода и вообще не знаешь этот пароль, а хранишь его в православном KeePass, на который ещё и минимум 2 фактора навешано; если ещё и на сами сервисы вешаешь вторые факторы, то нет никакой нужны использовать фразы.

А я перешёл на фразы (когда это возможно) из-за ерунды – не смог однажды в скрипт передать пароль. То есть в итоге сделал, но пришлось внимательно расставлять экранирования. Это, кстати, было ещё во времена Windows и это было в batch. Если вам приходилось писать скрипты на batch, то вы поняли глубину моей душевной травмы.

Но зачем настолько длинные, зачем 91 символ (с чего всё и началось)? Да не за чем. Просто стояло число 11 в генераторе и он сделал 11 слов. Вот и получилась такая длина – просто совпадение. Было бы 10, то я бы мог и не попасть на изначальную проблему mariadb клиента. Таким образом вся статья родилась из-за того, что просто стояло число 11 и я его не менял. Мне ведь всё равно, 90 там символов или 200. А с точки зрения NIST важно, что их больше 64

Об AppOpsManager

Отслеживаем (логирование) и контроль доступа (разрешение, запрет) к критичным API системы происходит через механизм app-opов. App-opы (давайте просто app-ops во множественном числе и app-op в единственном) покрывают большой набор функциональности — от рантайм пермишенов до монитора состояния батарейки. Управление же всеми этими фичами, внутри, происходит через AppOpsManager Что именно можно отслеживать и как этим управлять — это вы можете увидеть по ссылке выше. Здесь же нас интересуют именно режимы контроля.

Контроль доступа

Всего таких режимов четыре:

• MODE_DEFAULT — режим “поведения по умолчанию”, которое напрямую документацией не описано. Просто “может отличаться от одного app-op к другому”. Спасибо, ничего не понятно, но очень интересно.
• MODE_ALLOWED — режим, в котором доступ разрешается
• MODE_ERRORED — режим, в котором доступ не просто запрещается, а ещё бросается SecurityException при обращении
• MODE_IGNORED — режим, в котором и доступ не предоставляется, так ещё и ничего не возвращается

Разрешение и запрет с ошибкой выглядят прям очень знакомым, не так ли? Эти режимы доступны пользователю в интерфейсе Android, они позволяют понимать приложению, одобрил пользователь какой-то пермишен или отказал. Но это для пользователя. Для производителей и прошивок, и MDM решений, есть вот этот классный режим игнорирования. Если вы сами производитель какого-то MDM решения, то это разрешение ну очень полезно для вас.

В режиме игнорирования условный диктофон просто не узнает, что у него нет доступа к микрофону — ведь исключения SecurityException не вылетает. И будет считать, что запись идёт. То есть вам, как производителю MDM или защищённой прошивки, выгодно переводить app-ops приложений именно в игнор. Потому что очень наглые приложения начнут настаивать предоставить им доступ.

Кстати, пользователь тоже может управлять app-ops и у него есть полтора способа. Сначала я написал “обычный пользователь”, потому убрал это прилагательное, всё же пользователь должен быть подготовлен на столько, что способен использовать adb. Об этих способах расскажу ниже, когда опишу уязвимость.

Уязвимость CVE-2022-20551

История обнаружения

Мой коллега и руководитель обнаружил, что WhatsApp в режиме MODE_IGNORED продолжает записывать голосовые сообщения. Хоть они и выглядели как запись без звука (что было бы правильным поведением) — просто прямая линия, — но звук на самом деле записывался и голосовое можно было прослушать. Но полбеды в том, что запись выглядела как запись без звука. Индикатор Android о доступе к микрофону не включался и в истории доступа к микрофону WhatsApp не появлялся. Будто он микрофон никогда и не использовал. На меня упала задача посмотреть, что вообще не так.

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

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

Проталкивание проблемы

Aug 19, 2022 08:50PM — это точное время, когда я оформил баг 243152409 в багтрекере Google. Т.к. это проблема безопасности, то оформлял через специальную форму и полученный баг не публичный, попасть туда могу я и сотрудники Google. В этом баге было описано, как WhatsApp обходит режим игнорирования. Я приложил запись видео и сценарий воспроизведения. Ну и информацию о системе, разумеется — при оформлении проблем безопасности эти поля обязательны. Даже точную версию мессенджера указал, на случай, если WhatsApp резко изменят поведение. Это была последняя доступная версия на тот момент.

Казалось бы. Вот вам приложение, вот вам инструкция воспроизведения, как выставить режим игнорирования, вот вам даже видеозапись. Однако Aug 27, 2022 12:15AM получаю ответ: Status: Won't Fix (Infeasible). И объяснение, что мы не считаем это проблемой. Цитировать переписку не буду, ну мало ли. Можете поверить мне наслово. Но там была строка “The Resolution Notes label has been set to NSBC (Not Security Bulletin Class) to reflect this assessment”. Зафиксируем, что 27 августа 22 года воспроизведение на реальном ПО посчитали “working as intended”.

Сообщил нашей команде о том, что Google положил болт на проблему. Это подкинуло дровишек в топку “это дыра – для кого надо дыра, не лезьте”. Но дожать надо. Решили предоставить им PoC, который не имеет ничего лишнего, кроме эксплуатации уязвимости. Забегая вперёд скажу, что сценарий его использования такой же, как и WhatsApp. То есть мессенджера было совершенно точно достаточно.

Наш сотрудник Артём (фамилию не скажу, но лишний раз подчеркну наше всеобщее уважение к нему) разобрал WhatsApp и провёл исследование, как же мессенджеру удаётся обходить ограничение, тогда как все другие этого сделать не могут.

12 сентября Артём всё же докопался до истины. Оказалось, что при использовании OpenSLES режим игнорирования просто не работает. Далее Артём написал PoC, основанный прям на демке самого Google по работе с OpenSLES. Ну то есть Гугл буквально зажали в углу: демонстрация использования уязвимости была сделана на их собственном примере работы с технологией.

Sep 13, 2022 04:52PM я добавляю в ишую со статусом “вонт фикс” новое сообщение. Цитирую его целиком и прикрепляю PoC, чтобы вы могли проверить свои собственные прошивки. Если у вас установлены февральские (от февраля 23 года) обновления, то проблема не будет воспроизводится. Если же не установлены — словите описанное ниже поведение. И важно, проверять нужно на Android 12 и новее, потому что в версиях ниже не было визуального индикатора, который бы показывал, что сейчас идёт прослушивание через микрофон. То есть проблема есть и на 11 и ниже, просто пользователь в принципе не мог раньше понять, что что-то происходит.

Added PoC. It uses OpenSLES

1. Install app
2. Run app
3. Tap on Record button
4. Allow access while using the app
5. Speak something during 5 seconds → We see the microphone access indicator
6. Tap Play button → We hear ourself
7. adb shell pm list packages -U | grep nativeaudio → package:com.example.nativeaudio uid:10060
8. adb shell cmd appops set 10060 RECORD_AUDIO ignore
9. Tap Record button
10. Speak something during 5 seconds → We not see indicator
11. Tap Play button

Expected: silent
Actual: we hear ourself

PoC можно скачать здесь.

Через час после этого Google отписал “спасибо за новую инфу, мы рассмотрим эти данные”.

Sep 23, 2022 01:04AM сотрудник Google написал новое сообщение, где признал проблему: “Based on our published severity assessment matrix (1) it was rated as Moderate severity”. Единичка – это ссылка на матрицу: “(1) Severity Matrix: https://source.android.com/security/overview/updates-resources#severity”.

Oct 8, 2022 06:50AM — гугловцы сообщают, что назначено такое-то вознаграждение.

Nov 10, 2022 08:48PM — гугловцы пишут, что мы всё ещё работаем над исправлением

Jan 6, 2023 09:31PM — новое обновление статуса. Уведомили, что деняк будет выплачено больше, потому что “After conducting additional review of the security issue in this report, we have revised the severity to High”. Я думаю, что у них из отпуска вернулся кто-то, у кого голова не только чтобы в неё есть. И он объяснил остальным, что вы чего вообще, это не какое-то приватное API. Это API мы даём специально для обеспечения безопасности и его используют в том числе Samsung.

Далее ещё несколько переписок по формальностям чистым. Типа, заполните вот эти документы, заполните вот эти. И, наконец, Feb 13, 2023 10:35PM происходит главное: Marked as fixed.

Эта ошибка для своих

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

• Предоставленное полное описание проблемы с демонстрацией на видео и чёткой инструкцией, но конкретно на WhatsApp они вообще не посчитали проблемой: “Based on our review, this issue has been determined to not be a security vulnerability and is working as intended”
• Как только это же самое сделали на другом приложении, они проблему признали
• Мало того, они признали, что это проблема высокой важности по их собственной системе оценок
• Можно было бы посчитать, что у них не получилось воспроизвести на WhatsApp, но это не так. Посмотрите на фикс: они прямо в нём написали, что проверять надо на WhatsApp: “Test: verify app ops work with WhatsApp”. То есть всё у них получилось воспроизвести

Возможно, конечно, я перегибаю палку. Вполне вероятно, что проверял человек, который увидел в WhatsApp прямую линию на записи и просто не прослушал запись, решив, что голосовое сообщение не записалась. А в PoC прямых линий не рисовали и они таки убедились, что всё работает. Но тогда получается, что Security Team в Google не тянули с исправлением, а просто забили болт на проверку.

Какой вариант выбираете: забили болт или тянули с фиксом, потому что уязвимость пока что нужна была?

App-opp у себя

Если вам нравится идея режима игнорирования, вам не обязательно (покупать?) и ставить MDM решение от стороннего производителя. У вас есть полтора пути. Полтора, потому что путь в итоге один, просто “второй” способ — это через GUI, но внутри тоже самое, что и “первый”.

Первый способ вы уже видели на PoC. Получаем UID приложения и выставляем ему режим через adb. Второй — использовать приложение, которому поднимете привилегии через тот же adb. Я сам проверял на Permission Manager X и что-то даже работало. Но я не ходил с ним. Просто проверил, что, прикольно, срабатывает и на этом всё.

Моя телега: https://t.me/mydaybug

Изменения, касающиеся всех приложений

Здесь собраны изменения, которые задевают приложения, даже если их таргет ниже 14. Называется новая версия, если что, Android Upside-down cake — “перевёрнутый” пирог или “вверх ногами” или “наизнанку” — как угодно. В общем, суть в том, что после выпекания этот пирог переворачивают и то, что раньше было верхом пирога становится его дном.

Core функциональность

Разрешение SCHEDULE_EXACT_ALARM больше не выдаётся автоматически

Exact alarms — это когда нужно выполнить задачу в строго заданное время, ни раньше, ни позже. К примеру — напомнить о встрече. Начиная с Android 14 для большинства устанавливаемых приложений (очевидно, не касается уже установленных), таргет которых начинается с 13, пермишен SCHEDULE_EXACT_ALARM автоматически выдаваться больше не будет. В общем, теперь нужно спрашивать его явно.

Контекстно-зарегистрированные бродкасты ставятся в очередь для кешированных приложений

Если приложение перешло в состояние “кешировано” (то есть оно не на переднем плане и не убито системой и становится кандидатом на отстрел), то контекстные бродкасты складываются в очередь. Если приложение не будет отстрелено системой и пользователь снова к нему обратиться, то лежащие в очереди бродкасты будут доставлены, если контекст позволяет.

Приложения могут убить только собственные фоновые процессы

Метод killBackgroundProcesses() может убить теперь только фоновые процессы того приложения, из которого был вызван. Наконец сдохнет большинство “оптимизаторов батареи”. К сожалению, во-первых только сторонние, во-вторых не все. Вендорский шлак так и будет существовать, а разработчики стороннего ПО то и дело будут ссылаться на https://dontkillmyapp.com/

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

Поднят минимальный таргет для устанавливаемых приложений

Приложения с targetSdkVersion ниже 23 (это Android 6) больше не могут быть установлены. То есть в Android 14 теперь все приложения будут поддерживать runtime permission, либо не будут работать вовсе. Если приложение с более низким таргетом было установлено, когда на ваше устройство прилетел Android 14, то для него будет сделано исключение и оно продолжит работать. Но вот переустановить его уже нельзя будет.

Поле Media owner package name может быть изменено

К хранилищу медиа можно делать запросы поля OWNER_PACKAGE_NAME, в котором будет (или не будет — может быть NULL) указано имя пакета, который сохранил определённый медиа файл. Начиная с Android 14 значение этого поля будет подменяться для всех приложений кроме (должно быть выполнено хоть одно условие):

• приложение, которое сохранило этот файл, входит в список приложений, которые всегда видимы другим
• приложение, которое запросило это поле, имеет разрешение QUERY_ALL_PACKAGES

User experience

Давайте уже согласимся, что говорить “юикс” нормально, а говорить “пользовательский опыт” — это ментальное заболевание. Впрочем, лично мне нравится говорить “привычки”, хотя в реальной речи стараюсь не использовать это слово. Оно нравится мне, но другие как-то так не говорят и боюсь, что буду сбивать с толку других

Взаимодействие с несмахиваемыми уведомлениями

В Android 14 пользователь может смахивать уведомления, которые ранее были не смахиваемыми, но в конкретных случаях. Если уведомление сделано не смахиваемым установкой флага FLAG_ONGOING_EVENT, то пользователь теперь может всё-таки его смахнуть. Флаг выставляется, например, через NotificationCompat.Builder#setOngoing(boolean).

Такие уведомления всё равно не будут смахиваться, если:

• телефон заблокирован. Ну то есть на экране блокировки
• пользователь нажал кнопку очистки уведомлений. То есть случайно потерять не получится

Поведение не меняется, если:

• уведомление создано с использованием MediaStyle API — то есть явно для плееров
• политики запрещают это действие

Предоставление частичного доступа к фото и видео

Если вам достаточно фото пикера, то можно пропускать.

В Android 13 появились пермишены доступа к изображениям (READ_MEDIA_IMAGES) и видео (READ_MEDIA_VIDEO). В Android 14 диалог запроса разрешения изменился:

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

Ну и видно, что разрешение READ_MEDIA_AUDIO не задето.

Специальные возможности

Масштабирование шрифта до 200%

Система позволит задавать масштабирование шрифта до 200%. Будьте добры убедиться, что ваше приложение к этому готово.

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

Изменения, стреляющие для target на 14 и выше

Некоторые из изменений ниже касаются приложений с таргетом и ниже 14. Но поддержка 14 позволяет управлять поведением более точно.

Core функциональность

Для foreground services требуется указание типа

Для приложений с targetSdkVersion на Android 14 для каждого foreground service нужно указывать его тип из заранее предопределённого списка. Если для приложения нельзя выбрать логичный тип из списка, то нужно переехать на WorkManager или специально созданный user-initiated data transfer job. Не уверен, что это нужно переводить. Вроде понятно, что речь идёт о задачах, которые инициировал сам пользователь.

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

Ограничения неявных и отложенных интентов

Мы все говорим “интент”. А вот говорите вы “отложенный” или “пендинг”?

Приложения с таргетом на Android 14 получают изменённое поведение взаимодействия со своими собственными компонентами:

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

Бродкаст ресиверы, зарегистрированные в рантайме, должны явно указать эспортированность

Контекстные ресиверы (о них было выше) в приложениях с таргетом на Android 14 обязаны явно указать, экспортированы они (RECEIVER_EXPORTED) или нет (RECEIVER_NOT_EXPORTED). При регистрации слушателя системных бродкастов (к примеру переход в режим полёта или установка приложения) это указание не требуется. Всё равно системные послать кто угодно не может — считается, что защита уже есть.

Более безопасная динамическая загрузка кода

Если приложение имеет таргет Android 14 и использует динамическую загрузку кода, то есть буквально передаёт внешнюю либу загрузчику, то теперь нужно помечать файл с этим кодом доступным только для чтения: File#setReadOnly()

Ну и отдельно Google просит (но не проверяет) явно пересоздавать эти файлы. Не проверять, что раз файл есть, то не перекачивать. А прям удалять и качать его снова. Видимо идея в том, чтобы вам не подложили левый файл и вы не приняли его за свой собственный. Ну и просят проверять подпись файла.

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

Новые ограничения запуска активити из фона

Для приложений с таргетом на Android 14, система накладывает ограничения на запуск активити из фона:

• отправитель, посылающий PendingIntent другому приложению, должен явно указать, позволяет ли он запускать себя из фона
• когда видимое приложение использует метод bindService() и, собственно, биндится к сервису другого приложения, которое сейчас в фоне, оно должно сообщить, можно ли теперь тому фоновому сервису запускать активити инициатора. Для этого есть флаг BIND_ALLOW_ACTIVITY_STARTS

Обновлены ограничения не SDK интерфейсов

Начиная с Android 9 урезают доступ к разным API. Часть держат в белом списке, часть в сером (типа, готовьтесь, можем отрезать), к части доступ заблокировали. Каждый релиз список пополняется. Вот, снова пополнили. Сейчас он весит больше 50 Мегабайт в csv формате.

Пример одной строки, как эти ограничения описаны:

Landroid/Manifest$permission ->BIND_COMPANION_DEVICE_SERVICE:Ljava/lang/String public-api sdk system-api test-api

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

Не знаю как вам, а мне изучение было полезным. А то я уже несколько релизов пропустил.