W3C home > Mailing lists > Public > public-device-apis@w3.org > February 2011

Re: Application Launcher (was: Rechartering Device APIs & Policy Working Group)

From: Bryan Sullivan <blsaws@gmail.com>
Date: Wed, 9 Feb 2011 19:33:11 -0800
Message-ID: <AANLkTi=Z-japETob7YnC+6_sJBTXaPzjLc7tgqsgtPCh@mail.gmail.com>
To: Robin Berjon <robin@berjon.com>
Cc: Dominique Hazael-Massieux <dom@w3.org>, public-device-apis <public-device-apis@w3.org>
Robin,
To be clear, I was referring to the following when I said "I'm not
sure why you say the ability to detect the registered
registered/default for a purpose (e.g. music player) and launch it is
"simply, deeply wrong":
> The idea that one should be able to do the following is simply, deeply
> wrong:
>
>  var boomnbox = navigator.apps.gimmeAnAppFor(MUSIC_PLAYING);
>  // boombox contains "/Applications/iTunes.app"
>  navigator.apps.runIt(boombox);
>

Re "> If the goal of the API you are proposing is to be "essentially
equivalent" to launching an application based on a URI scheme or media
type, then we don't need an API at all. We already have everything
that's needed.":
That was an example, and true for things which have a registered URI
scheme or content-handler status. But it's not true for general app
launching cases, which is the real gap here. Back in the London
meeting at the OMTP offices, I agreed that the URI schem approach is
fine for those type apps (this is why we have that specifically called
out in the WAC specs). but it is insufficient for the more generic
cases.

I disagree that this is a death-wish, or that we could not ensure
appropriate use of the API.

On Wednesday, February 9, 2011, Robin Berjon <robin@berjon.com> wrote:
> Hi Bryan,
>
> On Feb 9, 2011, at 09:01 , Bryan Sullivan wrote:
>> I'm not sure why you say the ability to detect the registered registered/default for a purpose (e.g. music player) and launch it is "simply, deeply wrong".
>
> This is a conversation that we need to get right, which requires making sure we're on the same page talking about the same thing. So since the above is not at all what I have said, I am going to ask you to please read my previous email in this thread more closely and either return with a rejoinder to what I actually did say, or a description of what you didn't find clear so that I may clarify (it may well be that I was unclear, but I need your help to figure out where).
>
>> The only thing the requesting app could do is invoke that registered/default application, and possibly pass it some invocation parameters. This is essentially equivalent to launching any URI-handler with parameters as defined in the related RFCs.
>
> If the goal of the API you are proposing is to be "essentially equivalent" to launching an application based on a URI scheme or media type, then we don't need an API at all. We already have everything that's needed.
>
> If however the idea is that one could call arbitrary applications based on their paths (as exemplified in my original post) then we have a security death wish. In BONDI 1.1, you could do that:
>
> // launch all the apps!
> bondi.applauncher.getInstalledApplications(runAll);
> function runAll (apps) {
>   for (var i = 0, n = apps.length; i < n; i++)
>     bondi.applauncher.launchApplication(null, null, "file://" + apps[i]);
> }
>
> That's just wrong. You can put all the policy you want on it, all it takes is a single, garden-variety XSS attack and you have full access to the platform of all the users who have widgets supporting the above code.
>
> We have more elegant solutions for this that don't involve anywhere near as much risk. We should use those.
>
> --
> Robin Berjon - http://berjon.com/
>
>
>
>
Received on Thursday, 10 February 2011 03:33:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:17 GMT