W3C home > Mailing lists > Public > public-device-apis@w3.org > December 2011

Re: Battery Status API Last Call Feedback (LC-2574)

From: Anne van Kesteren <annevk@opera.com>
Date: Thu, 01 Dec 2011 09:21:17 +0100
To: "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>, "Anssi Kostiainen" <anssi.kostiainen@nokia.com>
Message-ID: <op.v5sxhrrx64w2qv@annevk-macbookpro.local>
On Wed, 30 Nov 2011 17:45:30 +0100, Anssi Kostiainen  
<anssi.kostiainen@nokia.com> wrote:
> [2] Proposal:
> When the user agent is to update the battery status, the user agent must  
> queue a task which sets the attribute's value and fires a simple event  
> [HTML5] at the BatteryManager object.

You should have such a phrase for each attribute (and name the event and  
attribute explicitly). And it should probably be phrased more like: "When  
the battery level is updated, the user agent must ..."

> Specifically, when the value of charging, chargingTime, level or  
> dischargingTime attribute changes, the user agent must fire a simple  
> event, which does not bubble and is not cancelable, named  
> chargingchange, chargingtimechange, levelchange or dischargingtimechange  
> respectively.

This does not work. The attributes do not change, the internal concepts  
change, which in turn cause the attributes to be updated by the user agent  
based on the task you queue. You also do not have to say "not bubble and  
not cancelable", those are the defaults (see DOM4).

>> You also need to actually define the various on* attributes as being  
>> event handlers and update their IDL to match the latest crazy IDL  
>> syntax (which might be simplified, so maybe you want to wait for that).
> Do you have a pointer at hand to this Web IDL discussion? Sounds  
> interesting.


> [[
> Security and Privacy Considerations
> The API defined in this specification is used to determine the battery  
> status of the hosting device. This information discloses whether the  
> device is running in battery mode, thereby it may potentially compromise  
> the user's privacy.
> ]]

I think you should say something along the lines that exposing battery  
related information has minimal impact on privacy and that therefore it is  
exposed without permission grants of some kind. And that there is some  
potential for fingerprinting, but again minimal. "Potentially compromise  
the user's privacy" sounds quite dangerous and if that in fact would be  
the case we should better protect it!

Anne van Kesteren
Received on Thursday, 1 December 2011 08:21:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:51 UTC