Práticas recomendadas de permissões da Web

As solicitações de permissão são o principal mecanismo da Web para proteger recursos poderosos que são potencialmente perigosos para a privacidade e a segurança dos usuários. Com as solicitações de permissão, os navegadores têm como objetivo garantir que o usuário queira permitir que o site solicitante acesse o recurso em questão. As solicitações de permissão são usadas para várias APIs, incluindo captura de mídia (câmera e microfone), geolocalização, acesso ao armazenamento, MIDI e notificações. Consulte a documentação da API Permissions no MDN para mais informações.

Este guia descreve as práticas recomendadas para mostrar solicitações de permissão aos usuários com base nas estatísticas de uso do Chrome e na pesquisa de usuários. Ao seguir essas práticas recomendadas, os usuários vão encontrar menos solicitações desnecessárias, o que vai fazer com que os desenvolvedores tomem menos decisões de "bloqueio". O artigo termina com alguns padrões de código para trabalhar com APIs com permissão e práticas recomendadas para ajudar os usuários a sair de um estado bloqueado.

Práticas recomendadas para a solicitação

Você precisa pedir permissão após uma interação do usuário, em um momento em que os usuários possam entender por que você está pedindo e qual benefício eles vão receber ao permitir. Sempre que possível, permita que os usuários usem um meio alternativo para alcançar a mesma funcionalidade. Como regra geral, pedir permissão com menos frequência escolhendo os momentos em que você pede com cuidado reduz as chances de os usuários ficarem em um estado bloqueado difícil de recuperar. As práticas recomendadas a seguir oferecem mais detalhes sobre cada uma dessas sugestões.

Nunca pergunte no carregamento da página ou sem interação do usuário

Pedir permissão aos usuários no carregamento da página é equivalente a pedir uma informação sensível a um cliente quando ele entra em uma loja física. Ver uma permissão (talvez entre várias outras para inscrição em newsletter e consentimento de cookies) é uma experiência muito desagradável. Os usuários não vão entender por que estão sendo solicitados e como vão se beneficiar.

Mesmo que seu aplicativo da Web não funcione sem acesso a um determinado recurso, dê aos usuários a chance de entender por que ele é necessário. Por exemplo, coloque uma mensagem sua antes da solicitação de permissão que explique a necessidade e dê aos usuários uma escolha. Por exemplo, sempre que possível, forneça meios alternativos para realizar a mesma funcionalidade. Se você não conseguir pensar em um momento melhor para pedir permissão do que no carregamento da página, há alguns exemplos mais adiante neste guia.

Outra situação ruim para pedir permissão é sem uma interação anterior do usuário (também conhecida como ativação temporária do usuário). A telemetria do Chrome mostra que 77% das solicitações de permissão no Chrome para computador são mostradas sem um indicador muito básico da intenção do usuário. Consequentemente, apenas 12% dessas solicitações são permitidas. Após uma interação do usuário, permita que as taxas aumentem para 30%. Portanto, só peça permissão depois que o usuário interagir com a página de alguma forma.

Só faça perguntas quando os usuários entenderem por que você está perguntando

As decisões de permissão geralmente são decisões de privacidade. Com base no framework de integridade contextual, sabemos que as decisões de privacidade são altamente contextuais. Entender por que um acesso é necessário pode ser considerado um aspecto importante disso. Portanto, solicite apenas os recursos necessários para oferecer valor aos usuários (e em que os usuários provavelmente concordarão que vão receber valor). Além disso, peça a permissão em um momento em que fique claro para o usuário por que o recurso é útil. O objetivo é facilitar ao máximo que os usuários entendam o contexto de uso.

Nossa pesquisa de usuários mostra que os usuários têm muito mais chances de permitir o acesso quando entendem por que um site está pedindo acesso e também percebem um benefício. Também encontramos que os usuários esperam conhecer primeiro os sites desconhecidos para entender melhor o valor que podem receber em troca do acesso. Eles geralmente dispensam ou ignoram solicitações de permissão nesse meio tempo. Com permissões únicas, elas podem permitir uma única visita primeiro. O aplicativo precisa oferecer suporte a esses comportamentos.

Oferecer meios alternativos para alcançar a mesma funcionalidade, quando possível

O resultado de alguns recursos pode não ser útil para os usuários. Por exemplo, a geolocalização de um dispositivo de computador sem um sensor de GPS pode retornar o local errado porque a pessoa está conectada a uma VPN. Outros usuários podem não querer fornecer acesso à área de transferência porque preferem manter o controle e acionar esses eventos manualmente com combinações de teclas. Em situações como essas, é importante oferecer uma alternativa para alcançar os mesmos resultados. Por exemplo, se você estiver solicitando a permissão de geolocalização, ofereça um campo de texto em que os usuários possam inserir um CEP ou endereço. Com a área de transferência, verifique se os elementos a serem copiados também podem ser selecionados e copiados por uma combinação de teclas ou pelo menu de contexto. Com as notificações, ofereça a opção de receber e-mails em vez de notificações push.

