Re: Passing "origin" with intents

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