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

Marian Harbach

Thomas Steiner

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

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

В заключение этого документа приводятся некоторые шаблоны кода для API с ограниченным доступом и способы оказания помощи пользователям в восстановлении после блокировки .

Содействие внедрению передовых методов

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

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

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

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

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

Запрос разрешения без предварительного взаимодействия с пользователем также неэффективен. Это называется временной активацией пользователя . Телеметрия Chrome показывает, что 77% запросов на разрешение на настольных компьютерах отображаются без сигнала о намерении пользователя, и, следовательно, разрешается только 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 .