Open samuelweiler opened 3 years ago
m32b64
commented
1 year ago @samuelweiler commented on Dec 3, 2020 @samuelweiler added privacy-needs-resolution label on Dec 3, 2020 @samuelweiler added security-needs-resolution label on Dec 3, 2020 m32b64@gmail.com asked any idea when the group might get around to these issues? It's Sep 23, 2022
anssiko
commented
1 year ago @m32b64 thank you for providing the GH label timeline. Here's an update on the recent developments:
The WG discussed the Battery Status API and the privacy-enhancing high-level API proposal at its 15 September 2022 meeting.
The WG made a resolution to "Understand the use cases behind current usage of the API, and if compelling, seek positions from other implementers for interest for the high-level Battery proposal."
The WG specified [SecureContext] restriction https://github.com/w3c/battery/pull/51 and landed this into the implementation earlier this year. Due to the substantial usage of the current API (~10% of page loads in Chrome), the WG believes normative changes to the current API benefit from a data-driven assessment and need a deprecation plan for implementers.
Interested folks are welcome to contribute use cases (#52) and propose enhancements to the privacy and security considerations sections.
m32b64
commented
1 year ago @anssiko Thanks for the update.
I hope that I can add to your understanding of, at least, one of the current uses of the Battery Status API.
I have implemented a Chrome extension based on research that supports keeping a Lithium-ion battery charge between 20 and 80 per cent. The extension creates a notification augmented with audio when the battery charge level is less than or equal to 20% or greater than or equal to 80%. I have included the relevant code below:
+-----------------------------------------------------------------------------------------------+
function batteryStatus(battery) {
if (battery.level <= 0.20 && battery.charging == false) {
chrome.notifications.create({
type: 'basic',
iconUrl: 'warning.png',
title: 'Battery Level: 20%',
message: 'CONNECT CHARGER NOW!',
requireInteraction: true,
priority: 2
});
playAudio();
}
if (battery.level >= 0.80 && battery.charging == true) {
chrome.notifications.create({
type: 'basic',
iconUrl: 'warning.png',
title: 'Battery Level: 80%',
message: 'DISCONNECT CHARGER NOW!',
requireInteraction: true,
priority: 2
});
playAudio();
}
function playAudio() {
var audio = new Audio('oneUp.mp3');
audio.play();
audio.volume = 0.25;
}
}
navigator.getBattery().then(function(battery) {
battery.onlevelchange = () => {
batteryStatus(battery);
};
});
+-------------------------------------------------------------------------------------------------+
As far as "enhancements to the privacy and security considerations", I believe they are already addressed in the current api:
Battery Status API W3C Editor's Draft 03 February 2022
"The user agent MAY ask the user for battery status information access, or alternatively, enforce the user permission requirement in its private browsing modes."
"The user agent SHOULD inform the user of the API use by scripts in an unobtrusive manner to aid transparency and to allow the user to revoke the API access."
I believe the final decision should be that of the user aided by the user agent.
Regards, Mike Barrett
Section 4 is a little short on analysis and explanation of the risks of exposing this API. At the very least, since the mitigations it defines (well, see https://github.com/w3c/battery/issues/27...) seem to be mostly about privacy, there should be a clear statement about security issues, if any.
Current best practice is to split security and privacy into separate sections. No fault for not having done that - we've only recently started asking for that - but please do that as you work on the section.