Pull to refresh

Comments 34

Спасибо. Полезно. Хорошо, что в последней версии Android этот вопрос решили.
Foreground Services Requirement — When does your app interact with the camera? On Android 9 (API level 28) and later, apps running in the background cannot access the camera. Therefore, you should use the camera either when your app is in the foreground or as part of a foreground service.
Правда не понятно, когда Pie доберется до всех. Да и в этом случае вендоры могут оставить для себя бэкдор и тогда даже ADB не спасет.

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

Безопасность и возможности- две стороны одной медали. Предполагаю, что в начале сделали ставку на второе по принципу «не нравятся пермишены- не устанавливай». По идее большое количество доступов к личным данным должно было опускать приложение в списках из-за отказов.

Только крупные сервисы не оставляли пользователям альтернатив. А потом понемногу пошли скандалы о сливах.

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

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

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

Вот бы и выложили статью на эту тему, как продолжение к нынешней… Глядишь, кто-нибудь бы и эти дыры позакрывал.
Справедливо. Я думал об этом раньше, но в итоге решил отказаться по двум причинам:
1. Все эти способы давно есть на stackoveflow и в остальном интернете
2. Процент отказов и получения ложных или неверных данных настолько велик, что подобное не годится для широкомасштабного применения. Потому это не интересно ни компаниям ни отдельным лицам. И потому подобное мало реально встретить в приложениях (скорее всего, такие даже не пройдут постмодерацию). И потому статья об этом получится бесполезной. У меня есть более интересный материал)
Приложения некоторых крупных сервисов отказываются работать, пока пользователь на старте не даст им доступы к смс

А еще не написали патч, который позволяет эмулировать выданный доступ? То есть приложению вызов функции перечисляющей разрешения отдает желаемое, а при попытке воспользоваться этим разрешением возвращает OK, но без данных или с шумом вместо данных.
Для старых приложений примерно так и должно работать, для новых при доступе- exception. Возможно, решение есть у отдельных вендоров. Но нельзя такое расценивать как патч. В самой системе пермишенов, с точки зрения реализации и логики, проблем нет. Есть проблема в наглости сервисов. Даже если и станет подобная подмена повсеместной- сервисы начнут вкладывать человекочасы в способы определения реальности получаемых данных.

Давно написали, для старых андроидов это XPrivacy, для новых XPrivacyLua, но для его работы нужен рут и Xposed Framework.

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

А еще не написали патч, который позволяет эмулировать выданный доступ?

Есть вполне законный способ это делать для большинства разрешений без рута (но только для Android 6.0 и выше).

Можно поставить Shizuku Manager, дать ему доступ с помощью adb (инструкция прямо в приложении), потом поставить App Ops — и рулить как угодно.

Если доступ к чему-то закрыт в App Ops, то приложению (если оно его запрашивает) можно сказать Allow — оно всё равно ничего не получит (пустой список контактов, SMS etc), хотя будет уверено что разрешение получило.

Закрыть таким образом доступ в сеть нельзя, но контакты, микрофон, камера, GPS и ещё куча всего (включая возможность работать в фоне) — вполне можно.

Используются стандартные возможности Android, никакой магии (отбирать доступ можно просто с помощью adb — до переустановки приложения), эти два приложения просто удобный UI.
А для сети вроде тоже чего-то было же
В Lineage OS есть Trust, я так сберу «выдавал» разрешения на доступ к смс, телефону и местоположению
Приложения некоторых крупных сервисов отказываются работать, пока пользователь на старте не даст им доступы к смс, звонкам, контактам и т.д.

Когда уже появятся решения с fake permissions? Приложение думает, что разрешщение ему дали, а по факту — скармливают мусор.
Написал комментом выше. По факту оно и не нужно, если бы GDPR и его аналоги распостранялись на всех.
Появится fake permissions повсеместно- сервисы начнут с этим бороться анализом фейковых данных.
С другой стороны, так можно и такси в другую страну вызвать случайно, и записать на диктофон шум вместо голоса)
Написал комментом выше. По факту оно и не нужно, если бы GDPR и его аналоги распостранялись на всех.

Слежка и так не законна. Но всем плевать.

Появится fake permissions повсеместно- сервисы начнут с этим бороться анализом фейковых данных.

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

С другой стороны, так можно и такси в другую страну вызвать случайно, и записать на диктофон шум вместо голоса)

А это уже детали использования. Если диктофону дал фейк пермишен вместо настоящего на запись звука — сам себе злобный буратино. А вот зачем сервис погоды хочет доступ к звонкам и не работает без него — вопрос открытый.
Ну и идет он нафиг с такими хотелками.
Тем не менее, вопрос «почему сервис погоды не может работать без идентификации пользователя» остается открытым
Слежка и так не законна. Но всем плевать.
Потому большинство этим и не занимается. Зато большинство собирает данные о аккаунтах и прочих идентификаторах пользователя и устройства, установленных приложениях и так далее. Что с такой bigdata можно делать- уже давно известно.

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

