Re: CfC: Battery Last Call

On 11/21/2011 12:14 PM, Anssi Kostiainen wrote:
> On 18.11.2011, at 12.44, ext Mounir Lamouri wrote:
>> On 11/17/2011 05:07 PM, Robin Berjon wrote:
>>>> 2. A bit more sensitive information like whether the device has a battery or not. We do not expose clearly this information but you can get it by doing (battery.chargingTime == battery.dischargingTime) both will be Infinity if the device is battery-less. This information can't be used to attack the user but can help fingerprinting her/him: it's adding one bit of entropy (as far as I understand it). I believe this bit of entropy is not a big deal given that there are far more than one [1].
>>>> However, do we care about that? do we want to make it impossible for any consumer of Battery Status API to know if the device has a battery? If we don't, we should probably add an attribute that makes this more obvious like navigator.battery.hasBattery.
>>>
>>> It's a trade-off. I think that 1) Battery is useful, 2) one bit isn't much, and 3) shielding this behind a doorhanger makes it close to useless.
>>
>> I tend to agree. Then, shall we add an attribute to the BatteryManager object that explicitly says if there is a battery in the device?
>
> DOM API has had hasFeature() and isSupported() for quite some time, but AFAIK the methods are not widely used (for various reasons). Also, no existing [device-ish] web platform APIs come to my mind that have .has*.
>
> I think authors would still go with the established practice of feature detecting based on functional parts of the API (see e.g. [1]) instead of relying on the .hasBattery.
>
> I would like us to understand the issue a bit better before committing to .hasBattery.

My suggestion wasn't to add a feature detection method but a way to know 
if the device has a battery. Knowing if the Battery API is enabled in 
the UA should be as simple as ("battery" in navigator) but knowing if 
the device has a real battery is harder. As I said, our current API 
allows that in an unintuitive way: (battery.chargingTime === Infinity && 
battery.level === 1.0) [1][2].

What I propose is to add an attribute (I don't care about the naming) 
that would let authors to know more explicitly and simply if the device 
has a battery.
In one hand, that would prevent dirty hack like above when the Web App 
really needs to know if there is a battery. In the other hand, some 
authors might use it even when not needed like:
if (battery.hasBattery && battery.level < 0.5) {
   // do battery-saving stuff
} else {
   // do CPU-expensive stuff
}
The condition could have been |if (battery.level < 0.5)|.

However, I do not think there are a lot of use cases where knowing if 
the device has a battery is useful. Actually, the only one I see is for 
a Battery Widget/UI: it shouldn't draw a charging battery if there is 
actually no battery.
Taking this into account, maybe we could fix the current way to know if 
there is a battery (see [2]) and add an attribute that will return if 
there is a battery but hide it behind some kind of security/permission. 
That way, we could hope authors will not try to read that when they 
don't need it and apps that really need it will ask for it. Though, it 
might be worse if authors uselessly read the attribute en masse.
Another solution would be to move this information to another API that 
would return system informations like if the device has a GPS, a WIFI 
connectivity, Bluetooth, etc.

[1] The condition I gave in a previous email was actually not always 
correct.
[2] We could probably prevent this by always returning chargingTime = 0 
if there is no battery. Actually, that might be a better behavior.
--
Mounir

Received on Monday, 21 November 2011 11:45:55 UTC