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

Hi Anne, All,

On 1.12.2011, at 10.21, ext Anne van Kesteren wrote:

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

Updated proposal:

[[

When the battery charging state is updated, the user agent must queue a task which sets the charging attribute's value and fires a simple event [HTML5] named chargingchange at the BatteryManager object.

When the battery charging time is updated, the user agent must queue a task which sets the chargingTime attribute's value and fires a simple event [HTML5] named chargingtimechange at the BatteryManager object.

When the battery discharging time is updated, the user agent must queue a task which sets the dischargingTime attribute's value and fires a simple event [HTML5] nameddischargingtimechange at the BatteryManager object.

When the battery level is updated, the user agent must queue a task which sets the level attribute's value and fires a simple event [HTML5] named levelchange 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.
> 
> 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).

I dropped this given the relevant bits are now baked in to the above explicit conditions.

>>> 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.
> 
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=14916

I added the following to the Conformance section:

[[

The Function interface represents a function in the scripting language being used as defined in [HTML5].

]]

Would that do the trick? I'm looking for the path of least resistance here :)

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

You're right, I was probably exaggerating the privacy threat. Here's the updated proposal:

[[

The API defined in this specification is used to determine the battery status of the hosting device. This information discloses battery related information, which has minimal impact on privacy or fingerprinting, and therefore is exposed without permission grants.

]]

Thanks again!

The diff to LC#1:

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

The latest ED:

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

-Anssi

Received on Thursday, 1 December 2011 11:22:17 UTC