Рекомендации по веб-разрешениям

Marian Harbach

Thomas Steiner

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

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

Подсказка передового опыта

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

Никогда не спрашивайте при загрузке страницы или без взаимодействия с пользователем

Запрос разрешения у пользователя при загрузке страницы эквивалентен запросу у клиента конфиденциальной информации, когда он заходит в физический магазин. Видеть запрос разрешения (возможно, среди нескольких других запросов на подписку на рассылку и согласие на использование файлов cookie) — очень неприятный опыт. Пользователи не поймут , почему их спрашивают и какую выгоду они получат .

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

Аналогичная плохая ситуация для запроса разрешения — без предварительного взаимодействия с пользователем (также известная как временная активация пользователя ). Телеметрия Chrome показывает, что 77% запросов на разрешение в Chrome для ПК отображаются без такого очень простого сигнала намерения пользователя, и, следовательно, только 12% таких запросов разрешаются. После взаимодействия с пользователем ставки разрешения увеличиваются до 30%. Поэтому запрашивайте разрешение только после того, как пользователь взаимодействовал со страницей в какой-либо форме.

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

Решения о разрешении часто являются решениями о конфиденциальности. Основываясь на структуре контекстной целостности , мы знаем, что решения о конфиденциальности в значительной степени контекстны. Понимание того, почему необходим доступ, можно считать ключевым аспектом этого. Поэтому вам следует запрашивать только те возможности, которые вам нужны для предоставления пользователям ценности (и где пользователи, скорее всего, согласятся с вами, что они действительно получат ценность). Кроме того, вам следует запрашивать разрешение в тот момент, когда пользователю очевидно, почему эта возможность полезна. Цель состоит в том, чтобы максимально упростить для ваших пользователей понимание контекста использования.

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

Предоставьте альтернативные средства для достижения той же функциональности, где это возможно.

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

Полезным шаблоном является использование альтернативного пользовательского интерфейса также в качестве объяснения того, почему доступ может быть выгодным. Пользователи, увидев опцию ввода местоположения рядом с кнопкой, которая запускает API геолокации, будут чувствовать, что контролируют то, что произойдет, потому что они понимают, что могут просто ввести свой адрес. Аналогично, если есть выбор между получением уведомлений через push или электронную почту или присоединением к собранию без предоставления доступа к камере и микрофону, пользователи более естественно понимают компромиссы, на которые они идут.

Не доводите себя до состояния застоя, из него трудно выйти.

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

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

Обратите внимание на сторонний контент

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

Когда спрашивать разрешение

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

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

Шаблоны кода для запроса разрешения

Получение разрешения на использование API происходит разными способами, в зависимости от API. Некоторые (обычно старые) API используют модель, в которой браузер автоматически запрашивает разрешение при первой попытке использования API. Одним из примеров является API геолокации при вызове navigator.geolocation.getCurrentPosition() .

try {
  navigator.geolocation.getCurrentPosition((pos) => console.log(pos));
} catch (error) {
  console.error(error);
}

Другие API используют модель, в которой вам явно нужно сначала запросить разрешение с помощью статического метода. Хорошим примером является Notification.requestPermission() для разрешения уведомлений или менее распространенный DeviceOrientationEvent.requestPermission() , который является частью API событий ориентации устройства. Обратите внимание, что некоторые браузеры могут автоматически предоставлять разрешение указанным API. Например, Chrome всегда разрешает доступ к ориентации устройства, тогда как Safari показывает запрос.

const result = await DeviceOrientationEvent.requestPermission();
console.log(`The user's decision when prompted to use the Device Orientation
Events API was: ${result}.`);
if (result === 'granted') {
  /* Use the API. */
}

Как проверить состояние разрешений

Чтобы проверить, можете ли вы использовать определенный API, используйте метод navigator.permissions.query() из API разрешений.

const result = await navigator.permissions.query({ name: 'geolocation' });
console.log(`The result of querying for the Geolocation API is:
${result.state}.`);
if (result.state === 'granted') {
  // Use the API.
}

Помогите пользователям выйти из заблокированного состояния

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

В Chrome пользователи должны перейти в Site Controls , нажав на значок «tune» в левой части адресной строки. Здесь они могут включить соответствующее разрешение. В некоторых случаях им может потребоваться перезагрузить страницу перед использованием возможности. В этом случае в верхней части окна появится панель сообщений, предлагающая перезагрузить страницу при нажатии соответствующей кнопки.

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