Are there new use cases for battery API?

[marcoscaceres]

Given the lack of second implementation (see #65) and implementer interest, can we mark this as a Discontinued Draft?

[anssiko]

Per process, implementation experience is formally collected at the Candidate Recommendation phase.

This is a Working Draft and the Working Group continues work on the specification and continues to gather further implementation experience and input from the wider community. Considering this, it is deemed not appropriate to discontinue this work.

[marcoscaceres]

Wait, you can’t sit this in CR forever in the hope someone will implement it.

[marcoscaceres]

I think there needs to be a considered call and a formal decision taken. You can’t just dismiss my issue out of hand.

The working group should provide a reasonable timeframe for discontinuing this if it gets no adoption.

[anssiko]

Wait, you can’t sit this in CR forever in the hope someone will implement it.

This is a Working Draft. The Working Group continues work on the specification. EOM.

[marcoscaceres]

Please stop closing my issue. As you are editor (and it seems to be effecting your ability to be objective about this), I kindly ask that you recuse yourself from these conversations and let your other co-chair handle them.

[anssiko]

We will discuss this issue among the chairs and process experts and will re-open as appropriate.

In short: Your claims are not supported by the W3C Process. You claims have factual inaccuracies.

A longer version: What I'm referring to in this discussion is the W3C Process, specifically expectations with respect to https://www.w3.org/2023/Process-20231103/#implementation-experience and when that experience is formally collected. I also noted this is a Working Draft. I acknowledge you are not a participant of this Working Group and I am one of the editors of the specification. I am also a co-chair of this Working Group. These are facts.

I read between the lines you are not a fan of the W3C Process and people whose duty it is to make sure everyone follows the said process. Please do realize that document defines the rules by which we play. If you don't agree with the rules, you don't play. We acknowledge you have made a proposal for the Process WG, thanks for that. That is the right venue for process improvement ideas.

Maybe this articulation helps you understand this better: First, think about the implications of a general case of your claim: a W3C Working Draft without two or more implementations is to be discontinued. Would the W3C community support that? No. Is that what the W3C Process says? No. Is it normal for a W3C Working Draft to stay at a Working Draft stage for a longer time? Yes.

Your issue has been heard and a response has been recorded. What comes to your contributions as a non-participant in this Working Group, I recommend you to use your time more productively for your own benefit, and for the benefit of the W3C community.

[marcoscaceres]

Please stop closing the issue until we have a resolution. And stop saying things I never said. I never said I didn't like the W3C Process.

[marcoscaceres]

We should ascertain if there is enough support to keep this spec going and why. Otherwise it should be mark spec as Discontinued Draft. That's what this issue is about.

Again, if this is too personal for you, you should recuse yourself and let people who are not close to it have an objective discussion.

[reillyeon]

There is no process requirement for implementations or even implementor interest at the WD stage.

The DAS working group was recently (February 21st, 2024) chartered to work on this specification, which indicates that the W3C Membership intends us to do so. Knowing that there exist at least some members who are interested in continuing to pursue this draft, as a chair I can determine without further consultation that the WG does not have consensus to discontinue.

Unless any WG members would like to ask for a CfC on this, we will continue this work, and close these issues.

[marcoscaceres]

I understand, but can you help me understand what the value or utility of this API is (specifically if it’s being updated)?

Let’s imagine WebKit had never seen this, why would we implement it and expose it to the Web Platform?

I looked at #25 and most of those cases (specifically the media ones) are covered by more sophisticated solutions, like Managed Media Source. So I’m still unsure what value or use cases this API brings (and by implication why the W3C would then Recommend WebKit and other engines implement it).

As you can hopefully understand, WebKit takes things ending up on the Rec Track seriously, so we want to understand why this being Recommended to us to implement?

(i.e., DAS should be serving the interest of all members, not just DAS’s members)

[marcoscaceres]

Also, should I file a standards position on the webkit side to serve as Wide Review input for the working group? It would be good to perhaps get another position from Mozilla also as Wide Review input for the specification, if there are changes.

Maybe the changes the WG are going to make the specification worth while, so I’ll like to take an open mind to that.

At the same time, it would be good if the WG listened also to the feedback it is receiving from Wide Review (as well as Horizontal Review) as to whether the use cases of this spec are more effectively covered to other specifications.

I.e., this goes both ways: Wide/Horizontal review could make a compelling case that this API is either “harmful” or not needed. While the WG should be able to articulate the case as to why this should be Recommended for implementation.

Can we do that?

[marcoscaceres]

Updates the issue title so we can talk use cases and see if the spec provides something not already covered by other parts of the platform.

[anssiko]

Early use cases are discussed in https://www.w3.org/TR/battery-status/#introduction and I should say, not in an all inclusive manner. There's room for improvement. We've also discussed a complementary proposal you may want to check out: https://github.com/w3c/battery/blob/gh-pages/energy-saver-mode-explainer.md

One new use case that have come up in the context of WebNN API, also not documented in this spec yet, is to figure out whether to download a potentially very big model for on-device inference or use a cloud-based inference instead, or some other mechanism. In this case, knowing something about the device's battery level, and whether the device is plugged in or not is helpful. "You're about to download a 2 GB model file, but it appears you're not plugged in and your battery level appears to be pretty low. Would you still want to proceed?" Not a prompt I'd propose in a product, but for illustration. Also for long-running inference tasks it is helpful to know the rough impact on your battery over a long period or time and fine-tune accordingly. This is a specific case of the general case discussed in the introduction.

[reillyeon]

I would definitely appreciate sites like the Android Flash Tool providing a warning if you are about to try flashing a device when your battery is low.

Anssi, given this API has been available for a number of years are you aware of any compelling examples of real-world use? Metrics from Chrome say ~10% of page loads call this API, what are they using it for?

[marcoscaceres]

I would definitely appreciate sites like the Android Flash Tool providing a warning if you are about to try flashing a device when your battery is low.

Right, but doesn't the OS handle that? On iOS, you can't update the OS unless it's plugged in an at 50% (note that these heuristics change over time, based on hardware, OS version, etc.). It's not something you would want a web site to handle for a number of reasons:

1. after the firmware uploads, the battery level may have dropped.
2. the use may plug or unplug the device after the firmware has uploaded or during the process.
3. the site might have the wrong/outdated information, and can't know the actual health of the battery or device (e.g., even at 100%, the battery health might be bad - requiring the device to always be plugged in to do an update.)

And so on... a site is not in a good position to make any determination about if a firmware update should be installed based battery level. However, the OS is, and it generally tells the user if they can do an update or not based on the more sophisticated heuristics it has.

Metrics from Chrome say ~10% of page loads call this API, what are they using it for?

I'm concerned that the top-sites listed there are either porn sites, link farms, and fairly dubious sites (please have a look yourself... thought NSFW warning applies). Snapchat seems to be doing either fingerprinting or some kind of extreme form of feature detection (probably for fingerprinting) ... getBattery() is not called by any script:

This is pretty indicative, and I'd be more than willing to bet, the API is being primarily for fingerprinting (specially in that 10% usage range). If this was not the case, and there was a legitimate use for it by 10% of sites, developers would be requesting it be exposed in other engines.

Assuming this is a tracking vector, the larger question around use cases arises. Let's say there are legitimate use cases for this API, but those cases are niche (e.g., the Android Flash Tool case). The presumption is that that tool is not for average users.

So, my question is: does every website on the Internet need to have access to this API? or should it only be available to sites that actually need it? Why not only expose this to specific PWAs or make it explicitly something that developers would manually enable (or sites would request)?

This is critical: there may be legitimate niche uses for the API, but can those audiences/developers/users be served without exposing all other users to this tracking vector.

If we accept that this API is used as a tracking vector, but it may in certain case may be useful to some niche applications. So, given that, can we come up with a means to serve need audiences without compromising other users' privacy?

[marcoscaceres]

There are several issues with the "Energy Saver Mode" Proposal:

1. Privacy Concerns: Can enable fingerprinting and cross-site tracking by monitoring unique device states.
2. Security Risks: Potential misuse of energy saver mode status by malicious websites.
3. Inconsistent User Experience: Different implementations can lead to inconsistent behavior across websites.
4. Over-Complication: Adds unnecessary complexity for web developers.
5. Dependence on Web Compatibility: Varying browser and device support can cause compatibility issues.
6. Potential Misuse: Websites might intentionally degrade performance based on energy saver status.

And similarly, Issues with Using the Battery API for Model Downloads and Long-Running Tasks:

1. Privacy Concerns: Exposing battery information can lead to fingerprinting and tracking across different websites, violating user privacy.
2. Inconsistent Experience: Battery-based decisions can lead to inconsistent user experiences, as not all devices or browsers may handle battery data the same way.
3. User Trust and Control: Users might not trust websites to make decisions based on battery status, preferring OS-level controls for critical decisions.
4. Complexity and Maintenance: Adding battery checks increases the complexity of web applications and requires ongoing maintenance to handle different scenarios and devices.
5. Limited Web Capabilities: Web APIs do not provide the same level of detailed and secure battery management as OS-level solutions, making web-based decisions less reliable.

Even the case of:

"You're about to download a 2 GB model file, but it appears you're not plugged in and your battery level appears to be pretty low. Would you still want to proceed?"

That's something the OS or user agent should decide, not the site (the site is not the user agent and not in a position to make any sort of good determination - or such determinations would be a nuisance). Consider also, I might have a "low" battery on device with an exceptionally good battery where "low" may last 12 hours. The battery API would be affording a site making erroneous assumptions.

Or better, improve the models so they are not 2GB... The point being: the Battery API is a solution looking for a problem, where the actual problems need to be addressed elsewhere.

[anssiko]

I will restate what my co-chair @reillyeon said in https://github.com/w3c/battery/issues/64#issuecomment-2125671911:

There is no process requirement for implementations or even implementor interest at the WD stage.

The DAS working group was recently (February 21st, 2024) chartered to work on this specification, which indicates that the W3C Membership intends us to do so. Knowing that there exist at least some members who are interested in continuing to pursue this draft, as a chair I can determine without further consultation that the WG does not have consensus to discontinue.

Unless any WG members would like to ask for a CfC on this, we will continue this work, and close these issues.

I will now proceed to close this issue.

The work on this API continues.

I invite you to review the way your own organization responded to the corresponding AC review: https://www.w3.org/2002/09/wbs/33280/das-wg-2023/results (Member-only link)

[marcoscaceres]

We are having a fruitful discussion about the use cases. Please stop closing my issues. I will close them once I have satisfactory responses.

[marcoscaceres]

@anssiko, Reilly asked:

Anssi, given this API has been available for a number of years are you aware of any compelling examples of real-world use? Metrics from Chrome say ~10% of page loads call this API, what are they using it for?

@anssiko, you also completely ignored my feedback and didn't answer my questions:

does every website on the Internet need to have access to this API? or should it only be available to sites that actually need it? Why not only expose this to specific PWAs or make it explicitly something that developers would manually enable (or sites would request)?

This is critical: there may be legitimate niche uses for the API, but can those audiences/developers/users be served without exposing all other users to this tracking vector.

I know these are hard questions, but closing the issue without answering them is not helpful.

[anssiko]

@marcoscaceres you requested to discontinue this work in https://github.com/w3c/battery/issues/64#issue-2307258382 The WG did not support such a request and does not discontinue this specification per https://github.com/w3c/battery/issues/64#issuecomment-2125671911 I closed this issue in response to that. Then this discussion drifted to other topics.

Other topics are however better discussed in existing topic-specific issues:

• Use cases discussed in #25

• Permission model was discussed in #5, that led to #10 fixed by #13

However, before jumping on these issues, please note:

Issue #5 has a lot of helpful historical context. Before filing a new issue or chiming in, I ask people interested in making well-informed contributions to revisit the previous discussions open minded. Based on that specific discussion a mitigation was specified and it seems the intent to implement that mitigation was put on hold due to Akamai's feedback that such a change would break its open-source library. I believe a reasonable course of action here would be to revisit that intent given the mitigation was considered to be effective against unwanted use.

[cwilso]

Also, I would like to refute a statement you made, @marcoscaceres :

Wait, you can’t sit this in CR forever in the hope someone will implement it.

Actually, there is no maximum length of time one can sit in CR. I would point out that WebMIDI sat in draft [1] for around a decade with only one core engine implementation [2] before Mozilla decided to pick it up and ship it.

It is a totally valid statement of "We have spent a considerable amount of time working out the use cases, and if this is to become an interoperable standard, this is how a cross-sectional segment thinks it should be done." Certainly, it is not the same as an interoperable REC.

[1] If I had it to do over again, I would have spent a bit more effort personally as editor and gotten it to CR early on, and left it in that state for that time period. My bad. [2] There were at least two other implementations - a "Web MIDI Browser" wrapper on iOS (in the App Store), and the plug-in-based polyfill I wrote for Mozilla a long time ago (pretty sure it rotted away).

[reillyeon]

@anssiko, for an API that is available in at least one engine (and since that engine is Blink, multiple browsers) I'd like us to move past prospective use cases and look at real-world deployments. Can you point at any sites that are making user-visible decisions based on the Battery Status API?

The Akamai use case (described in their paper) doesn't really count as user-visible. The other examples from the Chromium issue are limited to kiosk-mode applications and browser extensions which could be given access to this information without providing it to every web site.

A number of positive user benefits have been proposed but it's unclear that any site has actually implemented them. I would like to see that evidence before advocating one way or the other for continuing work on this specification.

[reillyeon]

Right, but doesn't the OS handle that?

@marcoscaceres, you misunderstand the use case I'm proposing: This is for the device sending the firmware image to check whether it is on battery power and warn that the operation might take longer than the amount of power it has remaining. That is not something that the OS can handle.

[marcoscaceres]

@reillyeon, ah! got it... it's the inverse. Thank you for clarifying.

I think my point stands, if, as Chrome does, .dischargingTime and .chargingTime both always return Infinity, because the site can't know what .level of .15 means in terms of minutes of battery life left (or what kind of device I'm on). Like 15% on my MacBook Pro could be 1-2 hours.

