Зачем будильнику микрофон
Ставите приложение — простое, на первый взгляд: заметки, фонарик, будильник. И ещё до первого экрана система показывает список: доступ к файлам, к камере, к микрофону, к вашему местоположению. Будильник просит микрофон.
Первая реакция — «зачем?». Вторая, как правило, — «ладно». Нам интересна первая: ответ на неё объясняет, как телефон устроен изнутри. Разрешение — единственный механизм, которым система делит власть между программами.
Устройство простое. Телефон — дом с общими кладовыми: камера, микрофон, контакты, файлы, местоположение. Любое установленное приложение — жилец, и без замков он дотянется до любой кладовой. Поэтому система держит каждую кладовую за дверью и раздаёт ключи только с согласия человека. Список разрешений — это опись дверей, которые приложение просит открыть.
А зачем вообще замки? Потому что без них хуже. Если бы любая программа могла слушать микрофон и читать файлы без вопросов, одна плохая установка означала бы неограниченный ущерб. Замки не делают жильца честным — они делают его действия видимыми: система знает, у кого какой ключ, и может его отобрать.
Так что список разрешений — это торг: «покажи, что тебе нужно, а человек решит». Торг кривой, и в этом вся проблема.
Откуда в списке лишние пункты
Почему пунктов больше, чем нужно? Причины скучно-экономические, а не зловещие.
Начнём с арифметики шагов. Одна функция — несколько ключей. Прикрепить фото к сообщению — это доступ к файлам; донести фото до собеседника — сеть; «позвонить из приложения» — микрофон. Функция, которую вы описали одним словом, внутри разложена на шаги, и почти каждый упирается в свою дверь. Отсюда странности, похожие на наглость: во многих телефонах фонарик — это вспышка камеры, поэтому фонарик честно просит доступ к камере. По-другому вспышку не включить, и система об этом знает.
Дальше — то, о чём обычно не догадываются. Приложение почти никогда не пишут с нуля: его собирают из готовых блоков — показ рекламы, сбор статистики, карта, вход по номеру. У каждого блока свои аппетиты, и ключи блоки просят сами, не спрашивая автора приложения. Разработчик подключает рекламный блок, чтобы программа окупалась, а блок тянет за собой местоположение: чем точнее реклама попадает в человека, тем дороже стоит показ. В списке это выглядит прихотью автора — хотя автор, возможно, вообще не в курсе. Кто и что на самом деле попадает в программу и кто читает этот перечень — тема нашего материала о цепочке поставки.
Ещё причина — смета. Написать программу, которая умеет работать и без камеры, и с камерой, — это два поведения вместо одного: дороже писать, дороже проверять. Дешевле попросить всё сразу: кто согласился, тому работаем; кто отказал, тому извините. Это не зло. Это лень, вписанная в смету.
Есть и деньги как таковые: часть ключей нужна не функциям, а продаже. Список разрешений это намерение честно показывает — просто не подписывает его.
И история: в старых системах замков почти не было, ключи выдавались автоматически, и все привыкли тянуть всё. Привычка осталась в коде, который пережил правила.
Складывается одно: список длиннее, чем нужно именно вам, и молчит о главном — зачем.
Тупик: решить всё по списку
Что делает человек, которого беспокоит судьба его данных? Читает список при установке. Внимательно, целиком. Со стороны это выглядит ответственно — и именно здесь тупик.
Список отвечает на вопрос «что», а решение требует ответа на «зачем». «Доступ к микрофону» не сообщает ничего, пока неизвестно, что приложение собиралось делать с этим микрофоном. Список объяснить не может: система сама не знает, зачем приложение просит, — она лишь фиксирует просьбу.
Дальше — арифметика внимания. Чтобы осмысленно решить судьбу одного пункта, надо удержать в голове, что это за программа, что она обещала и что даёт в её руках конкретная дверь. Пунктов много, внимание одно, и всё это происходит до первого запуска — в момент максимального незнания об этом приложении.
Поэтому список превращается в ритуал: его пролистывают и жмут «разрешить», с каждым разом всё привычнее. Согласие, отданное не глядя, — подпись под документом, который никто не читал.
Зеркальный тупик — отказывать всему подряд. Тоже мимо. Приложение будет спрашивать снова при каждом удобном случае: отказывать утомительно, спрашивать — нет, и в этой гонке терпения выигрывает спрашивающий. Важнее другое: замки охраняют не всё. Они стоят на дверях к общим кладовым — камере, файлам, контактам. А всё, что вы отдаёте добровольно внутри приложения — поисковые запросы, номер при входе, фотографии, загруженные своими руками, — выносится через крыльцо, и ни один замок на это не смотрит. Можно отказать во всём — и всё равно рассказать о себе очень много.
Тотальное «да» и тотальное «нет» не работают одинаково. Работает третий путь.
Момент важнее списка
В списке при установке информации почти нет. В моменте запроса — есть.
Современные системы часто спрашивают разрешение не при установке, а когда приложение впервые что-то делает. И этот момент — свидетельство. Игра просит микрофон на кнопке «записать ролик» — понятно. Игра просит микрофон при первом запуске, до всяких кнопок, — вопрос. Навигатор спрашивает местоположение, когда вы строите маршрут, — это его работа. Тот же навигатор спрашивает местоположение, когда маршрут построен и вы стоите дома, — вопрос.
Отсюда рабочая привычка: отвечать «сначала нет». Отказ — бесплатный эксперимент, и главный его плюс — обратимость. Дать ключ можно в любой момент, отозвать — тоже. Если приложение без ключа работает — вы узнали, что ключ был не нужен. Если не работает — оно само скажет, чего ему не хватило, и это первая честная «зачем» в ваших отношениях с программой. Согласие такой информации не даёт никогда: после «да» вы не узнаете, брал ли приложение ключ со стены вообще.
Про геолокацию — отдельно, потому что это самый дорогой ключ. Система обычно предлагает выбор: давать место постоянно или только пока приложение открыто. Постоянный доступ нужен узкому кругу программ — тем, чья работа и есть следить за перемещением. Остальным хватает «пока открыто». Если приложение настаивает на постоянном, не объясняя зачем, — это самый содержательный пункт во всём списке.
Ещё привычка, которая окупается: замечать новые просьбы у старых приложений. Программа год работала без камеры — и вдруг попросила её после обновления. Это событие. Не обязательно плохое: возможно, добавили сканер. Но событие, ради которого стоит открыть настройки и прочитать, что именно обновилось.
И последнее. Список разрешений в настройках телефона полезен по-другому: это инвентаризация. Изредка пройтись и посмотреть, у кого сейчас геолокация и микрофон, — единственный способ заметить, что накопилось незаметно. У того, чем давно не пользуетесь, ключи можно отзывать без сожалений: вернётся — попросит снова.
Позиция редакции
Наша позиция: правильный ответ по умолчанию на любой запрос разрешения — «нет». На «да» меняем его только после того, как приложение объяснило, зачем ему ключ: словами, кнопкой или внятной поломкой.
Позиция держится на одном механизме. Отказ и согласие обратимы одинаково, но отказ возвращает информацию, а согласие её забирает. Сказав «нет», вы узнаёте, нужен ли был ключ; сказав «да», не узнаете ничего. Вся стратегия — покупать информацию отказами.
Теперь честное: условия, при которых эта позиция неверна. Не «неудобна» — именно неверна. Оба проверяются на себе.
Первое условие — момент повторного вопроса. Сила «сначала нет» в том, что вы отвечаете на спокойную голову. Но приложение само решает, когда спросить снова, и выгодный для него момент — не «когда человек спокоен», а «когда человек хочет»: запрос выскочит поверх кнопки, которая без ключа не работает. В эту секунду цена отказа — потерять желаемое прямо сейчас, и мало кто взвешивает дальные последствия данных против немедленного «хочу». Тогда «сначала нет» ничего не экономит: оно переносит то же решение на момент, когда ответ заведомо «да» и дан не глядя. Проверка простая. Если вы ловите себя на «разрешить», нажатом поверх нужной кнопки, — стратегия развернулась против вас: ваши отказы стали отсроченными согласиями, и для вас наша позиция неверна. Вместо защиты она даёт ровно то бездумное «да», с которым борется. Правильный ход здесь противоположный: давать ключ на спокойную голову — заранее, в настройках, — а не отнимать его на горячую.
Второе условие — немой отказ. Позиция предполагает, что после «нет» приложение объяснит, чего не хватило. Бывают программы, которые вместо этого ломаются молча: функция просто исчезает, без слов. Тогда отказ не возвращает информацию, а хуже — каждый такой отказ учит, что «нет» ломает программы, и к следующему запросу рука идёт к «разрешить» рефлекторно. В таких программах наша позиция ошибочна вдвойне: она слепа и при этом тренирует противоположное. Честный выход другой: либо соглашаться осознанно и записывать, кому что дали, либо не пользоваться программой, которая не умеет объяснить собственную поломку.
И граница, где позиция не ошибается, а пустеет: если назначение приложения — то самое разрешение, отказ лишён смысла. Навигатор без местоположения — не навигатор. Отвечать «сначала нет» на вопрос, ответ на который вы знали до установки, — потеря времени, а не осторожность. Здесь список при установке как раз честен: он показывает, что вы покупаете.
Если ни одно из этих условий не про вас — на следующем запросе ответьте «нет» и посмотрите, что скажет приложение. Это самый дешёвый способ узнать, кому вы доверяете.