Re: [all] [HNTF] Opera's device discovery proposal?

Many thanks for pointing this out Kazuyuki, it looks very interesting.



On Fri, 15 Jul 2011 06:55:16 +0100, Kazuyuki Ashimura <>  

> Hi group, esp. the HNTF,
> I've found an interesting proposal by Rich Tibbett from Opera on local
> device discovery that was sent to the Device APIs public mailing list
> [a and below].
> Here he points out several issues with the existing approaches, e.g.,
> CORS [b, c], and proposes a new idea named "Local Network Service
> Messaging" [d].  Also he mentions our Use Case discussion within the
> HNTF in his message below.
> So I was wondering if you all were aware of this proposal, and would
> ask you for opinion about this.
> Please note that Rich's disclaimer saying:
>> Disclaimer: This API proposal does not represent the consensus of any
>> standards group and should not be referenced as anything other than an
>> unofficial draft which is a work in progress.
> [a]  
> [b]
> [c]
> [d]
> Thanks,
> Kazuyuki
> [ Rich Tibbett from Opera <> ]
>> A number of devices connected within a local network today advertise
>> service API endpoints to the network, the primary purpose of which is to
>> allow other devices within the same local network to connect, control
>> and interact with those services through the provided interfaces.
>> It is possible today to build native applications that can both discover
>> and communicate with such local-networked services. There is currently
>> no standard or, indeed, any particularly easy way to discover or
>> interact with local devices and services from a web application without
>> significant technical hackery on the part of the user (see 'current
>> practice' below).
>> We need a way for a user agent, acting as a broker between a user and a
>> web application to discover services via common discovery protocols
>> (i.e. SSDP and DNS-SD) within the local network, allow web applications
>> to request a particular service type (or class of service) that it
>> wishes to interact with and then for a user to authorize that
>> connectivity based on services found in their local network matching the
>> requested service type. The solution should then enable communication to
>> occur between the authorized web application and the local-networked
>> service, bypassing or overriding the same-origin policy rule if
>> necessary to allow for safe and secure cross-domain communication.
>> Assuming the user is able to obtain a local-networked service's host and
>> port information, which in itself is a hard task for both technical and
>> non-technical users alike, the user must then provide that host and port
>> information to the web application by entering such information in e.g.
>> a web form and submitting said form. Having got this far the web
>> application, despite having all the information required to communicate
>> with a local-networked device/service, is then likely to encounter
>> another issue, namely the same-origin policy rule which prevents a web
>> application from communicating with a networked device that does not
>> share the same host and port origin combination as itself.
>> As a solution to this, CORS has been developed to enable cross-origin
>> messaging from web applications. Within the home network, if the target
>> networked device happened to provide the HTTP header
>> [Access-Control-Allow-Origin: *] then there is little problem with the
>> browser now being able to communicate with the provided host and port.
>> However, the majority of local-networked services do not implement CORS
>> and because [Access-Control-Allow-Origin: *] is generally a bad idea to
>> enable within a local network, it is not really the ideal future-facing
>> solution within local networks to ensure access is granted only to web
>> applications that a user has explicitly authorized access to.
>> In the vast majority of use cases (from e.g. [1]) communication from a
>> web application to a local-networked service is blocked or inherently
>> insecure today due to one or more of the issues above being present in
>> modern web browsers.
>> The current practice therefore does not fulfill the requirements of the
>> initial problem and so we began to consider alternative approaches.
>> To counter the issues identified in the current practice above we
>> developed a low-level API, produced incrementally over the course of the
>> last few months, that allows a web application to request a particular
>> service type (or class of service type) and for the user to then be able
>> to authorize and connect a discovered matching service to the requesting
>> web application. This enables a user-authorized web application to
>> control, interact and synchronize content (and otherwise generally
>> communicate) with home-networked services, negating the operational
>> issues present in browsers today.
>> The proposed solution is available, in its full form, here:
>> A note on CORS: this API is intended to work with or without CORS
>> support enabled in local-networked services. That is to say, CORS in
>> combination with e.g. HTTP authentication schemes, assuming such a model
>> is deployed widely in the future, may provide a good user authorization
>> model for this API (perhaps even to the point of negating the need for
>> any specialized Service Discovery user interfaces at all). As it stands,
>> the proposed solution is intended to work with existing services
>> deployed within local networks without shoe-horning all communications
>> in to a future-only CORS model.
>> Opera plan to produce an experimental implementation of this API in the
>> coming weeks and I plan to keep this group updated on its progress.
>> In the mean time, you can provide any feedback on this proposal at
>> I hope we will also see other API proposals
>> submitted to this group in the coming months.
>> Disclaimer: This API proposal does not represent the consensus of any
>> standards group and should not be referenced as anything other than an
>> unofficial draft which is a work in progress.
>> Best regards,
>> Rich Tibbett
>> [1]

| Matt Hammond
| Research Engineer, BBC R&D, Centre House, London

Received on Friday, 15 July 2011 07:12:18 UTC