RE: [discovery] DAP-ISSUE-131 Support UPnP device discovery by Device Type? (was RE: [discovery] Adding CORS to NSD API - proposal and issues)

Hi,

Comments inline.

> -----Original Message-----
> From: Cathy.Chan@nokia.com [mailto:Cathy.Chan@nokia.com]
> Sent: Friday, October 18, 2013 7:23 AM
> To: Youenn.Fablet@crf.canon.fr; richt@opera.com
> Cc: Igarashi, Tatsuya; public-device-apis@w3.org; giuseppep@opera.com
> Subject: RE: [discovery] DAP-ISSUE-131 Support UPnP device discovery by Device
> Type? (was RE: [discovery] Adding CORS to NSD API - proposal and issues)
> 
> > From: ext FABLET Youenn [mailto:Youenn.Fablet@crf.canon.fr]
> >
> > > If this remains an issue we are concerned about then perhaps this
> > > actually ties in with another security concern that has been raised
> > > recently: leaking network topology information in service endpoint
> > > URLs (e.g. providing http://10.0.2.34:4552/... allows a web page to
> > > infer the local subnet and can scan that subnet for
> > > vulnerabilities/other exposed services). I think we should start
> > > looking in to obfuscating these URLs per service when they are
> > > returned to web pages (something like
> > > 'http://127.0.0.1:5000/<serviceA_GUID>' or 'app://<serviceA_GUID>/'
> > > - TBD). One of the requirements of such a system would be that web
> > > pages should then not be able to infer or access other services
> > > being provided on the same device that have not been requested and
> > > authorized by the user (+ this solves the network topology
> > > leak/privacy
> > security issue raised elsewhere).
> >
> > This approach has some disadvantages though.
> > URL sharing is made more difficult (think about image browsing on
> > media box and then display on TV).
> 
> I would assume that such URL obfuscation will only be done (by the UA) on the
> service URL (controlURL of a UPnP service), and not on the content URLs
> exchanged between the service itself and the web app. The latter would require
> the UA to snoop on every single message exchange between the web app and the
> service and switch out the URLs. I don't think it is in the scope of this work
> to prevent URL leakage after the discovery phase. With that in mind, and seeing
> that there's a certain likelihood of URL leakage during the communication phase
> anyway (at least with services like ContentDirectory), I'm a bit skeptical on
> the usefulness of obfuscating the URL in the discovery phase.
> - Cathy.
>

Yes, what Cathy said is correct. ContentDirectory service exposes content metadata with content URL. They would contain IP address of the physical device which provide the ContentDirectory service. It means IP address of the physical device would be potentially leaked. 

If user agreement is required by UA before accessing service, such URL obfuscation in the discovery phase may make sense, but we have to consider trade-off between security/privacy and usability. I do not see a big requirement on supporting the URL obfuscation to avoid ip address leakage. It may be true that most consumers would use default ip sub-network of home router.

The example of ContentDirectory service also implies another aspect about the cross-site resource issue to get media contents from MediaServer.  CORS would be a solution to address the issue, I think.

-***---***---***---***---***---***---***---***---***--***---***---***-
Tatsuya Igarashi (Tatsuya.Igarashi@jp.sony.com)
Information Technology Development Div, R&D Platform
Sony Corporation

Received on Friday, 18 October 2013 09:52:48 UTC