Summary

  • Saber que a bateria está baixa permite ao aplicativo consultar menos o servidor ou salvar um documento antes do desligamento.
  • Leituras detalhadas de carga e tempo também podem diferenciar um aparelho. Os registros do W3C mostram a preocupação chegando ao trabalho normativo e moldando recomendações sobre precisão, permissão, valores ofuscados e acesso de páginas incorporadas.

Uma caixa de entrada que pergunta ao servidor por mensagens novas a cada poucos segundos enquanto o notebook perde energia parece um visitante que toca a campainha sem parar. Um editor que salva o documento antes do apagão tem modos melhores. A proposta do W3C de 2016 apresenta esses dois exemplos. O navegador forneceria uma pista sobre energia; o aplicativo decidiria trabalhar menos ou proteger o trabalho feito. O propósito era pequeno e útil.

No primeiro rascunho público, de abril de 2011, a informação vinha como evento retirado de uma API maior de informações do sistema. A proposta considerava se o aparelho usava bateria, se carregava, nível entre zero e cem e tempo restante em segundos. O grupo ainda buscava casos fortes para alguns campos. Um exemplo apenas registrava o nível. Era um desenho anterior ao posterior getBattery(): o mostrador já estava sobre a mesa, mas o direito de cada site a ler suas marcas ainda precisava de discussão.

Uma leitura bastante fina para orientar tarefas também pode descrever o visitante. Nível, condição de carregamento e tempo estimado formam um perfil que se move conforme o uso. A página não precisa abrir fotos ou contatos para conhecer uma característica do equipamento. Basta observar um instrumento aparentemente banal. O medidor posto ali para economizar recursos também passou a oferecer uma pista a quem deseja reconhecer a máquina.

Em um e-mail do grupo de trabalho do W3C, em julho de 2015, Frederick Hirsch encaminhou recomendações ligadas a pesquisa original sobre privacidade: registrar o risco de impressão digital por leituras muito precisas, considerar permissão e tornar o uso da API visível. O documento mostra que o tema entrou na conversa de quem escrevia o padrão. Não oferece uma contagem de sites que perseguiram usuários com a carga da bateria, nem precisa oferecer para justificar a pergunta.

A Proposed Recommendation de março de 2016 aconselha evitar precisão alta e permite pedir autorização ou embaralhar o valor entregue. navigator.getBattery() fornece um BatteryManager com carga, nível e tempos de carregamento e descarga. Se o navegador não puder relatar o estado real, os valores padrão parecem uma bateria cheia e ligada à tomada. Isso também impede que um site reduza a qualidade do serviço apenas porque o navegador guardou o medidor para si. O verde do ícone pode ser uma cortina, não a festa da bateria.

No rascunho de outubro de 2024, getBattery() aparece em contexto seguro. A Permissions Policy da função battery permite por padrão 'self'; um documento sem acesso recebe NotAllowedError. O alerta sobre leituras muito precisas permanece. O navegador pode perguntar, ofuscar ou impedir. Um webmail não precisa receber a história segundo a segundo do acumulador para deixar de ser inconveniente.

O histórico de publicações do W3C passa pelos rascunhos de 2011, pelos textos de 2016 e pelas revisões de 2024. Essas datas pertencem ao processo da especificação, não a uma adoção simultânea em todos os navegadores. A lição é mais duradoura: um pequeno sinal de economia de energia, quando detalhado demais, vira uma forma de apresentar o visitante à página.

O aplicativo ainda pode salvar o texto e espaçar consultas. Para fazer isso com educação, não precisa narrar o último fôlego da bateria.