- From: Francois Daoust <fd@w3.org>
- Date: Wed, 01 Jul 2015 11:55:55 +0200
- To: www-tag@w3.org
- CC: "public-secondscreen@w3.org" <public-secondscreen@w3.org>
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