To be able to load a less resource intensive version (i.e. disable animations, reduce refresh rate, remove canvas elements etc...) of a website if the battery is low.
Yea ok...but who does that really ? lets face it, this is just some extra signals so they can track you more easily. I know it was never intended to be used as tracking information but the least they could do is be less precise about your battery percentage.
This is ridiculous IMO. Instead of providing false (or "less precise") data let's not provide that data in the first place.
My guess is this is just another part of the attempt to move desktop features to the web browsers so that people don't have to write actual applications. Personally, I don't like this trend.
As I noted elsewhere, it’s about more than “so that people don’t have to write actual applications” (although I grant you that you have identified a real thing).
For the ideologically inclined, it’s also about disintermediating the relationship between users and developers. Web sites don’t need an app store.
Then it would certainly be useful to be able to spoof this battery level reported by your browser: then you can always get the less resource intensive versions and surf longer :D
Be careful with that, you might see higher prices then.
> “Some companies may be analysing the possibility of monetising the access to battery levels,” he writes. “When battery is running low, people might be prone to some – otherwise different – decisions. In such circumstances, users will agree to pay more for a service.”
True, but for some reason this one hit a nerve. At least in most cases digital marketing can (at least slightly) benefit the user, but in this case the benefit is 100% with the company. Uber were alleged to charge more for those with low batteries too. Ugh.
Marketing used to be beneficial to consumers by helping them become aware of new products and their features. In an era of instant information search and retrieval, this is no longer necessary. It's all zero-sum spam intended to overwhelm one's decision making capabilities coupled with surveillance to enable better price discrimination.
I agree. The correct way to discriminate between low- and high-resource requiring functionality is "on battery" vs "plugged in". The specific battery level is completely useless.
Web applications served over HTTP, on the other hand...
Mozilla have it as part of their mission to make technology open and accessible (insert DRM debate here). Native apps have been thrown behind the app store “walled garden.” So, they want to make it possible to create rich apps over HTTP.
Thus, you find things like this available to web pages.
Surely the answer here is for the browser to not give such fine-grained information. For example always give the charge level to the nearest 10 percent and the battery life to the nearest 10 seconds.
Or take the iOS approach. The phone is either in a low power mode or not.
The benefit is that the user doesn't need an additional setting for each potential web app to set the threshold for a low power mode, it's all done once at the OS level.
I'm skeptical. If you ask for permission to capture video, that's something that users will understand, and they'll be able to make an informed decision. But if you ask for permission to check the battery level, most people will just click through the request because they don't understand the privacy implications.
"This browser is so dumb, it's saying that I can be identified by my battery level! Stupid Google!"
... I suspect many wouldn't understand the tracking implications, and even many who can understand it wouldn't immediately make the connection.
That said, this isn't the first such thing used to identify users. Other things like resolution, browser, extensions, etc, can be used to make a nearly unique fingerprint and this has been known for years. Search "browser fingerprint" and you'll find many pages on the subject.
I would opt for levels of concern in power usage: low concern (desktop or mobile that is charging), concern (mobile), high concern (mobile on low battery). Then we could streamline it more, because websites know when you are on mobile already and give single flag: low power.
It is is similar in any other case of low resources. There probably is not much of a difference for a website if user is low in power than if it is low in memory. There should be then just one flag/event really: low resources (catch-all for battery, memory, CPU time, storage etc.).
Thanks, came here to say the same thing. This was as surprsing to me as the first time a spammy website started vibrating my phone (dom.vibrator.enabled)
Not really anonymous. People have a pretty good idea of which bitcoins are his. He just never does anything with them, so that knowledge doesn't serve much of a purpose.
It would be sort of like setting your browser's user-agent to a unique identifier that you never change, but then never actually using the browser for anything. It's not the unique ID that hides you, it's the fact that you never use it.
But this is more like saying "I'm walking in a shop, the shop shouldn't record what tipe of shirt I'm wearing".
It's not something hidden if the phone is giving the info out. The only thing we could do is stop the phone from sending the information in the first place.
Mobile device fingerprinting has been a big deal for a long time. Multiple startups have been created to do it and some have been acquired. And many adtech companies incorporate this functionality.
I hope some day soon your mobile OS let's you choose to restrict the device information available to sites and apps. It really ought to be a user's choice whether to make the tradeoff between providing more info in exchange for supposedly better functionality or not.
This was a terrible idea from the start. In the best case scenario, what is supposed to happen? The sites I visit suddenly start being served as shells of their former selves in order to save the compute cost of rendering them? Web designers are supposed to figure out an entirely new design mode for the whole site to cater to visitors with low batteries?
Now back to the real world, where many sites I visit peg my desktop CPU trying to serve so many ads and so much tracking to squeeze every possible cent of profitability from my visit. If there's a war against ad-blockers, did we think these sites would relent and say, oh, OK, I see you might be low on battery, I'll serve just the content you want this time?!
No, this is a purely client-side concern, with plenty of purely client-side mitigation which can be put into place. That the protocol actually specified 14m degrees of granularity -- from what at the very least ought to have been a binary setting -- makes me wonder if the point wasn't user tracking all along.
Missing from the article: Do all user agents actually provide this information in request headers? Is there a way to shut it off?
As a web application developer, one idea that comes to mind is that, if I were writing an app that supports offline usage, I'd probably want to be aware of a low battery situation so that I can save my state and warn the user that the app needs to shut down to avoid data loss. I might also switch from online mode to offline mode, again letting the user know (and letting them override the choice, maybe.)
I can't see any reason to make use of the battery status server-side. But, there's also no way to prevent the information from being sent, once you make it available to javascript code on the device. If the standard api didn't send it, then you'd just see ad-hoc apis gathering the data locally and sending it.
However, I don't think the battery state needs to be as granular as it is to support those use-cases. A simple boolean hasLowBattery or a much coarser 0%-25%-50%-75%-100% enumeration seems like it would have been sufficient.
If anything, I would propose the mode should be a user-controlled bit called simply: "LOW"
Maybe I request low mode because...
I hope you serve me less crappy ads
I haven't bought a new phone in 3 years
I am running other apps which need more CPU
I find too much interactivity distracting or confusing
I just want to read black text on a white background
I hate your website, but need to visit it for some reason anyway
...
I have full battery, but I need to conserve it
I have low battery
EDIT: Fuck, I just realized, this already exists, and it's called NOSCRIPT. Wait, we could call this LOWSCRIPT!
Good luck defining "low". Also, coarse percentages of charge provide no indication of the amount of time left of a battery based on current activity. Which is something you would need in the above offline/save example.
Maybe a boolean would work. I don't think 0%-25% would work for the scenario I described; 0% is too late to do anything about the low battery situation, and 25% is too soon to worry about it.
I've seen my devices give notifications about the battery level to me, but I don't think they notify the apps I'm running, and if I ignore the notifications until the battery dies the device just shuts down. The apps have no chance to save their state.
Often, that's probably just fine. But if I'm developing an app and I have a requirement to save state before my app gets shut down due to power failure, this api will allow me to do that. It's the equivalent to a drive flushing any writes before shutting down; normally they'd get flushed sooner or later, but if you have to shut down NOW, you'd better flush now too while you can.
I mean, but if the device notifies you that it's running low on battery... maybe you should close the app? Shouldn't this be enough?
You would avoid loosing data, and regarding user experience, also avoid a slower performance of your app (and perhaps complaining about it?), and also seeing your device shutting down itself with your app screen running in background (which is pretty lame).
As a user, maybe that should be enough. Maybe not. It depends on the app and how critical the data/state is, I guess.
As a developer, trying to implement requirements set by a product designer/owner who thinks saving the data is critical even if the user doesn't cooperate, the api is useful to have.
If you're really worried about your battery running low and working with critical data, removing the browser overhead which is draining you battery should be one of the first things to do.
> But, there's also no way to prevent the information from being sent, once you make it available to javascript code on the device.
Surely it's possible for JavaScript engines to either (a) optionally prevent code from accessing this; or (b) return random nonsense, or even just a single fixed static value (for every instance of the engine anywhere).
Nope; either the information is not available to Javascript code at all, or the Javascript code can do whatever it wants with the info.
A security permission, or config setting, can/should be used to prevent access to the api that returns the battery level. But once access is enabled, there's no way to prevent the code from getting the level (which is just a number) and sending it to a server (which is just calling an ajax request with a numeric argument.)
I would think that if you architect your app to handle disappearing network connections gracefully, it will probably handle the user shutting down the phone gracefully too. If the battery is critically low, the user will get popups from the operating system at various points and can make a decision whether or not to keep using your application.
You could also expose an offline-only option somewhere in your application. A user might want to do this if they are in an area with marginal coverage (e.g., there is a connection, but it's basically useless) or roaming, etc.
A disappearing network connection is a different case, because the app continues running. Imminent power failure is different because the app is about to be terminated, probably not gracefully. This is also different from the user shutting down the app manually, because that's probably a graceful shutdown which will give you a chance to save some state before termination.
E.g. weather app that automatically fetches new weather data periodically, but stops when battery is low. That said, you're right that the only data you need for such purposes is binary. The current API provides too much info.
If it's a native app, then it can already do this. If it's a web app, then hopefully it's only fetching updates if the tab is visible, right? I absolutely think web apps should be checking if their tab is foreground and behaving differently based on that.
So what you're saying is that on top of having to deal with low battery, now you're also getting caught in the rain? :-)
Don't tell Steve, but if I want to save battery, I swipe closed the browser. If I sign up for rain notifications, I better get my darn rain notification!
No, I'm not talking about low battery. You suggested that the app stop checking for weather updates when its tab is not in the foreground. If I do that then I get caught in the rain even with a full battery.
Hopefully browser tabs don't have any way of triggering system notifications, in which case how would it matter if a webapp stopped automatically updating when the window loses focus?
> Web designers are supposed to figure out an entirely new design mode for the whole site to cater to visitors with low batteries?
You're constructing an obvious straw-man here. It's easy to imagine scenarios where a 'low power mode' would be in the interest of the site and it's visitors. Especially when we're talking 'apps' rather than 'content sites' - there's plenty of desirable but non-essential functionality that could be disabled and for web apps intended for mobile use this could potentially be a great differentiator.
The most obvious thing is animations. Android has a powersave mode where all animations are disabled. (It's a bit unsettling, actually, but really helps with conserving the few remaining electrons.)
I think you're fighting straw with straw. Think about the development and testing costs of trying to add the functionality and have it work across a host of devices.
Again, there's a litany of things a device can do to reduce power usage itself. Native apps and websites alike should absolutely consider their power profile and reduce it if possible.
The idea which I think is terrible is making this part of unrestricted Web API as 14m possible states. But even as a binary state I think very few apps have the resources to design, develop, and test across multiple devices for dynamically adjusting power consumption.
> Think about the development and testing costs of trying to add the functionality and have it work across a host of devices.
1. Simple example - any app that does polling for any reason can reduce the polling interval.
2. Interactive WebGL charts could be replaced with static bitmaps
3. Background spell or syntax checking could be disabled and made 'on demand'
4. Chatty network features could be disabled or cut back.
None of the above need to significantly increase development or testing costs. They are quick examples I pulled out of thin air. If we discussed specific applications I'm sure I could suggest more.
Non-browser apps already can do all this and often do. (and I wish they would do it more often)
I guess the way I think of it... if I am visiting a site or web app, I am actively opting to expend the energy required to render the page. Obviously if the page is not visible, and not doing a background task like playing audio, then I expect its CPU consumption to be negligible. So, first and foremost, use the page visibility API.
If I'm low on battery and choose to open that webpage, and now the WebGL charts are static bitmaps, my first reaction is going to be WTF. Now I want a button synonymous with 'Show Desktop Site' -- I guess we could label it the 'Stop Fucking With Me' button.
All code should be aware of the CPU that it is consuming. More efficient code is not just better for battery, but also likely more responsive and better for multitasking. So the question becomes, not how do we reduce CPU and possibly even improve UX, but in what cases would we make the CPU requirement dynamic, and when/where might the trade-offs be made to ultimately improve the user experience.
So first is Page Visibility, as discussed. The very next area where I would consider making CPU usage dynamic is not a battery state, but rather it's an overall device performance adjustment. If someone visits with an iPhone 4 versus a 6s, they have dramatically different amounts of compute available. I would consider investing in dynamic CPU consumption based on a device performance flag a lot sooner than I would do it based on remaining charge, because I think it would improve the UX for a large percentage of users every time they used the site. It's also a static setting from the perspective of the device owner, so they are not seeing changing UX on their device potentially from one moment to the next.
> None of the above need to significantly increase development or testing costs.
I can only offer my opinion based on my experience, but trying to alter functionality to reduce CPU load based on dynamically changing battery metrics across a pool of devices which may behave inconsistently... this is really not simple to code and test and maintain over time. We have a hard enough time just trying to efficiently serve device-specific assets (like lower res images to mobile) and that's based on a static/fixed user-agent string, not a dynamic header, and sites get it wrong so often that user-agents added a special button to try to turn it off!
I agree with your sentiment. However, I also appreciate the web maturing and giving developers similar API abilities as a native app. The API may not have a use for you, but surely across the global audience of web apps there will be more than a few valid use cases.
This is a great point, and I too tend to think in terms of the Web API having parity with native can only be a Good Thing.
The problem is the web is not a very nice place, and (like the ad networks mentioned by the OP) third parties beyond my control often get to run fully-scoped Javascript on my browser. OTOH, at least I get to choose which apps are installed on my home screen.
So I wonder if instead of all the prompts we have today;
Would you like to allow this page to see your location?
Would you like to allow this page to use your microphone?
Would you like to allow this page to use your camera?
Would you like to allow this page to send notifications?
Would you like to allow this page to view your battery status?
We need something more holistic. I joked above about NoScript vs. LowScript. I was chuckling to myself imagining a 3-way toggle -- NoScript, LowScript, and YoScript.
There certainly could be use cases for having a comprehensive Web API for charging status, battery capacity, remaining charge, and time till charged. Someone will find this useful. But simply adding it and having it on-by-default is not without tradeoffs...
As Web API matures, there is a plethora of APIs which have privacy concerns, some slight, some grave. We need to communicate to users these trade-offs in some usable way, and give them some control over them. Some APIs definitely need their own unique Yes/No prompt, like turning on my camera/mic, but I wonder if there's a middle-ground of a group of APIs which should be restricted all behind a single setting, akin to favoriting or 'staring' the site gives just that first-party domain access to those APIs. Maybe we even call it "Native Mode", then we put choice back in the hands of the user and we can expose APIs with impunity.
Then you confuse the users by displaying some of the content only some of the time. Mobile sites are already crippled in functionality so I can't imagine them being crippled more being a good thing.
> In the best case scenario, what is supposed to happen?
I assume it is intended for mobile apps written in-browser that are intended to run in some sort of kiosk mode so obscure the OS's default battery display.
>This was a terrible idea from the start. In the best case scenario, what is supposed to happen?
I see two scenarios here:
1. The usual cock-up of the API guys not being the privacy/security guys and managers being unable to find common ground between the two.
2. The pressure to make HTML5 be an "app killer" and making sure devs have everything they need to write HTML5 web apps that can compete with native apps. Security/privacy becomes a browser problem, and if the browser guys screw up (see 1.) then too bad.
Seems to me, a simple middle ground of reporting a less granular battery value would have made sense. Very Low, Low, Medium, High, Very High would probably take care of it. You can probably just shoe-horn this in right now by just assigning a number to each condition and never telling websites the real number (or randomizing it a bit).
Not mine, since I have JavaScript turned off (how do you know I have JavaScript turned off? Don't worry, I'll let you know every time there's a browser exploit or privacy hole due to JavaScript — so at least thrice weekly).
They've closed the window but left the door open. See the link I posted. When the page knows "Battery will be discharged in 18365 seconds" it doesn't matter that the battery percentage is only two digits.
Every time these new user tracking hacks come up (like the one based on Audio API etc.) I wonder why in the world this is not handled in a manner similar to Android where it prompts you to give permissions to the any specific API its going to use.
Because web developers have this dream of replacing native apps, the industry has been busy removing piece by piece the sandbox that browser apps live in. They want to have all the power and features of native apps except one: app store review and approval. But if you have all the power of native without any moderation, plus the wild west of user-hostile ad-networks... actually i don't know where it leads but it's not good.
I have that dream but didn't ask for the sandbox to be removed. Having users approve use of location data is quite fine by me, and clearly superior to the way it works with native Android apps, where the user has to approve a bunch of permissions at install time, not knowing for sure which ones are actually necessary.
How do I disable this in Chromium? I feel like I ask this question at least once a month, by the way. Last time, it was for WebRTC information leakage...
Why does the battery status have to be so accurate that it can be used to identify? Your device should be able to fuzz it and just send an integer between 1 and 100 - that should be enough granularity for the intended use case. Update the damn spec.
These types of articles are silly in that they leave out the context that nearly every variable that is pseudo-unique to you is already being used and that this is a common practice known as fingerprinting that has been done since forever. Headline: "New variable x can be used to track you". Well, yea. Add that to the size your browser window is, what plugins you have installed, your IP address, and many more ways a website can use to surmise a relationship between two disjoint events.
As someone building a cross-platform battery monitor that depends on APIs like this being available, I think the best solution would be to treat battery status like the location information, where the user is asked on a case-by-case basis whether to provide the information.
You might argue that this sort of stuff should only be available to native applications, that browsers should not attempt to replace native apps or even recreate an OS within themselves (something Chrome is often criticized for). The thing is, my battery monitor has native apps and yet users have been asking for web-based clients, be it browser extensions or plain web pages. And with some platforms loading a website or installing an extension has much less friction than installing a native app.
Sure, extensions can have access to a lot of stuff webpages don't have. But I would rather use standardized APIs that work across all browsers and are well documented in more than one website, than have to rewrite my extension for each browser and not have it work on plain old pages.
If the battery API was made to work like the location one I think everyone would be happy - users are informed and in control, developers can still offer features based on it, and it raises red flags when it needs to ("why is this advert asking about my battery status?").
This, and certain other capabilities, should be guarded like access to location data: Available upon user agreement only and just on secure connections (i.e. TLS).
101 comments
[ 2.3 ms ] story [ 74.9 ms ] threadThis lets sites who want to do "real things" with battery levels have access, without it being available "for free" (prompt is annoying).
My guess is this is just another part of the attempt to move desktop features to the web browsers so that people don't have to write actual applications. Personally, I don't like this trend.
For the ideologically inclined, it’s also about disintermediating the relationship between users and developers. Web sites don’t need an app store.
> “Some companies may be analysing the possibility of monetising the access to battery levels,” he writes. “When battery is running low, people might be prone to some – otherwise different – decisions. In such circumstances, users will agree to pay more for a service.”
That describes a scarily large portion of all web stuff.
Web applications served over HTTP, on the other hand...
Mozilla have it as part of their mission to make technology open and accessible (insert DRM debate here). Native apps have been thrown behind the app store “walled garden.” So, they want to make it possible to create rich apps over HTTP.
Thus, you find things like this available to web pages.
The benefit is that the user doesn't need an additional setting for each potential web app to set the threshold for a low power mode, it's all done once at the OS level.
... I suspect many wouldn't understand the tracking implications, and even many who can understand it wouldn't immediately make the connection.
That said, this isn't the first such thing used to identify users. Other things like resolution, browser, extensions, etc, can be used to make a nearly unique fingerprint and this has been known for years. Search "browser fingerprint" and you'll find many pages on the subject.
It is is similar in any other case of low resources. There probably is not much of a difference for a website if user is low in power than if it is low in memory. There should be then just one flag/event really: low resources (catch-all for battery, memory, CPU time, storage etc.).
Plus ad blocking and "social button" blocking, as a preventive measure for this kind of issue.
The Web is the new Wild West.
Becoming famous and staying anonymous are diametrically opposed.
It would be sort of like setting your browser's user-agent to a unique identifier that you never change, but then never actually using the browser for anything. It's not the unique ID that hides you, it's the fact that you never use it.
Why should we allow companies recording other features that can identify us?
(btw, I don't think this should be a technical debate)
I hope some day soon your mobile OS let's you choose to restrict the device information available to sites and apps. It really ought to be a user's choice whether to make the tradeoff between providing more info in exchange for supposedly better functionality or not.
Now back to the real world, where many sites I visit peg my desktop CPU trying to serve so many ads and so much tracking to squeeze every possible cent of profitability from my visit. If there's a war against ad-blockers, did we think these sites would relent and say, oh, OK, I see you might be low on battery, I'll serve just the content you want this time?!
No, this is a purely client-side concern, with plenty of purely client-side mitigation which can be put into place. That the protocol actually specified 14m degrees of granularity -- from what at the very least ought to have been a binary setting -- makes me wonder if the point wasn't user tracking all along.
Missing from the article: Do all user agents actually provide this information in request headers? Is there a way to shut it off?
I can't see any reason to make use of the battery status server-side. But, there's also no way to prevent the information from being sent, once you make it available to javascript code on the device. If the standard api didn't send it, then you'd just see ad-hoc apis gathering the data locally and sending it.
Maybe I request low mode because...
EDIT: Fuck, I just realized, this already exists, and it's called NOSCRIPT. Wait, we could call this LOWSCRIPT!Doesn't the client (laptop, phone, etc) does this already?
Often, that's probably just fine. But if I'm developing an app and I have a requirement to save state before my app gets shut down due to power failure, this api will allow me to do that. It's the equivalent to a drive flushing any writes before shutting down; normally they'd get flushed sooner or later, but if you have to shut down NOW, you'd better flush now too while you can.
You would avoid loosing data, and regarding user experience, also avoid a slower performance of your app (and perhaps complaining about it?), and also seeing your device shutting down itself with your app screen running in background (which is pretty lame).
As a developer, trying to implement requirements set by a product designer/owner who thinks saving the data is critical even if the user doesn't cooperate, the api is useful to have.
If you're really worried about your battery running low and working with critical data, removing the browser overhead which is draining you battery should be one of the first things to do.
Surely it's possible for JavaScript engines to either (a) optionally prevent code from accessing this; or (b) return random nonsense, or even just a single fixed static value (for every instance of the engine anywhere).
A security permission, or config setting, can/should be used to prevent access to the api that returns the battery level. But once access is enabled, there's no way to prevent the code from getting the level (which is just a number) and sending it to a server (which is just calling an ajax request with a numeric argument.)
You could also expose an offline-only option somewhere in your application. A user might want to do this if they are in an area with marginal coverage (e.g., there is a connection, but it's basically useless) or roaming, etc.
Don't tell Steve, but if I want to save battery, I swipe closed the browser. If I sign up for rain notifications, I better get my darn rain notification!
You're constructing an obvious straw-man here. It's easy to imagine scenarios where a 'low power mode' would be in the interest of the site and it's visitors. Especially when we're talking 'apps' rather than 'content sites' - there's plenty of desirable but non-essential functionality that could be disabled and for web apps intended for mobile use this could potentially be a great differentiator.
(If your answer is 'there are no non-essential animations' then you haven't thought about it for long enough)
Again, there's a litany of things a device can do to reduce power usage itself. Native apps and websites alike should absolutely consider their power profile and reduce it if possible.
The idea which I think is terrible is making this part of unrestricted Web API as 14m possible states. But even as a binary state I think very few apps have the resources to design, develop, and test across multiple devices for dynamically adjusting power consumption.
1. Simple example - any app that does polling for any reason can reduce the polling interval.
2. Interactive WebGL charts could be replaced with static bitmaps
3. Background spell or syntax checking could be disabled and made 'on demand'
4. Chatty network features could be disabled or cut back.
None of the above need to significantly increase development or testing costs. They are quick examples I pulled out of thin air. If we discussed specific applications I'm sure I could suggest more.
Non-browser apps already can do all this and often do. (and I wish they would do it more often)
If I'm low on battery and choose to open that webpage, and now the WebGL charts are static bitmaps, my first reaction is going to be WTF. Now I want a button synonymous with 'Show Desktop Site' -- I guess we could label it the 'Stop Fucking With Me' button.
All code should be aware of the CPU that it is consuming. More efficient code is not just better for battery, but also likely more responsive and better for multitasking. So the question becomes, not how do we reduce CPU and possibly even improve UX, but in what cases would we make the CPU requirement dynamic, and when/where might the trade-offs be made to ultimately improve the user experience.
So first is Page Visibility, as discussed. The very next area where I would consider making CPU usage dynamic is not a battery state, but rather it's an overall device performance adjustment. If someone visits with an iPhone 4 versus a 6s, they have dramatically different amounts of compute available. I would consider investing in dynamic CPU consumption based on a device performance flag a lot sooner than I would do it based on remaining charge, because I think it would improve the UX for a large percentage of users every time they used the site. It's also a static setting from the perspective of the device owner, so they are not seeing changing UX on their device potentially from one moment to the next.
> None of the above need to significantly increase development or testing costs.
I can only offer my opinion based on my experience, but trying to alter functionality to reduce CPU load based on dynamically changing battery metrics across a pool of devices which may behave inconsistently... this is really not simple to code and test and maintain over time. We have a hard enough time just trying to efficiently serve device-specific assets (like lower res images to mobile) and that's based on a static/fixed user-agent string, not a dynamic header, and sites get it wrong so often that user-agents added a special button to try to turn it off!
The problem is the web is not a very nice place, and (like the ad networks mentioned by the OP) third parties beyond my control often get to run fully-scoped Javascript on my browser. OTOH, at least I get to choose which apps are installed on my home screen.
So I wonder if instead of all the prompts we have today;
We need something more holistic. I joked above about NoScript vs. LowScript. I was chuckling to myself imagining a 3-way toggle -- NoScript, LowScript, and YoScript.There certainly could be use cases for having a comprehensive Web API for charging status, battery capacity, remaining charge, and time till charged. Someone will find this useful. But simply adding it and having it on-by-default is not without tradeoffs...
As Web API matures, there is a plethora of APIs which have privacy concerns, some slight, some grave. We need to communicate to users these trade-offs in some usable way, and give them some control over them. Some APIs definitely need their own unique Yes/No prompt, like turning on my camera/mic, but I wonder if there's a middle-ground of a group of APIs which should be restricted all behind a single setting, akin to favoriting or 'staring' the site gives just that first-party domain access to those APIs. Maybe we even call it "Native Mode", then we put choice back in the hands of the user and we can expose APIs with impunity.
I assume it is intended for mobile apps written in-browser that are intended to run in some sort of kiosk mode so obscure the OS's default battery display.
I see two scenarios here:
1. The usual cock-up of the API guys not being the privacy/security guys and managers being unable to find common ground between the two.
2. The pressure to make HTML5 be an "app killer" and making sure devs have everything they need to write HTML5 web apps that can compete with native apps. Security/privacy becomes a browser problem, and if the browser guys screw up (see 1.) then too bad.
Seems to me, a simple middle ground of reporting a less granular battery value would have made sense. Very Low, Low, Medium, High, Very High would probably take care of it. You can probably just shoe-horn this in right now by just assigning a number to each condition and never telling websites the real number (or randomizing it a bit).
I searched Chrome settings for "battery" and found nothing. I did find this article with instructions for turning it off in Firefox: https://www.hackread.com/smartphone-laptop-battery-invading-...
I'm not opposed to the concept of a battery API, but as others have commented, it would be just as useful with a lot less granularity.
See: https://panopticlick.eff.org/
Here's my result:
Your browser fingerprint appears to be unique among the 119,205 tested so far.
Privacy is great...
You might argue that this sort of stuff should only be available to native applications, that browsers should not attempt to replace native apps or even recreate an OS within themselves (something Chrome is often criticized for). The thing is, my battery monitor has native apps and yet users have been asking for web-based clients, be it browser extensions or plain web pages. And with some platforms loading a website or installing an extension has much less friction than installing a native app.
Sure, extensions can have access to a lot of stuff webpages don't have. But I would rather use standardized APIs that work across all browsers and are well documented in more than one website, than have to rewrite my extension for each browser and not have it work on plain old pages.
If the battery API was made to work like the location one I think everyone would be happy - users are informed and in control, developers can still offer features based on it, and it raises red flags when it needs to ("why is this advert asking about my battery status?").