OpenURI portal w/o user granting permission

[Stephan Bergmann]

On 07/14/2016 02:23 PM, Philip Withnall wrote:
> On Thu, 2016-07-14 at 12:07 +0200, Stephan Bergmann wrote:
>> At least with a recent build of xdg-desktop-portal and
>> xdg-desktop-portal-gtk, sending an
>> org.freedesktop.portal.OpenURI.OpenURI request does not always
>> involve
>> the user granting permission first:  For example, if the given uri
>> argument is in the form of a valid http URL, it is passed directly
>> to
>> the browser to open it.  (Only if the argument is of some non-URL
>> form a
>> "Select application" dialog comes up.)  Isn't that a privacy and
>> security issue?
>
> How do you think it’s a privacy and security issue (and can you define
> the ‘security’ in concrete terms of availability, confidentiality and
> integrity)?
>
> We discussed this at the recent GTK+ hackfest, and the conclusion was
> that:
>  • Popping up a confirmation dialogue (‘do you want to open this URI?’)
> would be pointless: users cannot parse URIs, and it would be incredibly
> annoying to click a link in an application and then have to click ‘yes’
> in a confirmation dialogue.
>  • Browsers are explicitly designed to handle untrusted URIs, in the
> sense that if they end up loading a malicious page, the browser itself
> shouldn’t get exploited.
>  • There is an attack here where a compromised app could send your data
> to a malicious website in a GET parameter without you being able to
> stop it, but:
>   - That requires the app to have permission to access the data in the
> first place.
>   - You’re going to notice if the app does this a lot, because your
> browser will open each time.

once can already be enough...

>   - It’s basically impossible to get rid of covert channels (like
> this), so if an app isn’t leaking data through GET parameters, it will
> find another way to leak data. The best we can do is restrict the
> covert channels without impacting usability too much, and try to make
> it obvious when an app //is// using covert channels to leak data.
>
> Did you have another threat model in mind?

A malicious app can cause your browser to access a URL controlled by the 
app.

For one, that can be a privacy issue (with or without additional leakage 
of data through GET parameters), as the app's author can observe access 
to that URL (owned by them).

For another, it can be a security issue if accessing the URL triggers an 
exploitable bug in the browser.

But if this has already been discussed, and the pros of the current way 
are considered to outweigh its cons (and I tend to agree with that), 
then I'm fine.