As solicitações de permissão são o principal mecanismo da Web para proteger recursos avançados que são potencialmente perigosos para a privacidade e segurança dos usuários. Com as solicitações de permissão, os navegadores garantem que o usuário possa 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 em estatísticas de uso e pesquisas de usuário do Chrome. Ao seguir essas práticas recomendadas, os usuários vão encontrar menos solicitações desnecessárias, fazendo com que os desenvolvedores recebam menos decisões de "bloqueio". O artigo termina com alguns padrões de código para trabalhar com APIs controladas por permissão e práticas recomendadas para ajudar os usuários a se recuperar de um estado bloqueado.
Práticas recomendadas de comando
Você precisa pedir permissão após uma interação com o usuário, assim ele pode entender por que está pedindo e qual é o benefício de permitir. Sempre que possível, permita que os usuários utilizem um meio alternativo para realizar a mesma funcionalidade. Como diretriz geral, pedir uma permissão com menos frequência, escolhendo os momentos em que você faz solicitações com cuidado, diminui as chances de os usuários entrarem em um estado bloqueado que seja difícil de recuperar. As práticas recomendadas a seguir oferecem mais detalhes sobre cada uma dessas sugestões.
Nunca perguntar no carregamento da página ou sem interação do usuário
Pedir permissão aos usuários no carregamento de página equivale a pedir ao cliente uma informação sensível enquanto ele entra em uma loja física. Ver uma solicitação de permissão (possivelmente entre várias outras solicitações de assinatura de newsletter e consentimento de cookies) é uma experiência muito desagradável. Os usuários não entenderão por que recebem essa pergunta e como se beneficiarão.
Mesmo que seu aplicativo da Web não possa funcionar sem acesso a um determinado recurso, você deve dar aos usuários uma chance de entender por que ele é necessário. Por exemplo, apresentar a solicitação de permissão no início de uma solicitação que explique a necessidade e ofereça aos usuários uma escolha (por exemplo, quando possível, fornecendo meios alternativos para realizar a mesma funcionalidade). Se você não consegue pensar em um momento melhor para pedir permissão do que no carregamento da página, há alguns exemplos mais adiante neste guia.
Uma situação similarmente 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 computadores são mostradas sem um indicador tão básico de intenção do usuário e, consequentemente, apenas 12% desses solicitações são permitidas. Após uma interação do usuário, as taxas de permissão aumentam para 30%. Portanto, só peça permissão depois que o usuário interagir com a página de algum formato.
Pergunte apenas quando os usuários entenderem por que você está pedindo isso
Muitas vezes, decisões sobre permissões são decisões relacionadas à 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 fundamental disso. Portanto, solicite apenas os recursos necessários para oferecer valor aos usuários (e quando eles provavelmente concordarem com você que eles realmente vão receber valor). Além disso, peça permissão assim que o usuário fique claro por que o recurso é útil. O objetivo é fazer com que seja o mais fácil possível para seus usuários entenderem o contexto de uso.
Nossa pesquisa de usuário mostra que os usuários têm uma probabilidade maior de permitir acesso quando entendem por que um site está solicitando acesso e também percebem um benefício. Também descobrimos que os usuários esperam explorar sites desconhecidos primeiro para entender melhor o valor que podem receber ao permitir o acesso. Eles geralmente dispensam ou ignoram solicitações de permissão nesse meio tempo. Com permissões únicas, eles podem permitir uma única visita primeiro. Seu aplicativo precisa oferecer suporte a esses comportamentos.
Fornecer meios alternativos para realizar a mesma funcionalidade sempre que possível.
O resultado de alguns recursos pode não ser útil para os usuários. Por exemplo, a geolocalização de um dispositivo desktop sem um sensor de GPS pode retornar o local errado porque essa pessoa está conectada a uma VPN. Outros usuários podem não querer fornecer acesso à área de transferência porque preferem permanecer no controle e acionar esses eventos com combinações de teclas manualmente. Em situações como essas, é importante fornecer meios alternativos para alcançar os mesmos resultados. Por exemplo, se você estiver solicitando 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, confira 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 o recebimento de e-mails em vez de notificações push.
Um padrão útil é usar a interface alternativa também como uma explicação do motivo pelo qual o acesso pode ser benéfico. Os usuários que veem a opção de inserir um local ao lado de um botão que aciona a API de geolocalização se sentirão no controle do que acontecerá, porque entendem que também podem simplesmente 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 entenderão melhor as compensações que estão fazendo.
Não entre em um estado bloqueado, é difícil se recuperar
Depois que o usuário decide não permitir permanentemente o acesso a um recurso com permissão, os navegadores respeitam essa decisão. Se fosse possível continuar solicitando acesso, sites mal-intencionados continuariam a bombardear os usuários com solicitações. Portanto, a recuperação do estado bloqueado de um recurso exige intencionalmente um pouco de esforço do usuário. Da mesma forma, evite pedir permissão aos usuários em situações em que é provável que muitos deles não permitam o acesso.
Uma maneira comum de fazer isso é usar um chamado pré-comando, em que você explica aos usuários o que está prestes a acontecer e por que seu aplicativo precisa do recurso que você vai solicitar. Acione a solicitação de permissão do navegador somente quando os usuários reagirem afirmativamente a essa pré-solicitação. Há situações em que os usuários podem precisar se recuperar desse estado. Consulte a seção Ajudar os usuários a se recuperarem de um estado bloqueado para saber mais sobre isso.
Prestar atenção ao conteúdo de terceiros
Há uma fonte inesperada de solicitações de permissão que você precisa conhecer. 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á descritas. Para manter o controle das experiências dos usuários, leia com atenção a documentação de quaisquer 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 "Usar meu local" ao lado de um campo de formulário para inserir um endereço manualmente.
- Depois que um usuário se inscreve em um canal de vídeo ou em postagens e clica em um botão afirmativo em uma caixa de diálogo descrevendo que as atualizações podem ser entregues como e-mails ou notificações para o smartphone ou computador.
- Depois que um usuário acessa uma página que o prepara para participar de uma videochamada e responde afirmando que ele quer ser visto e ouvido em um pré-comando (consulte este estudo de caso do Google Meet).
Padrões de código para pedir permissão
Conseguir permissão para usar uma API acontece de maneiras diferentes, dependendo
da API. Algumas APIs (normalmente mais antigas) usam um modelo em que o navegador solicita permissão automaticamente 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 é necessário solicitar explicitamente a permissão usando um método estático. Um bom exemplo é o
Notification.requestPermission(),
para permitir notificações, ou o método menos comum
DeviceOrientationEvent.requestPermission(),
que faz parte da API Device Orientation Events. Alguns navegadores podem
conceder permissões automaticamente a determinadas APIs. Por exemplo, o Chrome sempre permite
o acesso à orientação do 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.
}
Ajudar os usuários a se recuperar de um estado bloqueado
Para ajudar os usuários a resolver problemas de acesso, detecte se 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 interagirem com elementos da interface associados a um recurso controlado por permissões, 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 alterar o estado de permissão variam de acordo com o navegador. Por isso, talvez seja melhor oferecer descrições correspondentes com base na string do user agent e nos navegadores mais usados no seu produto.
No Chrome, os usuários devem acessar Controles do site clicando no ícone "ajustar" à esquerda da barra de endereço. Aqui, eles podem ativar a respectiva permissão. 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 atualizar quando você clicar no botão correspondente.
Existem interfaces semelhantes para controlar permissões em outros navegadores. Por exemplo, veja como isso funciona no Firefox.