Врядли у тех, кто делает скам приложения достаточно ресурсов чтобы победить в этой войне. Это все таки не гугл против адблока.
Это битва именно такого класса. Речь идет о вендорах, финансовых организациях и компаниях вроде Facebook- у них ресурсов более чем достаточно. А даже если и не победят, и Android защитит инфу своих пользователей- начнут вкладывать деньги в вендоров или ОС, которые более «сговорчивы», тем самым выводя такие продукты в топы рынка.

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

Увы, GDPR не запрещает сбор данных, он просто выставляет к нему определенные требования, в частности, явное согласие пользователя на их сбор, его право на opt-out и удаление уже собранных данных. Но после первого согласия до opt-out данные уже могут быть собраны, а удаление проверить невозможно — есть где разгуляться для нечестных разработчиков, особенно если они из Китая или Индии, а пользователи где-то в других странах.

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

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

Но маловероятно что такой магазин появится, или выживет (если таки появится) — разве что подобные требования введут на уровне закона, что, в свою очередь, приведет к другим проблемам.
Увы, GDPR не запрещает сбор данных, он просто выставляет к нему определенные требования, в частности, явное согласие пользователя на их сбор, его право на opt-out и удаление уже собранных данных
Верно, не запрещает. Как WhasApp пользоваться без указания номера телефона?..

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

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

В итоге Модерация с жесткой политикой тоже не особо помогают- человеческий фактор + коммерция. Если что и может помочь с вопросом- так это холодный, бездушный, не делающий исключений и хорошо протестированный софт платфомы. Только никому такой делать не выгодно- об этом писал выше.
Народ начинал массово отключать рекламу и модули проверки легальности установки программ.
Было уже, и не раз.
На моем 9 андроиде не работает, так как формат изменился, там надо ориентироваться на 'Client PID:'
Ну и немножко:
* синтаксис
ps `<длинная-длинная команда>`
читается хуже, чем
<длинная-длинная команда> | xargs ps

* грепать по захардкоженному типу процесса не очень хорошо, можно просто передать -o NAME для ps

Рабочий вариант для моего Honor 10:
while true; do while ! (dumpsys media.camera | grep 'Client PID:') do done | grep -o '[0-9]*$' | xargs ps -o NAME; date; sleep 1; done


Результат
NAME
com.huawei.camera
Fri Jan 4 11:45:15 MSK 2019
NAME
com.huawei.camera
Fri Jan 4 11:45:17 MSK 2019
NAME
com.huawei.camera
Fri Jan 4 11:45:18 MSK 2019
NAME
com.huawei.camera
Fri Jan 4 11:45:19 MSK 2019
На Android 8.1 (Honor 8X JSN-L21) тоже только Ваш вариант заработал.
Добавил в статью описание мониторинга доступа приложений к микрофону.
как выключается камера, в консоль выпадает ошибка
Error dumping service info: (Unknown error -32) media.camera
ps: {})
Fri Jan 4 14:54:06 +05 2019
и сама камера выключается с ошибкой андрод 9
HTC U11 ведёт логи камеры (и изменения разрешений доступа), без необходимости снимать dumpsys каждую секунду:

$ dumpsys media.camera
== Service global info: ==

Number of camera devices: 2
Number of normal camera devices: 2
Active Camera Clients:
[
(Camera ID: 0, Cost: 100, PID: 26107, Score: 0, State: 2User Id: 0, Client Package Name: com.htc.camera2, Conflicting Client Devices: {})
]
Allowed user IDs: 0

== Camera service events log (most recent at top): ==
01-05 13:24:12 : CONNECT device 0 client for package com.htc.camera2 (PID 26107)
12-31 12:24:34 : DISCONNECT device 0 client for package com.htc.camera2 (PID 26107)
12-31 12:24:11 : CONNECT device 0 client for package com.htc.camera2 (PID 26107)
12-31 12:24:04 : DISCONNECT device 0 client for package com.htc.camera2 (PID 25652)
12-31 12:24:04 : DIED client(s) with PID 1132, reason: (Binder died unexpectedly)
12-31 12:22:52 : CONNECT device 0 client for package com.htc.camera2 (PID 25652)
12-31 12:22:50 : DISCONNECT device 0 client for package com.htc.camera2 (PID 2733)
12-31 12:22:50 : DIED client(s) with PID 1132, reason: (Binder died unexpectedly)
12-31 12:22:36 : CONNECT device 0 client for package com.htc.camera2 (PID 2733)
12-31 12:22:32 : DISCONNECT device 0 client for package com.htc.camera2 (PID 2733)
...
12-15 14:59:54 : USER_SWITCH previous allowed user IDs: , current allowed user IDs: 0
...
Добавил улучшенный вариант кода, убирающий NAME и пустые строки
Я добавил в статью описание мониторинга доступа приложений к микрофону.
Sign up to leave a comment.

Articles