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

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. 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.
 
CEA-2014-B leaves the topic of password generation open so an auto-PIN implementation is not precluded.
 
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.
 
Regards,
Russell Berkoff
Samsung Electronics

________________________________

From: public-web-and-tv-request@w3.org on behalf of Giuseppe Pascale
Sent: Fri 4/29/2011 8:22 AM
To: public-web-and-tv@w3.org
Subject: Re: webtv-ISSUE-3: Security concerns around Home Networking APIs [HOME_NETWORK_TF]



Russell, thanks for your feedbacks, see my comments inline

>
> [Samsung] Security/Privacy for UPnP/DLNA HN devices was a significant 
> concern during the development of CEA-2014-B(Remote UI).
> The following measures were implemented:
>
> 1. By default pages that accessed HN devices were opened in "sandbox" 
> mode where access to services such as cookies, XHR and Forms that could 
> be used to upload information outside the home were restricted. The page 
> could detect if the browser was in this mode. The UA could designate 
> "trusted" domains where HN pages were permitted full access to UA 
> facilities.
I'm not sure I understand the need of the sandbox. As I see it, there are 
2 cases:

- before I trust an application, it should get no access to other HN 
devices so there should be no need to restrict access to cookies etc. 
(since no information should be exposed to the app)
The usecase would be basically the same as browsing any web age from your 
PC/TV/Mobile

- after I trust an application to communicate with a specific device (not 
with all the home network devices) I don't need the sandbox anymore. Or do 
you have 2 levels of trust?

But maybe I'm missing something here, so if you can clarify it to me that 
would be great.

> 2. HN devices were protected by user-assigned passwords that were 
> stored/managed by the UA. Pages accessing HN devices would be required 
> to provide the correct password to the UA before it would "unlock" page 
> access to HN Methods. Note some methods were non-password protected to 
> allow basic device discovery to take place. The UA was required to 
> expire passwords in which case the page would need to resubmit password 
> to continue to have access to the device.

This seems to be more or less covered by my current proposal (do you 
agree?).
I have some questions on this though:

- letting the password expire seems a good thing from a security PoV but 
could be bad from a usability PoV.
Unless you allow the UA to store the PW and enter it for you (like it is 
currently done on the web for login forms)
How does this work for the UPnP/DLNA case? (I guess DLNA/UPnP only gives 
recommendation on this anyway, isn't it?

- you talk about a user defined password. I think the idea from BBC UC 
spec about an auto-generated PIN is also interesting.
Is this something that was never considered or it was considered and 
excluded?

/g

> On Wed, 20 Apr 2011 17:34:21 +0200, Web and TV Interest Group Issue 
> Tracker <sysbot+tracker@w3.org> wrote:
>
>>
>> webtv-ISSUE-3: Security concerns around Home Networking APIs 
>> [HOME_NETWORK_TF]
>>
>> http://www.w3.org/2011/webtv/track/issues/3
>>
>> Raised by: Giuseppe Pascale
>> On product: HOME_NETWORK_TF
>>
>> (re-posting for tracking purposes according to the new procedure; 
>> previous discussion available at [1]. Please reply to this thread if 
>> you have any comment)
>>
>>
>> Hi all,
>> we have discussed in several places (workshop, this mailing list, etc) 
>> how
>> important it is to address privacy and security concerns around  Home
>> Networking Technologies.
>>
>> In order to trigger some discussion, I started a new document about
>> Security.
>> The idea behind this document is to collect all reasonable concerns and 
>> a
>> list of possible solutions.
>> I don't think is in the scope for this TF to decide on one solution, 
>> but I
>> think would be valuable if this group could come up with an analysis 
>> and a
>> list of suggestion for a WG to work on.
>>
>> The document is as usual available on the wiki
>>   http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/Security
>>
>> I'm sure there are more things that can be written, so feel free to
>> comment on it and propose extensions or corrections to it.
>>
>>
>> [1] 
>> http://lists.w3.org/Archives/Public/public-web-and-tv/2011Apr/0118.html
>>
>>


--
Giuseppe Pascale
TV & Connected Devices
Opera Software - Sweden