Prácticas recomendadas sobre permisos web

Los mensajes de permiso son el mecanismo principal de la Web para proteger capacidades potentes que pueden ser peligrosas para la privacidad y la seguridad de los usuarios. Con las solicitudes de permiso, los navegadores tienen como objetivo garantizar que el usuario tenga la intención de permitir que el sitio web solicitante acceda a la función en cuestión. Los mensajes de permisos se usan para varias APIs, incluida la captura de contenido multimedia (cámara y micrófono), la ubicación geográfica, el acceso al almacenamiento, el MIDI y las notificaciones (consulta la documentación de la API de permisos en MDN para obtener más información).

En esta guía, se describen las prácticas recomendadas para mostrar mensajes de permiso a los usuarios según las investigaciones y las estadísticas de uso de Chrome. Si se siguen estas prácticas recomendadas, los usuarios deberían encontrar menos mensajes innecesarios, lo que llevaría a los desarrolladores a tomar menos decisiones de "bloqueo". El artículo finaliza con algunos patrones de código a fin de trabajar con APIs restringidas por permisos y prácticas recomendadas para ayudar a los usuarios a recuperarse de un estado bloqueado.

Prácticas recomendadas para las instrucciones

Debes pedir permiso después de una interacción con el usuario, en un momento en el que puedan comprender por qué lo preguntas y qué beneficios obtendrán si lo permiten. Siempre que sea posible, debes permitir que los usuarios utilicen un medio alternativo para lograr la misma funcionalidad. Como lineamiento general, solicitar permiso con menor frecuencia y elegir los momentos en los que lo solicitas con cuidado reduce las posibilidades de que los usuarios se encuentren bloqueados y sea difícil recuperarse de ellos. Las siguientes prácticas recomendadas ofrecen más detalles sobre cada una de estas sugerencias.

Nunca preguntar durante la carga de la página o sin interacción del usuario

Pedir permiso a los usuarios cuando se carga la página equivale a pedirle a un cliente información sensible cuando entra en una tienda física. Ver una solicitud de permiso (posiblemente entre varias otras solicitudes para registrarse en un boletín informativo y el consentimiento de uso de cookies) es una experiencia muy molesta. Los usuarios no comprenderán por qué se les pregunta y cómo se beneficiarán.

Incluso si tu aplicación web no puede funcionar sin acceso a una función determinada, debes darles a los usuarios la oportunidad de comprender por qué es necesaria. Por ejemplo, si antepones la solicitud de permiso con una solicitud propia que explique la necesidad y les brindes a los usuarios la opción de elegir (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 durante la carga de la página, hay algunos ejemplos más adelante en esta guía.

Una situación mala similar 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 los mensajes de permisos en Chrome para computadoras de escritorio se muestran sin un indicador tan básico de intención del usuario y, por lo tanto, solo el 12% de esos mensajes se permite. Después de una interacción con el usuario, las tasas de permisos aumentan al 30%. Por lo tanto, solicita permiso solo después de que el usuario haya interactuado con la página de alguna manera.

Preguntar solo cuando los usuarios comprendan por qué lo haces

Las decisiones de permisos suelen ser decisiones de privacidad. Según el marco de trabajo de integridad contextual, sabemos que las decisiones de privacidad son muy contextuales. Comprender por qué es necesario un acceso puede considerarse un aspecto clave de esto. Por lo tanto, solo debes solicitar las capacidades que necesitas para proporcionar valor a los usuarios (y en las que es probable que los usuarios estén de acuerdo contigo en que, de hecho, obtendrán valor). Además, debes solicitar permiso en un momento en el que el usuario pueda ver por qué la función es útil. El objetivo es hacer que los usuarios puedan comprender el contexto de uso de la manera más sencilla posible.

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

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

El resultado de algunas capacidades puede no ser útil para los usuarios. Por ejemplo, la ubicación geográfica de un dispositivo de escritorio sin sensor GPS podría mostrar la ubicación incorrecta porque esa 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 deseas copiar 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 activa la API de ubicación geográfica sentirán que tienen el control de lo que sucederá, ya que entienden que también pueden simplemente escribir su dirección. Del mismo modo, si se puede elegir 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 comprenderán más naturalmente las compensaciones que están haciendo.

No entres en un estado bloqueado, es difícil recuperarte

Una vez que un usuario decide no permitir de forma permanente el acceso a una función con permisos, los navegadores respetan esa decisión. Si fuera posible seguir solicitando acceso, los sitios malintencionados continuarían bombardeando a los usuarios con mensajes. Por lo tanto, la recuperación del estado bloqueado de una capacidad requiere un poco de esfuerzo por parte del usuario de manera intencional. Por lo tanto, evita pedirles permiso a los usuarios en situaciones en las que sea probable que muchos de ellos no permitan el acceso.

Una forma común de hacerlo es usar una instrucción previa, en la que les explicas a los usuarios lo que está por suceder y por qué tu aplicación necesita la capacidad que vas a solicitar. Solo cuando los usuarios reaccionen afirmativamente a esta solicitud previa, deberás activar la solicitud de permiso del navegador. Hay situaciones en las que los usuarios pueden de verdad necesitar recuperarse de ese estado. Para obtener más información al respecto, consulta la sección Cómo ayudar a los usuarios a recuperarse de un estado de bloqueo.

Presta atención al contenido de terceros

Existe una fuente inesperada de solicitudes de permisos que se deben tener en cuenta. Si incluyes secuencias de comandos de terceros en tu sitio, es posible que activen solicitudes de permisos que no querías mostrar. Esto puede afectar la experiencia de los usuarios en tu sitio web, en especial si esas instrucciones no siguen las prácticas recomendadas que ya se describieron. Para mantener el control de las experiencias de los usuarios, debes leer con atención 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 puedes solicitar permiso según las prácticas recomendadas que ya se describieron:

  • Cuando un usuario hace clic en el botón "Usar mi ubicación" junto a un campo de formulario para ingresar una dirección manualmente
  • Después de que un usuario se suscribió a un canal o publicaciones de videos y hace clic en un botón afirmativo en un diálogo en el que se describe que las actualizaciones pueden entregarse como correos electrónicos o notificaciones a su teléfono o computadora.
  • Cuando un usuario llega a una página que lo prepara para unirse a una videollamada y responde afirmativamente que quiere que lo vean y lo escuchen con un mensaje previo (consulta este caso de éxito de Google Meet).

Patrones de código para solicitar permiso

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 automáticamente permiso 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 necesitas solicitar permiso de forma explícita con un método estático. Un buen ejemplo es Notification.requestPermission() para permitir notificaciones, o el DeviceOrientationEvent.requestPermission() menos común, que forma parte de la API de Device Orientation Events. Ten en cuenta que algunos navegadores pueden otorgar permiso automáticamente a determinadas APIs. Por ejemplo, Chrome siempre permite el acceso a la orientación del dispositivo, mientras que Safari muestra una instrucción.

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 comprobar 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

  • 43
  • 79
  • 46
  • 16

Origen

Cómo ayudar a los usuarios a recuperarse de un estado bloqueado

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

En Chrome, los usuarios deben ir a Controles del sitio. Para ello, deben hacer clic en el ícono de ajustar en el lado izquierdo de la barra de direcciones. Aquí, pueden activar el permiso respectivo. En algunos casos, es posible que tengan que volver a cargar la página antes de usar esta función. En ese caso, aparecerá una barra de mensajes en la parte superior de la ventana que ofrece volver a cargar la página cuando se hace clic en el botón correspondiente.

Controles de sitios en el navegador Chrome

Un mensaje para volver a cargar la página después de cambiar los permisos con los controles de sitios

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