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

Anssi

Thanks, two minor nits that should be corrected in each document for the security & privacy considerations section.

In 1st paragraph, s/Privacy threats can arise/Privacy risks can arise/

in 3rd paragraph, s/JavasScript/JavaScript/


https://dvcs.w3.org/hg/dap/raw-file/default/light/Overview.html

https://dvcs.w3.org/hg/dap/raw-file/default/proximity/Overview.html

thanks

regards, Frederick

Frederick Hirsch
Nokia



On May 21, 2013, at 5:18 AM, ext Kostiainen, Anssi wrote:

> 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 Thursday, 23 May 2013 15:04:36 UTC