Request for a TAG review of the Presentation API

Good morning TAG,

The Second Screen Working Group would like to solicit the TAG for 
feedback on its Presentation API specification, which enables web 
content to access external presentation-type displays and use them for 
presenting web content:

  http://www.w3.org/TR/presentation-api/

  (latest version published today, see [1] for the latest editor's draft)


While the spec has matured over the last few months, it should not be 
regarded as final yet. For instance, the group anticipates changes to 
names and API structure to separate the controlling and presenting 
sides, which will result in two classes of product (presenting and 
controlling) being defined. Functionality should not change though.

The group would like to draw the TAG's attention to a few specific 
issues, which I attempted to summarize below (in no particular order) 
with links to relevant discussions. The list is also available under the 
"TAG" label on the group's issue tracker [2]. Feel free to comment on 
GitHub.

Please note that the group will also ask the Privacy IG and the Web 
Security IG for feedback on the issues that are also relevant to them.


1. Security requirements for the messaging channel
-----
The Presentation API is agnostic of the protocol used for the messaging 
channel as long as it is capable of carrying DOMString payloads in a 
reliable and in-order fashion. A user agent could perhaps communicate 
with the second device using the WebSockets protocol or a WebRTC data 
channel.

However, when the controlling page is loaded in a secure context, the 
spec should set some guarantees of message confidentiality and 
authenticity ("only secure WebSockets"). Do you have suggestions on ways 
to specify security requirements in a generic manner?

See relevant discussion in:
https://github.com/w3c/presentation-api/issues/80


2. Private mode browsing for the presenting context
-----
While the controlling device will be a "private" device, the presenting 
device will often be a "shared" device, perhaps a TV set or HDMI dongle 
in a household, or a remote screen in a meeting room. To protect the 
controlling user's privacy, the group would like to require the 
presenting user agent to load the presentation URL in private mode.

The group notes the work done by the TAG to define Private Mode Browsing 
[3]. Would private mode browsing be an appropriate requirement for the 
Presentation API? What is the status and plan for the TAG's draft? In 
particular, can the group reference it from the Presentation API 
specification?

See end of discussion in:
https://github.com/w3c/presentation-api/issues/45


3. Fingerprinting and screen availability monitoring
-----
There is no good fallback for the Presentation API in the case when 
there are no screens available. To ensure a good user experience, a web 
page must be able to tell whether a request to "startSession" is likely 
going to succeed before it offers the user the choice to present. That 
is the role of the "getAvailability" function.

Without parameter, this function de facto reveals one bit of information 
on the user's context that could be used for fingerprinting, although 
this information will change depending on the user's context (on the go, 
with TV on/off, etc.).

The group notes that a generic true/false is not enough in many 
situations where the URL to present may require additional capabilities. 
That is the reason why the "getAvailability" function takes the URL to 
present as parameter, to allow the user agent to filter screens.

See relevant discussion in:
https://github.com/w3c/presentation-api/issues/9


4. Dealing with legacy content
-----
One use case for the API is when a video/slideshow player embedded in an 
iframe wants to project the content to a second screen. The group 
explored to possibility to add an "allowpresentation" attribute to 
<iframe> in a similar vein as for the FullScreen API. However, this 
would de facto require millions of existing page that embed such players 
to update.

The group now wonders whether it could rather extend the semantics of 
the "allowfullscreen" attribute or leave it up to the user agent to ask 
for user's consent.

See relevant discussion in:
https://github.com/w3c/presentation-api/issues/79


5. Presenting the content of an <audio> or <video> element
-----
This is more FYI than a real question. A main use case that the group is 
to enable is the presentation of audio/video content on a second screen. 
The group thinks that the Presentation API is not a good fit for that 
use case, as a communication channel between a presenting context and a 
video does not mean anything.

Instead, the group proposes to extend the HTMLMediaElement interface 
with a "remote" attribute. The main benefit of this approach is that 
application developers can then reuse the usual methods and properties 
exposed by the local HTMLMediaElement interface to control the video 
playback (play, pause, currentTime, playbackRate, etc.) on the remote 
screen.

See relevant discussion and current proposal in:
https://github.com/w3c/presentation-api/issues/13
https://github.com/avayvod/remotehtmlmedia/blob/master/proposal.md


6. Security and privacy considerations
-----
The group would also like to draw the TAG's attention to the overall 
security and privacy considerations section in the spec, noting for 
instance that the API will not in itself allow the presenting page to 
identify the provenance and origin of incoming messages (no "origin" in 
a cross-device situation) and that the API will allow multiple 
controlling pages to connect to a single presenting context.

See evaluation in:
https://github.com/w3c/presentation-api/issues/45



Thanks,
Francois Daoust, Staff Contact
Second Screen Presentation Working Group

[1] http://w3c.github.io/presentation-api/
[2] https://github.com/w3c/presentation-api/labels/TAG
[3] http://w3ctag.github.io/private-mode/

Received on Wednesday, 1 July 2015 09:56:09 UTC