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

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

From: Robin Berjon <robin@berjon.com>
Date: Mon, 7 Feb 2011 12:37:43 +0100
Cc: Dominique Hazael-Massieux <dom@w3.org>, public-device-apis <public-device-apis@w3.org>
Message-Id: <CE530CA8-9CAD-4615-8A00-9750DE40A20D@berjon.com>
To: Bryan Sullivan <blsaws@gmail.com>

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"

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 Monday, 7 February 2011 11:38:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:25 UTC