W3C home > Mailing lists > Public > public-web-intents@w3.org > September 2012

Re: Passing "origin" with intents

From: ConradIrwin <conrad.irwin@gmail.com>
Date: Tue, 4 Sep 2012 00:39:04 -0700
Message-ID: <CAOTq_pvb0rB7hUyLXZVO8+bMvUyE93+G5ZjeGAV_dT7Nv4Tu2Q@mail.gmail.com>
To: Josh Soref <jsoref@rim.com>
Cc: WebIntents <public-web-intents@w3.org>
On Fri, Aug 31, 2012 at 10:36 PM, Greg Billock <gbillock@google.com> wrote:
> 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,

I agree that this is a theoretical possibility  but as above I'm
pretty skeptical that there are real-world cases where the user would
be able to decide "i don't want this service to know my origin".

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

Yeah. It's a hard UX problem... as we agree the user is not equipped
to make this choice, we could let the client do it on their behalf. 1.
is probably better than 4. as there are implicit intents (like "pay"
or "identify yourself") which could benefit from an origin. The
problem with letting the client make the choice at all, is that the
client does not choose the service  this in turn means that in order
for the intent to work, the client must second-guess the service's
choice. (Otherwise I guess we could pop up a dialog in the case the
client and service disagree, but ugh...).

There seems to be somewhat of a trade-off between protocol complexity,
user security and user privacy. I'd assert that either we can have a
complicated protocol that's a little bit secure and a little bit
private; or a simple secure protocol or a simple private protocol. I'd
always choose "simple secure".

This is all hyperbole of course, the amount of user privacy that's
leaked by the origin pales in comparison to the referer: header; and
the security added by the origin header is basically 0 unless the
service actually uses it. Either way, protocol complexity is probably
the biggest thing to steer clear of if widespread adoption of
web-intents is the goal, which I'd argue it should be :). If you're
making a choice: Choosing simple-private also cuts off some known
use-cases for which the WebIntents UI would be ideal (e.g. BrowserID);
choosing simple-secure might also cut off some use-cases where it's
important not to leak the origin to the service, but no-one's actually
provided an example yet.

On Wed, Aug 29, 2012 at 10:12 AM, Josh Soref <jsoref@rim.com> wrote:
> Matthew wrote:
>> IMHO, we don't want the user making a choice to disclose origin or not. It will
>> be difficult to communicate the concept of "origin" to a user. I think that most
>> users would not be able to understand the implications of disclosing the origin,
>> so giving them this choice seems like it wouldn't really accomplish anything
>> other than force an uncomfortable choice on the user.
>
> There will probably COTS products which will be meant for in house systems, like Zimbra and Github and Mailman. They will probably (if they're maintained) eventually grow Intent support. And users will want to use them. But ...
>
> Let's look at a Zimbra deployed for a company "Example.com Inc." It has an internal client system "Client Referrals", for some reason they want to know if people were using the corporate Zimbra for Pick-Contact, so they want this "origin" property. As such, they can't configure zimbra.example.com's Pick-Contact provider *not* to supply a "return" origin. However, when the user wants to run an app "Facebook", and it asks the user to Pick-Contact, and the user selects zimbra.example.com, the user doesn't want to leak `zimbra.example.com` with the selected Contact.

Yeah, I agree that we shouldn't send the service's origin to the
client. Existing protocols for which this is important
(Oauth-1/OpenID) require the use of a back-channel so that the user
can't impersonate a service.

Conrad
Received on Tuesday, 4 September 2012 07:39:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:47 UTC