W3C home > Mailing lists > Public > public-secondscreen@w3.org > July 2015

Re: Request for a TAG review of the Presentation API

From: Anne van Kesteren <annevk@annevk.nl>
Date: Wed, 1 Jul 2015 13:17:57 +0200
Message-ID: <CADnb78i4j=gNB8hb0qgM9YRQpVm1i3ygRSmzpHhgMQWpPLw=8w@mail.gmail.com>
To: Francois Daoust <fd@w3.org>
Cc: TAG <www-tag@w3.org>, "public-secondscreen@w3.org" <public-secondscreen@w3.org>
On Wed, Jul 1, 2015 at 11:55 AM, Francois Daoust <fd@w3.org> wrote:
> 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.

How can you leave this undefined? That would mean you don't have
interoperability across user agents and users would need to get all
their products from one vendor.


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

This seems hard since typically devices don't have a DNS name for
which you could issue a certificate.


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

How would this work for games? Games typically have large assets we
would not want to load anew each time you play. It would be pretty
disastrous if each time you want to do some gaming you have to wait a
couple of hours for all the assets to load on your TV.


-- 
https://annevankesteren.nl/
Received on Wednesday, 1 July 2015 11:18:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 1 July 2015 11:18:23 UTC