Um padrão útil é usar a interface alternativa também como a explicação de por que o acesso pode ser benéfico. Os usuários que tiverem a opção de inserir um local ao lado de um botão que aciona a API de geolocalização vão se sentir no controle do que vai acontecer, porque entendem que também podem digitar o endereço. Da mesma forma, se houver uma escolha entre receber notificações por push ou e-mail ou participar de uma reunião sem permitir o acesso à câmera e ao microfone, os usuários vão entender de forma mais natural as trocas que estão fazendo.

Não se deixe entrar em um estado bloqueado, é difícil se recuperar

Depois que um usuário decide não permitir o acesso permanente a um recurso com permissão restringida, os navegadores respeitam essa decisão. Se fosse possível continuar solicitando o acesso, sites mal-intencionados continuariam bombardeando os usuários com solicitações. Portanto, a recuperação do estado bloqueado de um capability exige um pouco de esforço do usuário. Portanto, evite pedir permissão aos usuários em situações em que muitos deles provavelmente não vão permitir o acesso.

Uma maneira comum de fazer isso é usar um pré-prompt, em que você explica aos usuários o que está prestes a acontecer e por que o app precisa da capacidade que você vai solicitar. Só quando os usuários reagirem afirmativamente a esse pré-prompt, você poderá acionar a solicitação de permissão do navegador. Há situações em que os usuários podem precisar se recuperar desse estado. Consulte a seção Ajudar os usuários a se recuperar de um estado bloqueado para mais informações.

Preste atenção ao conteúdo de terceiros

Há uma origem inesperada de solicitações de permissão. Se você incluir scripts de terceiros no seu site, eles poderão acionar solicitações de permissão que você não pretendia mostrar. Isso pode afetar a experiência dos usuários no seu site, especialmente se essas solicitações não seguirem as práticas recomendadas já detalhados. Para manter o controle das experiências dos usuários, leia com atenção a documentação de todas as bibliotecas e scripts de terceiros que você adicionar ao seu código.

Quando pedir permissão

Confira alguns exemplos de momentos que funcionam bem para pedir permissão, seguindo as práticas recomendadas já descritas:

  • Depois que um usuário clica em um botão que diz "Usar meu local" ao lado de um campo de formulário para inserir um endereço manualmente.
  • Depois que um usuário se inscreveu em um canal de vídeo ou postagens e clicou em um botão de confirmação em uma caixa de diálogo que descreve que as atualizações podem ser enviadas como e-mails ou notificações para o smartphone ou computador.
  • Depois que um usuário chega a uma página que o prepara para participar de uma videochamada e responde afirmativamente que quer ser visto e ouvido em uma solicitação prévia (consulte este estudo de caso do Google Meet).

Padrões de código para solicitar permissão

A permissão para usar uma API é concedida de maneiras diferentes, dependendo da API. Algumas APIs (geralmente mais antigas) usam um modelo em que o navegador solicita automaticamente a permissão na primeira vez que você tenta usar a API. Um exemplo é a API Geolocation ao chamar navigator.geolocation.getCurrentPosition().

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

Outras APIs usam um modelo em que você precisa solicitar explicitamente a permissão primeiro usando um método estático. Um bom exemplo é Notification.requestPermission() para permitir notificações ou o menos comum DeviceOrientationEvent.requestPermission(), que faz parte da API Device Orientation Events. Alguns navegadores podem conceder permissão automaticamente para determinadas APIs. Por exemplo, o Chrome sempre permite o acesso à orientação de um dispositivo, enquanto o Safari mostra uma solicitação.

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. */
}

Como verificar o estado das permissões

Para verificar se você pode usar uma determinada API, use o método navigator.permissions.query() da API Permissions.

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.
}

Compatibilidade com navegadores

  • Chrome: 43.
  • Edge: 79.
  • Firefox: 46.
  • Safari: 16.

Origem

Ajudar os usuários a sair de um estado bloqueado

Para ajudar os usuários a resolver problemas de acesso, detecte que eles bloquearam o acesso usando a API Permissions e ofereça um guia sobre como mudar as configurações. Por exemplo, quando os usuários interagem com elementos da interface associados a um recurso com permissão, use o padrão descrito na seção anterior e abra uma caixa de diálogo de solução de problemas. As etapas exatas para mudar o estado da permissão variam de acordo com o navegador. Por isso, ofereça descrições correspondentes com base na string do user agent e nos navegadores mais usados no seu produto.

No Chrome, os usuários precisam acessar os Controles do site clicando no ícone "sintonizar" no lado esquerdo da barra de endereço. Aqui, eles podem ativar a permissão respectiva. Em alguns casos, pode ser necessário recarregar a página antes de usar o recurso. Nesse caso, uma barra de mensagens vai aparecer na parte de cima da janela e oferecer a opção de recarregar ao clicar no botão correspondente.

Controles de site no navegador Chrome.

Uma solicitação de recarga após a mudança de permissões usando os controles do site.

Há interfaces semelhantes para controlar permissões em outros navegadores (por exemplo, veja como isso funciona no Firefox).