On 07/18/2013 01:20 PM, Thomas Voß wrote: > On Thu, Jul 18, 2013 at 7:06 PM, Marc Deslauriers > <marc.deslauri...@canonical.com> wrote: >> On 13-07-18 01:00 PM, Jamie Strandboge wrote: >>> On 07/18/2013 11:14 AM, Michał Sawicz wrote: >>>> W dniu 18.07.2013 17:38, Marc Deslauriers pisze: >>>>> For the browser, I imagine a URL handler will take care of it, but what >>>>> about >>>>> spawning a different application that doesn't necessarily handle URLs or >>>>> MIME types? >>>> >>>> And for network access I expect some platform API instead. >>>> >>>> I feel like the only instance where we would indeed allow spawning other >>>> apps directly would be if it's bundled in the same package - and handled >>>> through upstart as usual, I'd say. >>> >>> Well, an app may want to spawn a browser rather than implementing a webview >>> itself. Marc mentioned the URL handler, but I don't know how this would >>> work. >>> Marc, can you elaborate? >> >> Not really. I remember there was discussion around an API to allow apps to >> open >> stuff using a URL, such as http://www.ubuntu.com, or >> unity://wireless-settings >> or something similar. Was there going to be a dbus API for this? >> > > My last status on this is that we are going to have a URL handler > binary that apps can register with, much like for example on iOS. With > that, Jamie's web-browser example is easily solvable, and so are more > sophisticated use-cases like gallery://albums/birthday/cake.png. Not > sure if it's DBus or not, but I'm very much in favor of doing URL > handling as opposed to mime-type handling.
Cool, I'm glad others have thought about it. This feels like another good place for the trusted helper approach (which suggests DBus, but it doesn't strictly have to be). If the process doing the launching is out of process from the app, it handles different avenues attack (eg, manipulating the environment, not being able to ptrace the other app). Though in thinking about it, we should get all this simply having upstart in the mix. It isn't clear what the permissions model would look like though. "can launch other apps" seems overly broad. The permissions could be a 1 to 1 mapping of handlers to permissions, but might be too fine-grained. It may be ok for the first iteration to have at least two: 'http/https' and 'everything' since I think a lot of applications will want to have http:// and https:// handlers and not the others. It should also be noted that our application confinement model will not present the user with a dialog of app permissions at installation[1] and our app review process will be shallow. Where appropriate, we will be favoring contextual prompting instead. With other APIs like content picking, online accounts and geolocation, the user will be meaningfully prompted when the app tries to access one of these APIs (and the service providing the API may cache the answer). Have others thought about contextual prompting in reference to URL handling? On the one hand, it seems like a real usability problem to do so. On the other hand, the security guy in me says that an app shouldn't be able to launch arbitrary applications. Since the launching of the application is via upstart and the application can't be manipulated beyond giving it a URL, and the handler for that URL is either trusted or confined itself, and this handler would be launched in the foreground in front of the app doing the launching (and therefore obvious what just happened), I could probably be persuaded this isn't a problem after all. If the URL handling is overly sophisticated, like gallery+uploadphoto://*.png+http://givemeallyourpix.com:8888 then I'm back to worrying again. :) [1] Perhaps someone will want to write a tool to display the permissions of all installed click packages by parsing the manifests (there will certainly be a temptation to allow changing the permissions, but this would certain need some design to work well). Heck, maybe I'll write this tool myself :) -- Jamie Strandboge http://www.ubuntu.com/
signature.asc
Description: OpenPGP digital signature
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
