Network Service Discovery API

Dear Colleagues,

I am working for LG Electronics as a standards representative, and we would like to share a few thoughts on the Network Service Discovery API. First of all, we appreciate and welcome the effort that is going into it. In the consumer electronics domain, UPnP is implemented in many - if not most - devices. From our point of view, enabling access to device discovery is hence an essential enabler for Web technologies in consumer electronics. We are therefore closely watching the development of the Network Service Discovery API, in general, and its degree of support for UPnP.

In this context, I would like to share my thoughts on two areas with you.


Topic 1: Security and Privacy (ISSUE-154)

To raise the bar for malicious web apps, I would envisage the following:

(1) Obscure all information about the device *except* the friendlyName by replacing it with a per-session hash value before exposing it to the web app. That way it will not be possible to infer information that would potentially help in figuring out exploits (IP address, model, make, etc.), but if anything were to go back to the device, the NSD APU implementation would still be able to map it back to the actual values before sending to the device or searching the data. friendlyName is required, because the web app should be able to present the user a choice of devices to use (e.g. to select on which printer to print).

(2) Make it a request model. I.e. instead of offering a list of available services, have the web app query for each service type it knows about. If the app only knows about printers, there is no point in telling it that there is a media player available.

(3) Make it a user consent model like the Geolocation API ("Do you want to allow company.com to connect to devices on your network?"). CORS is not a solution IMO, since the company.com server will of course always allow all its web apps to access my devices. It's only and exclusively the end user to decide.


Topic 2: Accessing UPnP Enhanced Features and Extensions

In the frame of our standards activities in UPnP and consumer electronics standardisation, we are also involved in defining new UPnP device and service definitions, and also extensions to UPnP. All these serve the purpose to make enhanced device features - like e.g. second screen functionalities - accessible to web applications.

In the context of the security considerations (cf. topic 1 above) one of the options is removal of the config property. From a security/privacy standpoint this is a sensible approach. To enable access to special features and private extensions, we would envisage some sort of query API for getting at those parts of the device/service description. Searching for all elements from a specific xmlns (if the description is Schema based), or just for a substring (e.g. to retrieve all <X_ABC_...> elements) would come to mind.


Looking forward to your comments,

 --alexander adolf

Received on Wednesday, 12 February 2014 14:17:20 UTC