Re: webtv-ISSUE-3: Security concerns around Home Networking APIs [HOME_NETWORK_TF]

Hi Russell,
some more brainstorming inline

On Mon, 02 May 2011 03:51:51 +0200, Russell Berkoff  
<r.berkoff@sisa.samsung.com> wrote:

> Hi Giuseppe,
> There are two distinct notions; I wasn't  very clear about the  
> distinctions:
> Security - Preventing unauthorized access. CEA-2014-B allows a limited  
> subset of  device discovery to take place to allow WebPages obtain  
> enough information to ask the end-user for a device password.
> Privacy - Preventing the unauthorized  transfer of information outside  
> of the home. The is similar to not allowing a guest in your home  
> unlimited access to your personal papers.

Agree about the split, in fact I did the same split in my document
  http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/Security#Security_issues

Actually, if you (or anyone else) have something more to add to that list,  
feel free to point it out.

> In many cases HN WebPages which are not overly inquisitive  can work in  
> restricted mode. If a WebPage needs to upload information, the end-user  
> should have the option to require pages to explicitly request the  
> end-user approve this kind of activity.

Agree in principle, but still not sure about the solution
***brainstorming here***

Looking at what usually happens, users tend to authorize whatever the  
application/device asks without reading carefully what he is asked to  
authorize.
This is my impression at list.

Someone could say: it's not our problem. But during the Berlin workshop a  
TV manufacturer explicitly said that this was a concern against this type  
of APIs.

So I think that the only way not to leak information is not to expose them.
That's why I'm wondering if it is really necessary to expose device  
information **at all**.
The only person that needs to know about the device info (e.g. in order to  
authorize a connection) is the user, and it could get this info via the UA.

The application could just be exposed to an opaque object that represents  
the device. On top of that additional mechanism to require the UA to show  
device details,
authorize connections etc would be needed.

This approach would solve the privacy issue #2 in my document [1]

In theory this could be applied also to content metadata but would  
probably be much more challenging to do this without disrupting the user  
experience.
I haven't given much thought about this though.

So in short I'm not saying that a sand box is something bad (and actually  
similar ideas can be found in W3C Widgets [2] and in html5 [3])
but I suspect author are not always aware of what the authorize.

Furthermore in some cases I may not trust the service provider even though  
I want to use some of his services (e.g. I want to watch content from  
Provider X) but I don't want to let him know which kind of device I have  
in my home network.


> Its a common-sense precaution to have UAs periodically revalidate their  
> submitted device passwords. The UA can determine the amount of time left  
> on a previously submitted password by using getLoginTimeRemaining().  
> It's fairly simple for the UA to schedule a timer event to refresh the  
> device login loginToDevice() prior to the expiration reported by the  
> method above.

Also in this case, what I'm wondering is not if these things should be  
enabled (it sound reasonable to have something like this) but from a  
security PoV I'm wondering if it wouldn't be better NOT to expose these  
info to the application but leave it to the UA (or the underlying  
protocol) to handle this to avoid leaking of information.


[1]  
http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/Security#Privacy
[2] http://www.w3.org/TR/widgets-access/
[3]  
http://dev.w3.org/html5/spec/the-iframe-element.html#attr-iframe-sandbox
-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software - Sweden

Received on Monday, 2 May 2011 16:45:33 UTC