Prácticas recomendadas sobre permisos web

Las solicitudes de permisos son el mecanismo principal de la Web para proteger funciones potentes que pueden ser potencialmente peligrosas para la privacidad y la seguridad de los usuarios. Con los mensajes de permiso, los navegadores buscan garantizar que un usuario tenga la intención de permitir que el sitio web solicitante acceda a la función en cuestión. Las solicitudes de permisos se usan para una serie de APIs, como la captura de contenido multimedia (cámara y micrófono), la geolocalización, el acceso al almacenamiento, MIDI y las notificaciones (consulta la documentación de la API de Permissions en MDN para obtener más información).

En esta guía, se describen las prácticas recomendadas para mostrar solicitudes de permisos a los usuarios según las estadísticas de uso de Chrome y la investigación sobre usuarios. Cuando se siguen estas prácticas recomendadas, los usuarios deberían encontrar menos mensajes innecesarios, lo que lleva a que los desarrolladores tomen menos decisiones de "bloqueo". El artículo termina con algunos patrones de código para trabajar con APIs con control de acceso por permisos y prácticas recomendadas para ayudar a los usuarios a recuperarse de un estado bloqueado.

Sugiere prácticas recomendadas

Debes solicitar el permiso después de una interacción del usuario, en un momento en el que los usuarios puedan comprender por qué lo solicitas y qué beneficio obtendrán si lo permiten. Siempre que sea posible, debes permitir que los usuarios usen un medio alternativo para lograr la misma funcionalidad. Como lineamiento general, solicitar permisos con menos frecuencia eligiendo los momentos en los que los solicitas con cuidado reduce las probabilidades de que tus usuarios entren en un estado bloqueado del que sea difícil recuperarse. Las siguientes prácticas recomendadas ofrecen más detalles sobre cada una de estas sugerencias.

Nunca solicites permiso durante la carga de la página o sin interacción del usuario.

Solicitar permiso a los usuarios cuando se carga la página equivale a pedirle a un cliente información sensible cuando entra a una tienda física. Ver un mensaje de permiso (posiblemente entre varios otros mensajes para registrarse en el boletín informativo y dar consentimiento para las cookies) es una experiencia muy discordante. Los usuarios no comprenderán por qué se les solicita y qué beneficios obtendrán.

Incluso si tu aplicación web no puede funcionar sin acceso a una determinada función, debes darles a los usuarios la oportunidad de comprender por qué es necesaria. Por ejemplo, puedes anteponer el mensaje de permiso con uno propio que explique la necesidad y les dé a los usuarios una opción (por ejemplo, cuando sea posible, proporcionando medios alternativos para lograr la misma funcionalidad). Si no se te ocurre un mejor momento para solicitar permiso que cuando se carga la página, hay algunos ejemplos más adelante en esta guía.

Una situación similarmente mala para solicitar permiso es sin una interacción previa del usuario (también conocida como activación transitoria del usuario). La telemetría de Chrome muestra que el 77% de las solicitudes de permisos en Chrome para computadoras de escritorio se muestran sin una señal tan básica de la intención del usuario y, en consecuencia, solo se permite el 12% de esas solicitudes. Después de una interacción del usuario, permite que las tasas aumenten al 30%. Por lo tanto, solo solicita permiso después de que el usuario haya interactuado con la página de alguna forma.

Haz preguntas solo cuando los usuarios puedan entender por qué las haces.

Las decisiones sobre los permisos suelen ser decisiones de privacidad. En función del marco de trabajo de integridad contextual, sabemos que las decisiones de privacidad son altamente contextuales. Comprender por qué es necesario un acceso puede considerarse un aspecto clave de esto. Por lo tanto, solo debes solicitar las funciones que necesitas para proporcionarles valor a los usuarios (y en las que es probable que los usuarios estén de acuerdo contigo en que realmente obtendrán valor). Además, debes solicitar el permiso en un momento en el que sea evidente para el usuario por qué la función es útil. El objetivo es que los usuarios puedan comprender el contexto de uso de la forma más fácil posible.

Nuestra investigación sobre usuarios muestra que es mucho más probable que los usuarios permitan el acceso cuando comprenden por qué un sitio solicita acceso y también perciben un beneficio. También descubrimos que los usuarios esperan explorar primero sitios desconocidos para comprender mejor el valor que pueden obtener a cambio de permitir el acceso. Mientras tanto, a menudo descartarán o ignorarán las solicitudes de permisos. Con los permisos únicos, es posible que primero permitan una sola visita. Tu aplicación debe admitir estos comportamientos.

Proporcionar medios alternativos para lograr la misma funcionalidad siempre que sea posible

Es posible que el resultado de algunas funciones no sea útil para los usuarios. Por ejemplo, la geolocalización de un dispositivo de escritorio sin un sensor de GPS puede mostrar una ubicación incorrecta porque la persona está conectada a una VPN. Es posible que otros usuarios no quieran proporcionar acceso al portapapeles porque prefieren mantener el control y activar estos eventos con combinaciones de teclas de forma manual. En situaciones como estas, es importante proporcionar un medio alternativo para lograr los mismos resultados. Por ejemplo, si solicitas permiso de ubicación geográfica, ofrece un campo de texto en el que los usuarios puedan ingresar un código postal o una dirección. Con el portapapeles, asegúrate de que los elementos que se copiarán también se puedan seleccionar y copiar a través de una combinación de teclas o el menú contextual. Con las notificaciones, ofrece que las personas reciban correos electrónicos en lugar de notificaciones push.

