- From: Giuseppe Pascale <giuseppep@opera.com>
- Date: Fri, 29 Apr 2011 17:22:10 +0200
- To: public-web-and-tv@w3.org
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
Received on Friday, 29 April 2011 15:23:15 UTC