Re: Passing "origin" with intents

On Wed, Aug 29, 2012 at 12:34 PM, Greg Billock <gbillock@google.com> wrote:

> A couple related notes:
>
> Services can't rely on origin for security purposes -- it is trivial
> for a malicious UA to load a service and pass an incorrect origin
> parameter, so it is not a valid security token from the perspective of
> the service. The most that can be guaranteed is that a malicious
> client couldn't prepare an incorrect origin on a UA of the user's
> choice.
>

This is actually a very important (though irritatingly subtle) guarantee.
Good OpenID implementations reveal a different identity to each client to
avoid correlation, they also show a different dialog for first release of
identity to a new client. Oauth2 in "implicit" mode also releases a
different authorization to each client so that the user can revoke access
on a per-client basis. Both standards use the redirect_url parameter for
this, which doesn't protect clients against malicious users but does allow
services to easily protect users from malicious clients.


> Talking separately to some people interested in using intents as an
> IPC mechanism, having 'origin' on explicit intents (my suggestion 4
> above) would satisfy their needs. Would this also satisfy the use case
> of making Oauth-style authentication?


It would satisfy Oauth, where the service is explicit, but not OpenID,
where it's the user's choice.

The only reason I can see to not always pass the Origin is if the user
doesn't trust the service; but as the service is always at some point
chosen by the user, I find it hard to imagine a case where the user would
choose a service provider they don't trust. Even for "low-security" intents
like "share" or "edit", you're trusting a service to do (potentially very
public) things on your behalf, and to handle random data you push at it
from everywhere.

It may be that we should use your "3." choice above, and show a slightly
scarier warning when the user is about to choose a service that requires
the Origin to work.  I fear however that that will be a choice the user
is unqualified to make — when choosing an identity provider you should
choose the more secure one (i.e. the one that knows about origin), when
choosing a "share" provider you should choose the least inquisitive one
(i.e. the one that doesn't ask about your origin). What about a
hypothetical "pay" intent? Which would you choose?

On Wed, Aug 29, 2012 at 2:10 AM, Paul Kinlan <paulkinlan@google.com> wrote:

> If the client is receiving data back from a service, it too should be
> aware of the origin.
>
By using a Web-Intent the client is implicitly asking the user to choose
what to do. It should be happy with that decision, but, as you imply, must
be careful when trusting the results because a malicious user could cause
as much havoc as a good user who chose a malicious service. I'm not aware
of any ways we should be helping the client to protect the user from the
service, but I'm willing to believe there are some. The main reason for not
exposing the user's choice to the client is that malicious clients are
presumed to be much easier to fall foul of than malicious services, as
there's no explicit choice step.

Conrad