Re: question on 4.1 explicit intents

On Wed, Jun 13, 2012 at 1:51 AM, Jean-Claude Dufourd
<jean-claude.dufourd@telecom-paristech.fr> wrote:
> On 13/6/12 07:38 , Greg Billock wrote:
>>
>> Can you elaborate? The risk the language about intent delivery is
>> addressed to is not a security concern, but to maintain a specific
>> model of registration within the UA -- that it not silently register
>> services and then dispatch to them without user involvement. For
>> explicit intents, though, the client is specifically directing the
>> user to a particular service -- there's no registration involved.
>>
>> Do you think the same thinking ought to apply here, though? That is,
>> any dispatch, even explicit, to a particular service ought to be
>> approved by the user?
>
> JCD: The people I work with in the webinos project looked at the
> registration of the intent as the place in the process where they will
> insert security/policy checking.
> They are concerned about the explicit intents and the lack of this
> registration check.
> So our first reaction was to try to impose the registration check also for
> explicit intents.

Explicit intents are intended to provide a way for the invoking
context to deliver an intent directly to a particular service. That
is, there's no security difference for a "transferFunds" intent
whether it is invoked explicitly or dispatched by the user. If the
service providing this functionality has the right mechanisms in place
to protect the user from unauthorized transfers (and they should!)
then those mechanisms will work the same way for explicit intents.

>
> After trying to write a scenario about a pirate page using an explicit
> intent "transferFunds" provided by a banking site, I realize that the intent
> registration may not provide for enough checking.
> If such a sensitive intent existed, then I would not authorize its
> invocation from just any page, so at the intent registration time, I cannot
> "approve" it in general.
> So the intent provider may need to do additional checking, but it has no
> information on who is the invoker, right ?

If you mean restrictions on which pages may invoke intents, I'd need
to hear more about the security threat model you're thinking about. I
don't see yet how it's a real threat to allow any page to invoke any
intent.


> I believe there is something missing, the possibility of imposing more
> checks, depending on the sensitivity of the intent.
> How would you "install" a security policy for intents on top of the current
> spec ?

For non-explicit intents, the security policy is very open-ended --
that is, the UA is free to dispatch the intent in a way that can be
very responsive to the preferences of the user (and that's the whole
idea, after all). One goal for explicit intents is that they can be
used for intra-app transitions. (That is, an app could be built of
different intent handlers, and the transitions in the app
corresponding to good integration points with other apps.) For that
use case, app developers need to have predictability in the way those
invocations get handled. If there's a good justification, interposing
a registration step there is needed, but I don't see that being needed
at this point.

-Greg

Received on Monday, 18 June 2012 19:19:09 UTC