- From: Francois Daoust <fd@w3.org>
- Date: Mon, 20 Apr 2015 14:13:14 +0200
- To: Matt Hammond <Matt.Hammond@bbc.co.uk>
- CC: "public-secondscreen@w3.org" <public-secondscreen@w3.org>
On 2015-04-17 17:42, Matt Hammond wrote: [...] >> 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. I was more pointing at that mechanism as food for thought :) > >> 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. Perhaps! It might also be useful to look at WebRTC that enables a similar "communication with another entity" feature. The latest draft of the WebRTC security architecture forbids plain (unencrypted) data and media traffic altogether: https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-11#section-5.5 Francois.
Received on Monday, 20 April 2015 12:13:23 UTC