Re: user assigned names for services

On 25/11/11 08:10, Giuseppe Pascale wrote:
> On Thu, 24 Nov 2011 11:23:16 +0100, Dave Raggett <dsr@w3.org> wrote:
>
>> It is worth looking at multiscreen use cases where the user is seeking
>> to display some content, perhaps a video on one or more screens, e.g.
>> you may have a connected TV in your bedroom, and your living room (aka
>> lounge). These devices can be discovered via zeroconf or UPnP and
>> registered by the web run-time, but the interesting question is how
>> users identify the different screens, especially if they are the same
>> model of device.
> [...]
>> You could argue that this is something for the web run-times to deal
>> with, and not exposed by the web intents API. However, is that always
>> the case? I suspect that users and developers will want a way for
>> applications to make use of names for particular services, so that an
>> application can request a binding for an intent to a named service. This
>> has the corollary that applications can access the name of a service
>> after the user has bound the intent.
>>
>
> I think that what an application needs to know is different from what 
> a user needs to know.
> An application is interested in services: "I want a service to play 
> content" while a user thinks about devices: "the TV in my bedroom".

That particular example is probably already handled via the specific 
choice of intent. However, the application may still require additional 
information e.g. in order to set up a connection to the service.  
However, we can use the principle of data minimization via UA support, 
e.g. so that the application doesn't get access to the UPnP XML service 
descriptions.

>
> That said, in theory you could provide all the info (service and 
> device) to the application and let the application show these info to 
> the user, but then you will hit all sort of issues like:
>
> - privacy (e.g. fingerprinting, marketing profiling)
> - security (if I know which device I'm talking to, I may be able 
> exploit known vulnerabilities)
> - user experience/phishing (if you let the application show device 
> information, you have a different user experience on each application 
> and this will confuse the user)
>
> So the mapping between a generic service and a specific device needs 
> to be handled by the UA in a controlled way (and also in a way that is 
> familiar and understandable to the user).

Quite so. One the one hand there is the principle of data minimization 
for web APIs, and on the other hand, the principle of making users aware 
of what information will be disclosed.

>
> I realize there are ecosystems where there is no browser chrome, all 
> you have is a kind of fullscreen browser and you want to build your UI 
> using html/js/css.
> I'm wondering though if this scenario should be handled separately (by 
> a different spec/group) given that use cases and security implications 
> are different.
>

There are still means to provide a trusted UI. For instance, if you have 
the user register a photo/image and personalized phrase that are only 
known to the trusted code, and when shown act as evidence that the UI is 
being displayed by the trusted code.  It is a little more complicated 
that that, but you get the idea.

The Web Intents Task Force could develop a suite of complementary 
specifications as appropriate for agreed use cases, where each such 
specification is narrowly scoped.

-- 
Dave Raggett<dsr@w3.org>  http://www.w3.org/People/Raggett

Received on Friday, 25 November 2011 11:06:34 UTC