- From: Anton Vayvod <avayvod@google.com>
- Date: Thu, 11 May 2017 18:06:59 +0000
- To: public-privacy@w3.org
- Cc: "mark a. foltz" <mfoltz@google.com>, Mounir Lamouri <mounir@lamouri.fr>
- Message-ID: <CAOjek6pPkA3FUuMnPWe6+eb-g2tKSRGzivEfnsMn3GqNPLbJdA@mail.gmail.com>
Hi, I'd like to clarify the comments we received for Remote Playback API and provide some feedback. See more inline: >Hello Simon, > >Thank you for reviewing the draft specification and providing these useful comments. Before we pass these on, does anyone else have something to add? > >Christine >> On 25 Jan 2017, at 2:08 pm, Simon Rice <Simon.Rice@ico.org.uk> wrote: >> >> Following the Chair’s request for comments I have three comments to raise: >> 1) In the section “Disabling remote playback”, consider to add the requirement that the monitoring of devices must not occur if the feature is disabled by the user, thus “If the disableRemotePlayback attribute is present on the media element, the user agent MUST NOT monitor availability, play the media remotely or present any UI to do so. The 'disableRemotePlayback' attribute is not a user setting, it's a way for a website to inform the user agent that this media must not be played on a remote playback device (for quality reasons, for example). Even if the attribute is set on all the media elements loaded in the browser session, monitoring of remote playback device availability can continue when there are other reasons to do so. For example, if monitoring queries the network infrequently,y, stopping monitoring means the user will later waits too long before the device is rediscovered. Or, monitoring can be required for other features to work, like mirroring the whole page contents to the same type of device. If the user disables remote playback and/or availability monitoring through a global browser setting, the user agent should pause availability monitoring; however I don’t think that should concern the spec as long as the browser behavior doesn’t break the pages using the Remote Playback API. The spec will recommend reporting false availability via the registered availability callbacks and keeping the callbacks set for consistency [1]. >> >> 2) It is unclear if the callbackId is derived from a unique identifier on the Callback device (e.g. a hash value of a MAC address). Is there any reason why this could not be generated for each session by the UA? It would still be unique across all callback devices on the network but different devices on the same network could have a different set of unique devices and thus reducing the potential for device fingerprinting. Could you please clarify what you refer to as a "Callback device" here? The callback id is an integer returned by watchAvailability() that can only be used with cancelWatchAvailability() later to unregister the callback. It's the same as the value returned by watchPosition() in Geolocation API [2] WebNFC's NFC.watch [3]. It doesn't have anything to do with a remote playback device; in fact, it can't as it is returned before availability monitoring begins and any device is discovered by the user agent. >> >> 3) Does the RemotePlaybackAvailabilityCallback object include a human-readable name to identify the Callback object? E.g. “kitchen speaker”, “bedroom TV”, “Medical device”? Would this also be exposed outside of the UA? Privacy implications would vary depending on where this human-readable name is disclosed, if any. The callback is defined as `void (boolean)` [4]. It is basically a function that can be provided to the user agent to be invoked and it only provides one bit of information. See the section titled Personally Identifiable Information [5] in the spec for details. >> >> Simon >> >> >> The ICO's mission is to uphold information rights in the public interest. To find out more about our work please visit our website, or subscribe to our e-newsletter at ico.org.uk/newsletter. >> >> If you are not the intended recipient of this email (and any attachment), please inform the sender by return email and destroy all copies without passing to any third parties. >> >> If you'd like us to communicate with you in a particular way please do let us know, or for more information about things to consider when communicating with us by email, visit ico.org.uk/email Hope this answers the questions you had while reviewing the Remote Playback API. Thank you for taking the time to review it and let us know if you have anymore questions, Anton, Mark & Mounir [1] https://github.com/w3c/remote-playback/issues/84 [2] https://dev.w3.org/geo/api/spec-source.html#watch-position [3] https://w3c.github.io/web-nfc/#dom-nfc-watch [4] https://w3c.github.io/remote-playback/#remoteplayback-interface [5] https://w3c.github.io/remote-playback/#personally-identifiable-information
Received on Thursday, 11 May 2017 18:07:44 UTC