Hacker News Reader

Comment by dspillett | Hacker News Reader

Completely removing the feature seems overkill. Presumably there are good reasons to have it (full-screen kiosk style apps perhaps?) so would it not be better to leave the feature there but add a permissions gate as seen with location information and full-screen use ("This site wants to see power management information about your device, should we allow this? yes/no/always-for-this-site/never-for-this-site").

View on HN

Agreed wrt. the permissions gate. I wish more web APIs used these. I think there's an argument going around that these things are bad UX because they train the user to ignore prompts and just accept anything and everything so they can use the app, but at least on Android, it seems like users actually take notice of permissions (and complain about excessive permissions in Play Store reviews.) Keeping users aware of exactly what data is being leaked about them can only be a good thing. Bonus points if the API returns fake data until the user accepts the permission and there's no way for the app to tell if the data is real or not, so it can't force the user into accepting permissions they're not comfortable with.

I was actually very surprised when my wife told me she reviews permissions of app store apps on Android.

I thought for sure the average would be to just completely ignore them.

> Presumably there are good reasons to have it

That's not a good reason to keep a feature ever.

Given the context, browsers are ultimately a user's tool, not the developer's and the validity of APIs should be gauged by how useful they can be to the end user. If you can't demonstrate a valid use-case for the end user then there's no business having the API.

> > Presumably there are good reasons to have it

> That's not a good reason to keep a feature ever.

I'm not sure I understand you there. If there are good reasons for it existing (as I presume there are) then surely that is a good reason for it to be kept?

> If you can't demonstrate a valid use-case

Perhaps a full-screen kiosk application needs to indicate battery level (because any OS indicator is hidden? Though admittedly this is not going to be a common need.

Another use would perhaps be to turn off "excess" animations in a game when the battery is low.

The problem is that you're presuming there's a good reason or valid use case. The existence of feature or API is not evidence that it's warranted or even a good idea.

My point is that you need to scrutinize things a little more and not just trust that there's a good reason for something, especially if it looks problematic.

Permissions probably aren't that great UX-wise, but couldn't the API have been simplified instead, only allowing web sites to query remaining battery time? To me, it sounds like the API is vastly overengineered.

That still leaks a number, let's say it's 0-5h and resolution is 1 minute, that's 60*5 == 300, so roughly 8 bits of entropy.

A `onBatteryLow` callback might do the trick?

Exactly what I thought. The website needs to know whether the battery is low or not, not even how much time it still has. Let the API return a true/false to that question and, if necessary for some usecases, hide the rest behind a default deny permission.

Reply on news.ycombinator.com