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

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

From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
Date: Wed, 30 Nov 2011 18:45:30 +0200
Message-Id: <69082D08-08EF-4C10-AE4C-7675F4571783@nokia.com>
To: ext Anne van Kesteren <annevk@opera.com>, "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>
Hi Anne, All,

On 29.11.2011, at 13.52, ext Anne van Kesteren wrote:

> The events need to be queued using the task queue defined in HTML5. It should probably be worded in such a way that the attribute is updated and the event is dispatched in the same task so nothing else can observe the attribute having changed before the event is dispatched.

See my proposal [2] below. Does it address your concern?

[1] LC#1:

[[

When the value of charging, chargingTime, level or dischargingTime attribute changes, the user agent must fire a simple event [HTML5], which does not bubble and is not cancelable, named chargingchange, chargingtimechange, levelchange or dischargingtimechange respectively at the BatteryManager object.

]]

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

]]

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

> Should there be some kind of privacy section? I guess you cannot tell much from someone charging his phone, but maybe in conjunction with other data you can find patterns of some kind. Fingerprinting is probably also somewhat aided by this functionality.

I think Mounir already addressed most of this concern. My initial proposal below.

All - please complement the privacy section with more specific examples:

[[

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.

]]

Here's the diff to LC:

  http://dev.w3.org/cvsweb/2009/dap/system-info/battery-status.html.diff?r1=1.70;r2=1.71;f=h

And the spec:

  http://dev.w3.org/2009/dap/system-info/battery-status.html

Thanks!

-Anssi
Received on Wednesday, 30 November 2011 16:46:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:24 GMT