Re: Passing "origin" with intents

On Thu, Aug 30, 2012 at 10:53 PM, Conrad Irwin <conrad.irwin@gmail.com> wrote:
>
>
> 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.

This is a good point. The other side, I think, is that while the
service is definitely chosen by the user, the user may not always wish
to disclose the client origin to the service, so while they certainly
*could* (they were just there, so if the service had a form that said
"what site did you just come from" the user could obviously fill it
in), the UA may be making a presumption that has privacy implications
for the user. That's why I'm reluctant to have 'origin' apply more
broadly -- if there are particular use cases where it is required, I'd
like to keep auto-passing restricted to those.


>
> 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
>

Received on Saturday, 1 September 2012 05:36:34 UTC