Summary

  • Mit dem Akkustand kann eine Webanwendung ihre Arbeit anpassen: E-Mails seltener abrufen oder ein Dokument vor dem Abschalten speichern.
  • Sehr genaue Werte für Ladung und Restlaufzeit können ein Gerät unterscheidbar machen. W3C-Unterlagen zeigen, wie der Datenschutzaspekt in die Standardarbeit gelangte und zu Grenzen bei Genauigkeit, Berechtigung und Zugriff führte.

Ein Postfach, das bei fast leerem Akku alle paar Sekunden den Server belästigt, ist kein besonders taktvoller Mitbewohner. Ein Schreibprogramm, das den letzten Absatz rettet, benimmt sich besser. Der W3C-Text von 2016 nennt genau diese Beispiele. Der Browser liefert einen Hinweis zur Stromversorgung; die Anwendung entscheidet, ob sie weniger tut oder rechtzeitig speichert. Der Akku möchte Ruhe, der Autor sein Manuskript. Beides kann stimmen.

Der erste öffentliche Entwurf vom April 2011 sah noch ein Ereignis vor, herausgelöst aus einer größeren System Information API. Vorgeschlagen wurden Batteriebetrieb, Ladezustand, ein Wert von null bis hundert und eine Restzeit in Sekunden. Für einige Felder suchte die Arbeitsgruppe noch nach überzeugenden Einsatzfällen. Das Beispiel protokollierte schlicht den Pegel. Es war noch nicht die spätere getBattery()-Form. Die Messskala lag schon auf dem Tisch; wie genau jede Webseite hinschauen durfte, blieb offen.

Genauigkeit hat zwei Kunden. Für die Anwendung macht sie Entscheidungen leichter. Für eine neugierige Seite liefert sie Eigenschaften eines Besuchers: Ladestand, Ladevorgang und eine sich verändernde Zeitschätzung können zusammen eine kleine, bewegliche Kontur des Geräts bilden. Dazu muss niemand die Kontakte auslesen. Das scheinbar harmlose Instrument erzählt genug über den Rechner, um eine Frage nach Wiedererkennung auszulösen.

In einer W3C-Arbeitsgruppenmail vom Juli 2015 gab Vorsitzender Frederick Hirsch konkrete Vorschläge aus ursprünglicher Datenschutzforschung weiter: das Risiko hochpräziser Werte als Fingerprinting-Oberfläche benennen, eine Erlaubnis erwägen und die Nutzung sichtbar machen. Die Mail belegt eine fachliche Debatte über den Standard. Sie behauptet keine erfundene Statistik über Webseiten, die jeden Besucher am Akku verfolgt hätten. Die Möglichkeit war bereits ernst genug, um die Schnittstelle zu überdenken.

Die Proposed Recommendation von März 2016 empfiehlt, zu präzise Werte zu vermeiden; Browser können nach Erlaubnis fragen oder Angaben verschleiern. navigator.getBattery() liefert einen BatteryManager mit Ladezustand, Pegel und Zeiten bis zum Laden oder Entladen. Kann der Browser den echten Zustand nicht melden, sehen die Vorgaben wie „voll und angeschlossen“ aus. So darf eine Seite aus verschwiegenen Messwerten keinen Grund ableiten, den Nutzer schlechter zu bedienen. Die grüne Anzeige kann ein Vorhang sein, keine Erfolgsmeldung des Akkus.

Im W3C-Entwurf vom Oktober 2024 setzt getBattery() einen sicheren Kontext voraus. Die Permissions Policy für battery erlaubt standardmäßig 'self'; ein gesperrtes Dokument erhält NotAllowedError. Die Warnung vor hoher Genauigkeit bleibt. Der Browser behält die Möglichkeit, eine Erlaubnis einzuholen, Werte zu verwischen oder an dieser Stelle gar nichts preiszugeben. Eine Seite braucht nicht jede Sekunde aus dem Leben des Akkus, um weniger E-Mails abzufragen.

Die W3C-Veröffentlichungsgeschichte reicht von Entwürfen 2011 über die Standardarbeit 2016 bis zu den Fassungen von 2024. Das sind Daten der Texte, keine einheitlichen Starttermine aller Browser. Die eigentliche Korrektur ist zeitlos: Ein Hinweis zum Energiesparen wird zur Erkennungshilfe, wenn die Messuhr zu fein tickt.

Das Schreibprogramm soll weiterhin speichern, bevor der Bildschirm schwarz wird. Das Postfach darf höflich warten. Für solche Höflichkeit braucht niemand ein Protokoll der letzten Atemzüge des Akkus.