Re: Privacy review of the Remote Playback API - comments

Adding Simon Rice to the recipients list.

On Thu, May 11, 2017 at 2:06 PM Anton Vayvod <avayvod@google.com> wrote:

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