Re: Discovery API proposals: call for comments

> On Mon, 26 Sep 2011 08:57:57 +0200, N.V.Balaji <nv.balaji@samsung.com>  
> wrote:
>> From: "Dave Raggett" <dsr@w3.org>
>>
>>
>> I would also like to see a more generalized discovery and messaging  
>> mechanism that isn't limited to HTTP.  Why can't we allow web  
>> applications to discover and use services on devices connected by other  
>> interconnect technologies, e.g. USB, Bluetooth, Firewire, NFC and  
>> ZigBee?
>>
>> As an example involving NFC, imagine using a web application in your  
>> phone to display information about an object with an RFID tag, or to  
>> exchange information with someone by touching your phone to theirs, or  
>> to sign in to a website or to pay for an online purchase, by touching  
>> your phone to your notebook computer.
>>
I don't think our proposal is limited to HTTP, even though we may have  
provided binding only to HTTP based discovery protocols.
On the other end, I would like not to abuse the general architecture to  
handle in this way any sort of device/functionality.
In many cases you don't need to expose the device as service you want to  
communicate to, but more like an high level functionality that is  
available to the application, e.g. if you have a webcam or a USB disc you  
will use VideoConferencing APIs[1] or File API[2] for that.


>> Instead of providing a URL to access the service as with the  
>> getNetworkedServices proposal, the service object directly exposes the  
>> interface for accessing the service.
>
> [NVB]: That would mean that the interface JavaScript API should be  
> defined for each service type.  Pl. correct me if I am wrong.  Given the  
> enormity of this task (of defining APIs that can work over multiple  
> protocols and
> implementing them) it is better that we go for a simpler approach, even  
> if it is narrower in scope.
>
+1

Also: you don't need to have everything embedded into the browser. There  
are other technology layers you can use. For example (as in our proposal)  
you can build a JS library (or use an existing one) to simplify SOAP  
messaging with UPnP devices. So if the "low level" API allow to also  
experiment with possibly more highlevel API (written in Javascript) you  
achieve your goals and at the same time simplify the development and  
maintenance of such a feature.

Note the "low level" API is also used alone in some use cases, for example  
when you want allow 2 applications to communicate using their own protocol.

>> It is also worth distinguishing
>> discovery and binding, as users may want to view information about  
>> services before selecting which one to use.  This is a feature of the  
>> webinos API where you call the bind method on the discovered service to  
>> bind it.
>>
This is also supported in our API, but in a way that retain user privacy.  
The UA can expose all kind of information about that devices to the user  
to ask him to authorize the binding. But these should not be exposed to an  
application to avoid privacy issues. That is why we let the browse handle  
this part.

What an application usually ask for is something like "is there a TV I can  
use"? This is done with an approriate argument of getNetworkServices().  
Than the user can select which "TV" should be exposed to the application.  
Note that approval doesn't mean that from that point on everything is  
allowed. Certain information may still not be exposed to the application,  
and communication between devices will still be constrained by security  
mechanisms in place based on the type of communication protocol used.


>> Here is a typical scenario:
>>
>> 1. web page call findServices with service type and found, lost and  
>> error call backs
>>
>> 2. web page displays list of matching services where the list is  
>> dynamically updated via found and lost callbacks.
>>
We wanted to avoid the ability for the application to to this without the  
user allowing access to these devices.
Knowing that you have certain devices in the home is already a privacy  
concern (even if you cannot communicate with them)


>> The ability for web page scripts to scan your local environment is a  
>> risk to your privacy, and as such this must be subject to user control.
Indeed. This is enforce by the user agent.

>> Knowing about a service and being able to use it are two different  
>> things. This makes in necessary for users to further control which  
>> services a web page can bind to. Ensuring usability of such control is  
>> a challenge and should be beyond the scope of the discovery  
>> specification, although we should certainly be free to discuss what we  
>> feel to be good practices.
>>
Once you start exposing to an application information about available  
services you are already putting the user at risk.

>> Note that an alternative to the above would be to hand the task of  
>> presenting the list of services and binding to a service selected by  
>> the user over to the browser.
A middle group is allow the user to ask for specific type of services (not  
all of them) and having the user to authorize from that list. Note: not  
which one to talk to, but which one to expose to the application.


>> The web page script would in essence be limited to seeding the search  
>> parameters and requesting the browser to ask the user to make a choice.
>>
>> 1. web page calls getService with service type and success/failure  
>> callbacks
>>
>> 2. getService returns immediately with a handle that can be used to  
>> remove the selection UI
>>
>> 3. browser displays the service selection UI with a dynamically updated  
>> list of services
>>
>> 4. user clicks on chosen service or on cancel button
>>
>> 5. web page call back invoked with service object with bound interface  
>> for that service
>>
>> In this approach the web page doesn't get to scan the local environment  
>> which is a plus for privacy, but a negative for some kinds of  
>> applications that want to offer functionality based upon a knowledge of  
>> what devices/services are available.
Unfortunately if you want to address privacy and security concerns as much  
as possible you need to make some draconian choices.


[1]  
http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#video-conferencing-and-peer-to-peer-communication
[2] http://www.w3.org/TR/FileAPI/

-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software

Received on Thursday, 6 October 2011 13:58:02 UTC