Re: [battery] What’s this spec about again? (#64)

>I would definitely appreciate sites like the [Android Flash Tool](https://flash.android.com/) 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 this changes over time). 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](https://chromestatus.com/metrics/feature/timeline/popularity/2198) 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: 

![Screenshot 2024-05-26 at 4 35 59 PM](https://github.com/w3c/battery/assets/870154/e6fa38d1-8ea7-41da-8bf4-eacd31c2248b)

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? 
 


-- 
GitHub Notification of comment by marcoscaceres
Please view or discuss this issue at https://github.com/w3c/battery/issues/64#issuecomment-2132101571 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Sunday, 26 May 2024 07:13:21 UTC