Re: HbbTV 2.0 Specification Announcement

Hello Francois,

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

This is a very good point. I have less familiarity with the security side of W3C specifications. Based on what you have referenced, I agree with your interpretation.

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

Thanks for the reference, I'll read it properly, but after a first glance through, my initial question would be how to keep the password secret if (presumably) it would be provided by the HTML application?

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


Agreed, this is a more general issue that if you are establishing communication with another entity, how can you trust that other party on the home network? You might send a request that they load a particular URL but you take it on trust that they do. You could argue that any communication via the messaging API in the presentation API is cannot be trusted.


--
| Matt Hammond
| Senior Research Engineer, BBC R&D, Centre House, London
| http://www.bbc.co.uk/rd/


> On 17 Apr 2015, at 16:17, Francois Daoust <fd@w3.org> wrote:
>
> 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



-----------------------------
http://www.bbc.co.uk

This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

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