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

Robin,

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 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. What the launched application 
does with the input parameters is up to it, and apart from attempts to pass 
malformed parameters (e.g. in order to crash the app and open up some 
security hole, theoretically) I can't see any particular risk beyond the 
normal ones (e.g. the parameters might be related to some other mal-intent, 
e.g. sending some private info off the device, premium-rate fraud, or 
directing the browser to some bad site).  Most of those type threats already 
exist for Web applications, and that's why ability to limit access to the 
APIs is key (including URI scheme based launching, which should have been 
addressed generically in WARP). If the app is trusted, it can be given 
ability to use these APIs in a more user-friendly way. If not, the user 
should be involved in accepting the risks through a confirmation prompt.

--------------------------------------------------
From: "Robin Berjon" <robin@berjon.com>
Sent: Monday, February 07, 2011 3:37 AM
To: "Bryan Sullivan" <blsaws@gmail.com>
Cc: "Dominique Hazael-Massieux" <dom@w3.org>; "public-device-apis" 
<public-device-apis@w3.org>
Subject: Application Launcher (was: Rechartering Device APIs & Policy 
Working Group)

> Hi,
>
> On Feb 2, 2011, at 17:04 , Bryan Sullivan wrote:
>> - Application Launcher API should remain in scope.
>
> I think that the broad idea can remain but that the name should change. 
> There have been some very interesting investigations in this area, notably 
> through Web Introducer as well as the nice Web Intents trick from Paul 
> Kinlan (http://webintents.appspot.com/).
>
> 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);
>
> Even assuming code review, signing, policy, whatever you want, this is 
> still a major attack vector that simply can't be shipped responsibly. It 
> is *way* too easy to do code injection into a widget, nothing will stop 
> you except finding the cure for developer mistakes, which we don't have. 
> If you want more detail on such attacks, Thomas has an excellent 
> presentation about widget security. Essentially the API above was possible 
> in Apple's Dashboard widgets. The only reason it did not become one of the 
> greatest virus transmission system since Outlook is because people didn't 
> pay enough attention to it.
>
> But there are ways in which a Web application could trigger another 
> application in a safe manner. A standardised Web Intents system (based on 
> the several inputs that we have) would have the nice property that it 
> could transparently (and safely) equally well trigger a local application 
> or a Web-based app. It can work in a browser, and it can work in other 
> security settings with the exact same code (though the interaction and 
> which apps get triggered may be different). I can think of very cool uses 
> for this type of tech.
>
> However I think that the name is confusing, and makes people think that 
> it's there to address the former type of API. We should be clearer about 
> its goals, and I think that finding a better name for it could go a long 
> way.
>
> -- 
> Robin Berjon - http://berjon.com/
>
>
>
>

Received on Wednesday, 9 February 2011 09:14:54 UTC