Summary

  • Saber que queda poca batería permite a una aplicación reducir consultas al servidor o guardar un documento antes de que el equipo se apague.
  • Lecturas muy precisas del nivel y del tiempo restante pueden contribuir a identificar un aparato. Los documentos del W3C muestran cómo esa inquietud entró en la norma y llevó a hablar de precisión, permiso, valores difusos y límites para páginas incrustadas.

Una bandeja de entrada que consulta el servidor cada pocos segundos mientras el portátil agoniza se parece a un invitado que no deja de llamar al timbre. Un editor que guarda el texto antes del apagón se parece más a un amigo. El texto del W3C de 2016 ofrece esos ejemplos. La idea era que el navegador comunicara el estado de energía y que la aplicación ajustara su trabajo. No hacía falta convertir cada página en ingeniera eléctrica para salvar un párrafo.

El primer borrador público, de abril de 2011, extraía los eventos de batería de una API más amplia sobre el sistema. Planteaba si se usaba batería, si estaba cargando, un nivel de cero a cien y una estimación en segundos. El propio grupo todavía buscaba buenas razones para algunos campos. Un ejemplo registraba el nivel en la consola. Era una propuesta de eventos, anterior a la forma posterior de getBattery(). Habían puesto la aguja sobre la mesa sin decidir cuánto debía poder verla cualquier web.

La utilidad tenía una sombra. Nivel, indicador de carga y tiempo restante pueden combinarse en un perfil que cambia con el uso del aparato. La misma exactitud que ayuda a planificar una tarea da pistas para distinguir a un visitante. La web no tiene que leer archivos privados para aprender algo sobre la máquina. Le basta con observar un medidor que parece inocente porque aparece en todos los portátiles.

En julio de 2015, un mensaje del grupo de trabajo del W3C puso la cuestión en palabras precisas. Su presidente Frederick Hirsch trasladó propuestas derivadas de investigación original: advertir del riesgo de identificación por lecturas de alta precisión, considerar permisos y mostrar al usuario cuándo se usa la API. El registro documenta una discusión técnica concreta. No convierte la posibilidad de identificación en una estadística inventada sobre todos los sitios del mundo.

La Proposed Recommendation de marzo de 2016 aconsejó evitar lecturas demasiado finas y permitió al navegador pedir autorización u ocultar parte del valor. navigator.getBattery() devuelve un BatteryManager con nivel, carga y tiempos estimados. Si el navegador no puede informar del estado real, los valores predeterminados simulan una batería llena y enchufada. Así, un sitio no obtiene una excusa para castigar al usuario porque su navegador guarda silencio. A veces el verde del indicador es una cortina, no una celebración.

El borrador de octubre de 2024 añadió una frontera más visible: getBattery() pertenece a un contexto seguro. La función battery de Permissions Policy permite por defecto 'self'; un documento sin autorización recibe NotAllowedError. Sigue presente la advertencia contra la precisión excesiva. El navegador conserva opciones para preguntar, difuminar o bloquear. La página puede ser considerada con la energía sin recibir un parte médico segundo a segundo del acumulador.

El historial de publicaciones del W3C recorre los borradores desde 2011, el trabajo de 2016 y las revisiones de 2024. Es un calendario de textos, no de adopción idéntica en cada navegador. La lección perdura: una pista para ahorrar batería también puede ser una etiqueta para reconocer al visitante si la aguja dibuja líneas demasiado finas.

El correo aún puede consultar menos. El editor aún puede guardar. Ninguna de esas cortesías exige contar las últimas respiraciones de la batería.