Re: Passing "origin" with intents

If the client is receiving data back from a service, it too should be aware
of the origin.

We also would need to make affordances for when the origin information is
not discernable (for instance if a UA invoked the action from its chrome)

My personal opinion on this is that this is being used for a service to
reject access from an origin then why is this not filtered out and not
presented to the user in the picker? The ux of a service blocking the
action after it has been invoked seems bad.

On a point of history, not having the services make a decision based on
source was the reason why we didn't ant the origin in.  That being said, we
are seeing a number of developers want this - I think I would prefer a
solution that didn't even present the option to the user in the picker.

P
On 29 Aug 2012 07:47, "Conrad Irwin" <conrad.irwin@gmail.com> wrote:

> On Mon, Aug 27, 2012 at 3:30 PM, ⅔ Steve McKay <smckay@google.com> wrote:
>
>> Wouldn't the client want some knowledge of which service it is disclosing
>> the origin to? Given that the service is decoupled from the client maybe we
>> would want a more subtle policy such as:
>
>
> I don't see why the client should have a say in this? The user may wish to
> avoid disclosing their browsing habits to untrusted third parties; but
> given that the user has chosen the service provider, they presumably trust
> it to handle their data.
>
> On Mon, Aug 27, 2012 at 9:16 AM, Paul Kinlan <paulkinlan@google.com>
>  wrote:
>
>> I was thinking an attribute on the constructor object along the lines of
>>
>> new Intent({action:... , type: ... , data:..., useOrigin: true});
>>
> If anything, the "should the service see the origin" decision should be
> made by the user when they choose the service provider (maybe the "do you
> want to install this service provider" dialog could be a bit scarier in
> that case). I didn't include that in the below diff because I can't think
> of any use-case for a service that is trustworthy enough for intent data
> and ports, but not trustworthy enough for origin information.
>
> On Sun, Aug 26, 2012 at 9:19 PM, Greg Billock <gbillock@google.com> wrote:
>
>> We've discussed this, but there's no formal proposal yet. Do you want
>> to draw one up? Certainly for explicit intents this seems like it'd be
>> a good addition.
>
>
> I'm not sure exactly what should be involved in a "Formal Proposal", but
> attached is a diff to be started with.
>
> diff -r 86cfa8e21bff spec/Overview-respec.html
> --- a/spec/Overview-respec.html Mon Jul 30 08:17:29 2012 -0700
> +++ b/spec/Overview-respec.html Tue Aug 28 23:34:18 2012 -0700
> @@ -306,7 +306,9 @@
>          [[!POSTMSG]]</dd>
>          <dt>readonly attribute any extras</dt>
>          <dd>Retrieves the extras metadata (if any) which this intent was
> constructed with.</dd>
> -
> +        <dt>readonly attribute DOMString origin</dt>
> +        <dd>The origin of a webintent MUST be set to the origin of the
> client page
> +            formatted as a <code>serialized-origin</code>. See
> [[!ORIGIN]].</dd>
>          <dt>void postResult(any data, optional
> sequence&lt;Transferable&gt; transferable)</dt>
>          <dd><b>Only present when the Intent object is delivered to the
>             Service page.</b> The payload passed to this method will be
> returned to the onSuccess
> @@ -852,6 +854,21 @@
>          persisted by the User Agent across login redirects.
>          </p>
>        </section>
> +      <section>
> +        <h3>Origin</h3>
> +        <p>
> +        User Agents should provide the origin of the client page to the
> service.
> +        As part of choosing the service to handle a Web Intent the user is
> +        implicitly indicating a degree of trust for that service. The user
> +        typically does not extend the same trust to client pages, which
> are
> +        arbitrary websites. Providing the origin to the service allows the
> +        service (with the help of the user if necessary) to make an
> informed
> +        decision about what data it is acceptable to provide in the
> postResult
> +        or postFailure callbacks. The origin is particularly useful for
> services
> +        that wish to provide user authentication or identification, but
> can also
> +        be used to warn the user of a suspicious client page for any
> intent.
> +        </p>
> +      </section>
>      </section>
>
>      <section>
>
> On Mon, Aug 27, 2012 at 3:30 PM, ⅔ Steve McKay <smckay@google.com> wrote:
>
>> Wouldn't the client want some knowledge of which service it is disclosing
>> the origin to? Given that the service is decoupled from the client maybe we
>> would want a more subtle policy such as:
>>
>> send_origin="NEVER (implicit), ALWAYS, SAME_ORIGIN"
>>
>> Steve McKay | Sr. Software Engineer |  smckay@google.com |  310-359-8331
>>
>>
>>
>>
>> On Mon, Aug 27, 2012 at 2:47 PM, Greg Billock <gbillock@google.com>wrote:
>>
>>>
>>> If the client doesn't want to disclose the origin, attaching it always
>>> might be a privacy concern. "UseOrigin: true" is nice -- then the
>>> browser fills in the right origin for the service. That lets the
>>> service know that the client is purposefully disclosing the origin,
>>> and that the value received is from the UA.
>>>
>>> Obviously the service can be loaded by a malicious UA, so it will need
>>> to maintain its own security based on other content in the message
>>> anyway.
>>>
>>>
>>> On Mon, Aug 27, 2012 at 1:15 PM, Conrad Irwin <conrad.irwin@gmail.com>
>>> wrote:
>>> > On Mon, Aug 27, 2012 at 1:02 PM, KOMATSU Kensaku
>>> > <kensaku.komatsu@gmail.com> wrote:
>>> >> Yep, most of modern browsers such as IE, chrome, safari and opera are
>>> >> trusted and sends right origin to intent services. But there are
>>> other clients
>>> >> their behavior is not trusted. So, I guess James pointed that origin
>>> info
>>> >> from clients is not always trusted.
>>> >
>>> > Just like the Origin: HTTP header, the only guarantee you get is that
>>> > "this user trusts the browser to send the correct Origin header".It
>>> > doesn't protect you from malicious users, but it does allow you to
>>> > protect clumsy users who might be fooled into clicking an intent on a
>>> > malicious website.
>>> >
>>> > Conrad
>>>
>>>
>>
>