Re: HbbTV 2.0 Specification Announcement

Hi Matt,

On 2015-04-08 15:05, Matt Hammond wrote:
[...]
>> I don´t know why Launching Broadcast Independent Applications from Companion Screens using only the URL of the HTML document is no supported ☹.
>
> I hope I've argued that in practice it is.
>
> <mhp:appId> and <mhp:orgId> are, however, important for certain HbbTV specific actions that an application may wish to take. The following is an example Use case showing one way in which we (and other broadcasters) might wish to use this presentation API:
>
> 1. The User is browsing the broadcaster's website on a phone/tablet/PC giving information about a TV show being broadcast right now.
> 2. The User also sees a button is available to start viewing on the TV.
> 3. The User presses this button, causing an HTML app to be launched on the TV.
> 4. The HTML app on the TV uses HbbTV specific functionality to convert itself from a "broadcast independent" app to a "broadcast related" app and is therefore able to tune to the required live TV broadcast channel.
>
> For this to work, <mhp:appId> and <mhp:orgId> values (as well as the URL) must match the values carried in the broadcast signalling.

Another aspect that I noted while reading the HbbTV 2.0 specification: 
since the WebSockets server that the HbbTV device embeds runs on a local 
IP address on the local network and thus cannot expose a proper TLS 
certificate chain, there is no way to establish secure Websockets 
connections with the device (see Note 1, p182 in the HbbTV 2.0 spec). In 
your example use case, what would happen if the User is browsing the 
broadcaster's website using HTTPS?

For instance, the WebSockets API prevents the establishment of non 
secure WebSockets connections from secure origins as far as I can tell 
(see step 2 in the description of the WebSocket constructor in [1]) and 
possible changes to that step introduced in the Mixed Content spec [2] 
do not relax that constraint if I read them correctly.

The Second Screen Presentation Working Group charter notes that the 
"establishment of a messaging channel between the two parties, including 
message addressing, security and authentication" is out of scope but I'm 
not sure how we can totally ignore security in practice. If the origin 
is secure, I would expect the communication channel to be "secure" as 
well, so that no one can eavesdrop.

Note that there may be ways for a user agent to establish a secure 
communication channel with a device, for instance following a similar 
mechanism to that described for the Named Web Sockets proposal [3].

I do not know how this could work for existing devices, though. Did I 
miss something obvious? Is there a simple solution?

I'll create an issue on GitHub to track this down otherwise. This is not 
specific to HbbTV.

Thanks,
Francois.

[1] http://dev.w3.org/html5/websockets/#websocket
[2] 
https://w3c.github.io/webappsec/specs/mixedcontent/#websockets-integration
[3] 
https://github.com/namedwebsockets/networkwebsockets/wiki/Introduction-to-Secure-DNS-based-Service-Discovery-(DNS-SSD)#secure-communications-channel-establishment-between-channel-peers

Received on Friday, 17 April 2015 15:17:46 UTC