- From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
- Date: Mon, 21 Nov 2011 13:14:27 +0200
- To: public-device-status@w3.org
Hi, 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. -Anssi [1] http://www.modernizr.com/
Received on Monday, 21 November 2011 11:14:58 UTC