Создание Android-смартфона с упором на приватность

Важная оговорка

Данный метод актуален только под Android, для работы потребуется рутированый телефон.

Мотивы

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

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

Копаем вглубь

Почему бы всем этим приложениям на телефоне не дать ровно то, что им нужно для работы а всё остальное отнять? — Но на каких устройствах это технически возможно сделать, и как понять что им надо?

Из устройств лучше всего подойдёт «нечто», — на чём используется Linux‑подобная операционная система, и конечно лучше с root‑доступом. То есть телефон на Android с разблокированным загрузчиком.

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

Для изучения я установил на ПК под управлением Linux Ubuntu — Android SDK, в котором с помощью андроид‑эмулятора создал тестовую среду для изучения. Тестовая среда — это виртуальная машина/телефон с root‑доступом, общение с которой возможно в графическом интерфейсе и с помощью командной строки (Android Debug Bridge).

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

Что же я там увидел, и что удалось узнать таким способом?

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

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

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

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

Решение

Так как мы используем Linux‑подобную операционную систему, то почему бы нам не использовать обычный фаерволл типа Iptables и попросту не отозвать лишние права у всех приложений?

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

Iptables не работает с доменами, а только с IP‑адресами. Поэтому с помощью модуля nslookup для Magisk мы узнаём IP‑адреса из всех белых и черных списков, на основе них составляем список цепочек для Iptables и потом заносим их в правила. Делает это автоматический скрипт раз в 3600 секунд.

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

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

/data/adb/netiso/
├── netiso.sh
├── global-blacklist.txt
├── rules.v4
├── cache/
└── apps.d/
    ├── первое_приложение.conf
    ├── второе_приложение.conf
    ├── третье_приложение.conf
    ├── четвертое_приложение.conf
    └── пятое_приложение.conf

/data/adb/service.d/
└── netiso-loop.sh

Где:

• netiso.sh ^[1] — основной скрипт;

• global-blacklist.txt — глобальный blacklist;

• netiso-loop.sh ^[2] — скрипт автоматического обновления IP-адресов.

Применение на реальном устройстве

Исполнение:

• выбрана подходящая для кастомизации модель телефона на Android

• разблокирован загрузчик

• установлен кастомный Recovery

• телефон рутирован с помощью Magisk

• удалены лишние системные приложения

• установлен модуль Busybox для Magisk

• создана структура каталогов

• заполнены глобальный blacklist и whitelists для каждого приложения

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

Второе пространство на телефоне

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

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

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

Немного гигиены

Одной из идей было настроить подключение телефона только к определённым wi‑fi сетям, чтобы не использовать общественные сети wi‑fi. Но проверив настройки телефона, пришёл к тому что в этом нет необходимости. Телефон и так будет подключаться только к тем wi‑fi сетям, которые запомнил.

Второй из идей — было использование чехла Фарадея для телефона. Его название напоминает клетку Фарадея, — это защитный экран из замкнутой проводящей оболочки, блокирующий любые сигналы. Если поместить телефон в такой чехол, телефон должен стать «невидимым» для окружающего мира. Данную идею рассматриваю для эксперимента

Итоги

Идея оказалась рабочей, на реальном телефоне применённый метод полностью работает. Если нужно будет добавить новое приложение — его можно будет «встроить» в фаерволл. Если какое‑то приложение станет работать иначе, — можно изменить конфигурацию для него. В моём случае были изучены и созданы правила для 17 приложений, которыми я пользуюсь.

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

Предостережение для желающих повторить данный эксперимент:

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

• важно выбрать подходящую для задачи модель телефона, иначе может не получиться