Re: [light, proximity] Proposed privacy considerations text for Proximity Events and Ambient Light Events specs

Hi Frederick, PING participants,

On May 20, 2013, at 5:27 PM, Frederick.Hirsch@nokia.com wrote:

> Thanks Nick, some comments in line, prefixed by <FH>.
> 
> I also include a proposed update to the privacy considerations text as well as proposed changes to the normative event sections that will require some WG agreement.
> 
> A. Here is update to the privacy considerations text.
> 
> The following proposed text is common to both specifications, apart from the part marked [SPECIFIC] which should be replaced with the specific text that follows.
> 
> Proposed Common text:

[...]

Frederick - thank you for your proposal.

I've updated both the specs' "Security and privacy considerations" sections as per your proposal:

  https://dvcs.w3.org/hg/dap/raw-file/default/proximity/Overview.html#security-and-privacy-considerations

  https://dvcs.w3.org/hg/dap/raw-file/default/light/Overview.html#security-and-privacy-considerations

Changeset:

  https://dvcs.w3.org/hg/dap/rev/7bca576bd37a

All - please take a look at the editor's drafts above and let us know if you have any comments or concerns.

> B. Here is proposed normative text to add related to events (refer to editors drafts)
> 
> Proximity section 5.1
> 
> change
> "When the current device proximity changes, the user agent must queue a task to fire a device proximity event at each browsing context's Window "
> 
> to
> [[ When the current device proximity changes, the user agent must queue a task to fire a device proximity event at the browsing context's Window. Note that the implementation SHOULD NOT fire a device proximity event in multiple browsing contexts to avoid the privacy risk of correlation of context information.  For example, a mobile device might only fire proximity event for the active "tab". ]]
> 
> Likewise for light in section 5.1
> 
> change
> "When the current light level changes, the user agent must queue a task to fire a device light event at each browsing context's Window."
> 
> to
> 
> [[ When the current light level changes, the user agent must queue a task to fire a device light event at the browsing context's Window. Note that the implementation SHOULD NOT fire a device light event in multiple browsing contexts to avoid the privacy risk of correlation of context information.  For example, a mobile device might only fire light event for the active "tab" . ]]
> 
> I guess we need to be clear whether it makes sense to have the event for multiple windows vs the privacy consideration.
> 
> What do others think?


Your proposal seems to be aligned my initial proposal [1]. Back then, I did not receive comments from others than Anne [2], so I guess people are fine with this change.

Some comments: I think that "s/at the browsing context's Window/at the top-level browsing context's Window object/" may be more precise. We may also want to make "Note that ..." a non-normative note. I also amended the language in the note a bit.

Here's the updated text with the above changes (using device proximity as an example):

[[

When the current device proximity changes, the user agent must queue a task to fire a device proximity event at the top-level browsing context's Window object.

[ NOTE ]: The device proximity and user proximity events are only fired in the top-level browsing context to avoid the privacy risk of sharing the information about proximity with contexts unfamiliar to the user. For example, a mobile device will only fire these events on the active tab, and not on the background tabs or within iframes.

]]

I plan to update the specs within a week as outlined above should I not hear any concerns.

FWIW, I also proposed an alternative approach ("fire [...] at any nested browsing context's Window object whose Document object has the same origin as the top-level browsing context's Document") [1] which would allow the events to be fired also within iframes and frames sharing the same origin with the top-level browsing context's Document. Did PING consider this alternative?

PING participants - thanks for reviewing the specs.

-Anssi

[1] http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0084.html
[2] http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0085.html

Received on Tuesday, 21 May 2013 09:19:33 UTC