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

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 пользователи должны перейти к элементам управления сайтом , щелкнув значок «настройка» в левой части адресной строки. Здесь они могут включить соответствующее разрешение. В некоторых случаях им, возможно, придется перезагрузить страницу, прежде чем использовать эту возможность. В этом случае в верхней части окна появится панель сообщений, предлагающая перезагрузку при нажатии соответствующей кнопки.

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