[Privacy] Adds notes clarifying behavior to address privacy review.

[markafoltz]

Addresses:

• Issue [Privacy] Request to disable monitoring when disableRemotePlayback is set #80: [Privacy] Request to disable monitoring when disableRemotePlayback is set
• Issue [Privacy] Clarify steps to generate callbackId #81: [Privacy] Clarify steps to generate callbackId
• Issue [Privacy] Clarify that availability callback does not include human readable names #82: [Privacy] Clarify that availability callback does not include human readable names

@avayvod @mounirlamouri PTAL

[avayvod]

nit: I think this example implies the callback ids must be unique across all the media elements within a browser session which is not true. They only must be unique for each media element alone. An example is a counter in the media element's scope, that's set to 0 when the media element is created and is incremented each time its value is returned by watchAvailability() for this particular element as the callback id.

[markafoltz]

That seems inconvenient if a page is watching availability on multiple elements and wants to keep the callbacks in a Map or otherwise track the set of callbacks by id.

[avayvod]

Fair point. It might be more likely having one callback per many elements compared to many callbacks for a single element. The spec doesn't guarantee any cross-element uniqueness of the ids at the moment though.

@jernoble @mounirlamouri WDYT?

[markafoltz]

It seems like this requires discussion in a separate issue. I'll remove the example from this PR and suggest it separately.

[avayvod]

nit: accidental whitespace?

[markafoltz]

Fixed.

[avayvod]

This seems broken if the last known information was that the availability is true. Also, there's no way for the pages to know the callback ids became invalid. I think in this case the UA should just report the availability as false and stop reporting availability through the callbacks.

[markafoltz]

I think this is an issue with the steps to disable remote playback. It clears the callbacks and does not invoke them with false before doing so.

[avayvod]

I'm not sure about the use of should and will here. If we're defining the behavior in the response of a user setting, MUST would be preferred (by the definition of the user agent). However, we don't spec browser settings here and it's just a note.

Maybe something like "The user agent MAY at any time stop monitoring the list of available remote playback devices if the user disables remote playback (for example through a browser setting). In this case the availability callbacks MUST be fired with false and their ids will remain valid however they MAY never be fired again." is more focused on the API?

[markafoltz]

Rephrased as suggested. However disabling remote playback doesn't fire any callbacks as noted above.

[avayvod]

In such a scary (to web authors) scenario I think firing the callbacks with availability set to false if needed would be nice.

[markafoltz]

I think the normative part of the spec should then describe the behavior of stop monitoring the list of remote playback devices. I'll drop the last sentence and file this as an enhancement.

[anssiko]

@avayvod it looks like this could be merged, since @mfoltzgoogle addressed your comments.

Should land this PR that addresses the privacy review feedback prior to CR #73.

[markafoltz]

I've updated it to no longer mention disabling remote playback to avoid any confusion with the disableRemotePlayback attribute.