Re: CfC: Battery Last Call

Hi Mounir,

On Nov 17, 2011, at 16:57 , Mounir Lamouri wrote:
> There are two kind of information that are leaked:
> 1. Insensitive information like current level of battery, whether the battery is charging or not and when the battery is going to be charged/discharged. There is only one way to use these information against the user: having a malicious website trying to drain your battery that would now know if it's worth trying. We can then consider this information as not sensitive because the website could just try to drain your battery every time and not care about you have or not a battery. I don't think we should care that much about this.

I don't think that this is an issue. A malicious website could indeed do that already (and a lot of non-malicious ones already do...).

> 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.

The more I mull over fingerprinting, the more I think that browsers should be able to detect it. If a website starts accessing a zillion different properties from font list to the presence of battery, you can guess that something fishy's going on. The centralise the information as is done for phishing and offer to block such sites (or better still, return fuzzy data).

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Thursday, 17 November 2011 16:07:45 UTC