ubuntu-phone team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

On 07/18/2013 01:20 PM, Thomas Voß wrote:
> On Thu, Jul 18, 2013 at 7:06 PM, Marc Deslauriers
> <marc.deslauriers@xxxxxxxxxxxxx> 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/

Attachment: signature.asc
Description: OpenPGP digital signature