[marcoscaceres]

I think the "kiosk mode" Web Apps is what I'm getting to above too... there's a class of application where this API makes sense (and should be available), but it might not make sense on the Web itself, where it can be used as an easily accessible tracking vector (e.g., .level + .charging)... so the ask is, how do we only expose it to kiosk mode? (or broadly just to the Web App/PWAs that actually need it).

[anssiko]

I think my point stands, if, as Chrome does, .dischargingTime and .chargingTime both always return Infinity

This is not correct. Chrome (also on macOS) returns the time in seconds for both.

(You need to wait a while for the subsystem to calculate the estimates after you plug in or unplug. If you tested this quickly, you saw Infinity for that reason. This is per the spec.)

@anssiko, for an API that is available in at least one engine (and since that engine is Blink, multiple browsers) I'd like us to move past prospective use cases and look at real-world deployments. Can you point at any sites that are making user-visible decisions based on the Battery Status API?

I provided data that points to places where to look for real-world deployments in https://github.com/w3c/battery/issues/25#issuecomment-2136891965

[marcoscaceres]

Right, but that doesn't mean anyone uses them for anything. Just because they are part of frameworks doesn't mean much and is side-stepping the question.

What actual application is using the API and for what?

(Simple feature detection doesn't count as usage)

Just as important: what applications / web sites are misusing the API? and for what/how?

[marcoscaceres]

You need to wait a while for the subsystem to calculate the estimates after you plug in or unplug. If you tested this quickly, you saw Infinity for that reason. This is per the spec.

@anssiko, isn't that worse tho for privacy? Like, here two sites can collude to confirm it's the same user by checking their battery status (those are two different origins):

I can literally do this across two tabs across origins:

x = await navigator.getBattery();
setInterval(()=> { console.log(x.dischargingTime, x.level) }, 1000);

And watch for changes that are kept in sync.

[anssiko]

@marcoscaceres, please open a separate issue with your two tabs across origins proof-of-concept so the WG can look into it. Please include adequate details to make this reproducible.

We are discussing what sites use the API and how in https://github.com/w3c/battery/issues/25#issuecomment-2137363100