Un patrón útil es usar la IU alternativa también como explicación de por qué el acceso podría ser beneficioso. Los usuarios que vean una opción para ingresar una ubicación junto a un botón que active la API de ubicación geográfica sentirán que tienen el control de lo que sucederá, ya que comprenden que también pueden escribir su dirección. Del mismo modo, si hay una opción entre recibir notificaciones a través de notificaciones push o por correo electrónico, o unirse a una reunión sin permitir el acceso a la cámara y al micrófono, los usuarios comprenden de forma más natural las compensaciones que están haciendo.

No te bloquees, ya que es difícil recuperarse de esta situación.

Una vez que un usuario decide no permitir de forma permanente el acceso a una función con control de permisos, los navegadores respetan esa decisión. Si fuera posible seguir solicitando acceso, los sitios con intenciones maliciosas seguirían bombardeando a los usuarios con solicitudes. Por lo tanto, recuperarse del estado bloqueado de una capability requiere un poco de esfuerzo por parte del usuario. Por lo tanto, evita solicitarles permiso a los usuarios en situaciones en las que es probable que muchos no permitan el acceso.

Una forma común de hacerlo es usar un llamado mensaje previo, en el que les explicas a los usuarios lo que sucederá y por qué tu aplicación necesita la función que solicitarás. Solo cuando los usuarios reaccionen de forma afirmativa a una solicitud previa, debes activar el mensaje de permiso del navegador. Hay situaciones en las que los usuarios pueden necesitar recuperarse de ese estado de forma legítima. Consulta la sección Ayuda a los usuarios a recuperarse de un estado bloqueado para obtener más información.

Presta atención al contenido de terceros

Hay una fuente inesperada de solicitudes de permisos que debes tener en cuenta. Si incluyes secuencias de comandos de terceros en tu sitio, es posible que activen mensajes de permiso que no tenías la intención de mostrar. Esto puede afectar la experiencia de los usuarios en tu sitio web, en especial, si esas indicaciones no siguen las prácticas recomendadas que ya se describieron. Para mantener el control de las experiencias de tus usuarios, debes leer con cuidado la documentación de las bibliotecas y secuencias de comandos de terceros que agregues a tu propio código.

Cuándo solicitar permiso

Estos son algunos ejemplos de momentos en los que es conveniente solicitar permiso, siguiendo las prácticas recomendadas que ya se describieron:

  • Después de que un usuario hace clic en un botón que dice "Usar mi ubicación" junto a un campo de formulario para ingresar una dirección de forma manual.
  • Después de que un usuario se suscribe a un canal de video o a publicaciones, y hace clic en un botón positivo en un diálogo que describe que las actualizaciones se pueden entregar como correos electrónicos o notificaciones a su teléfono o computadora de escritorio.
  • Después de que un usuario llega a una página que lo prepara para unirse a una videollamada y responde afirmativamente que quiere que lo vean y escuchen en una instrucción previa (consulta este caso de éxito de Google Meet).

Patrones de código para solicitar permisos

Obtener permiso para usar una API se realiza a través de diferentes medios, según la API. Algunas APIs (por lo general, más antiguas) usan un modelo en el que el navegador solicita permiso automáticamente la primera vez que intentas usar la API. Un ejemplo es la API de Geolocation cuando se llama a navigator.geolocation.getCurrentPosition().

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

Otras APIs usan un modelo en el que primero debes solicitar el permiso de forma explícita con un método estático. Un buen ejemplo es Notification.requestPermission() para permitir notificaciones, o el menos común DeviceOrientationEvent.requestPermission(), que forma parte de la API de Device Orientation Events. Ten en cuenta que algunos navegadores pueden otorgar permisos automáticamente a determinadas APIs. Por ejemplo, Chrome siempre permite el acceso a la orientación de un dispositivo, mientras que Safari muestra un mensaje.

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

Cómo verificar el estado de los permisos

Para verificar si puedes usar una API determinada, usa el método navigator.permissions.query() de la API de 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.
}

Navegadores compatibles

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

Origen

Ayuda a los usuarios a recuperarse de un estado bloqueado

Para ayudar a los usuarios a solucionar problemas de acceso, detecta que bloquearon el acceso con la API de Permissions y ofréceles una guía sobre cómo cambiar la configuración. Por ejemplo, cuando los usuarios interactúan con elementos de la IU asociados con una función con control de permisos, usa el patrón que se describe en la sección anterior y abre un diálogo de solución de problemas. Los pasos exactos para cambiar el estado de los permisos varían según el navegador, por lo que te recomendamos que ofrezcas descripciones coincidentes según la cadena de usuario-agente y para los navegadores más utilizados en tu producto.

En Chrome, los usuarios deben ir a Controles de sitios haciendo clic en el ícono de "ajuste" que se encuentra en el lado izquierdo de la barra de direcciones. Aquí, puede activar el permiso correspondiente. En algunos casos, es posible que deban volver a cargar la página antes de usar la función. En ese caso, aparecerá una barra de mensajes en la parte superior de la ventana que ofrecerá volver a cargar la página cuando hagas clic en el botón correspondiente.

Controles de sitios en el navegador Chrome.

Mensaje de recarga después de cambiar los permisos con los controles del sitio

Existen IU similares para controlar los permisos en otros navegadores (por ejemplo, consulta cómo funciona en Firefox).