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

Anssi

I believe your adjustments to the event text are an improvement, thanks. 

I think the simplicity of the top level browsing context window is preferable to including nested frames, unless there is a good use case for it, which we then should discuss. Thus unless we hear other discussion I'd say go with what you are currently proposing below.

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 Tuesday, 21 May 2013 12:27:53 UTC