Re: Privacy review of the Remote Playback API - comments

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