Re: Web Intents and abuse

On Tue, Nov 22, 2011 at 8:28 PM, Tom Sepez <tsepez@chromium.org> wrote:
> Hi folks,
>   Saw the email from James go by and thought I would send out a few comments
> following a cursory read
> of www.chromium.org/developers/design-documents/webintentsapi
> - Intent Provider Discovery:
> The User Agent discovers Intent Providers as a side-effect of visiting a web
> page.  Presumably, before these are added to the User Agent's catalog of
> providers, there is user interaction required, in the form of a pop-up
> dialog or an infobar explaining that the Intent Provider site wants to
> register itself as a provider.  While absolutely necessary, this seems like
> an annoyance should it happen every time I go back to the site.  Is the user
> agent required to remember permanent denial of permissions if the user so
> chooses?  Or is this responsibility deferred to the site, using cookies to
> opt you out?

We should document that it should only happen for newly discovered
intents.  I newly discovered intent is one that it is not in the UA's
dictionary, based off a action/type tuple.

The assumption here is that it is ok to change the href as it is in
the same origin without prompting the user for action.

The UA should remember denial of permission, if permanently selected
by the user, however that is not the case for a basic dismissal will
temporarily revoke the UA from installing the intent.

> How does the user know that the title="" of the service actually matches the
> provider?  Can I trick users into revealing their data by claiming to be
> title="picassa service" on my own evli website?  Is the URL also displayed
> at registration time? This would be a strong suggestion.

Our demos show the domain of the service at invocation time and when
we register an intent it says something like "www.xyz.com would like
to add ... "

> Are there any restrictions on the service URLs (the <intent href=""> that a
> service provider site can attempt to register?  Must they be http/https
> URLs?  Must they be back to the same domain/origin/page as the page which
> contains the intent tag itself?

Same origin, http or https.

>Allowing the User Agent to register
> javascript: URL as a service provider seems like a bad idea, for example.
> I would strongly suggest that only top-level frames should be allowed to
> register Intents, intent tags in <iframe> should be ignored.  If I'm a bad
> guy, the first thing I'd do when this hits is to buy some ads (using a
> stolen credit card, of course) on an ad network and have the ad markup
> contain intent tags (no, the folks accepting the ad do a lousy job of
> vetting these in general).  Later, when the ad runs on a well-respected
> site, users may be tricked into accepting the registration based on the
> reputation of the top-level page, particularly when the title="" claims to
> be that service.

The JS Shim ignores registration attempts from iframes for this reason.

> As a nit, the <intent action=""> attribute name seems misleading.  Unlike a
> <form action="">, the URL contained therein will never be visited or posted.
> it is merely an identifier describing a protocol about what kind of data is
> to be exchanged.  That the provider takes the desired action ("saving") is
> really up to the provider in the end.


> - Intent Invocation:
> When the choose intent popup occurs on the client side, do I get more
> information than just the title to help aid my decision?  Do I get the
> service URL?
> It sounds like no data is actually posted to the Intent Provider, that
> rather it retrieves it client-side much like a post-message, correct?
>  That's good if so.

Yes, correct.

> When the Intent Provider's page is loaded in the "inline" disposition, it's
> still in an iframe from its own domain, correct?  We absolutely need to
> avoid giving the provider full access to the client page and vice versa.
> When the intent provider's page is loaded, do they get a referer (sic)
> header?  I would expect that this must be suppressed for privacy.  Same with
> the fledgling Origin header.

The inline disposition is intented to allow the app to appear in where
the action picker was, it is not intended to be an iframe on the page,
the current JS shim that we have that demos this has to use an iframe
embedded in the picker, but the real implementation won't.  There will
be no referer or Origin.

> The request to load the provider's page contains the user's cookies for the
> providers site as usual, correct?  I don't think there is a way around this.
>  I worry about introducing new CSRF vectors here.
> What is the interaction when an SSL client page wants to invoke a service?
>  Must the intent provider page also be over SSL?  Is there an easy way to
> tell whether the service I'm about to invoke is going to be suitable to
> handle the data without risking exposing it?

Currently there are no restrictions and no provision to restrict an
SSL to plain, downgrade.

>
> Thanks heaps.
>
>
>
>
>
>
>
>
>
>



-- 
Paul Kinlan
Developer Advocate @ Google for Chrome and HTML5
G+: http://plus.ly/paul.kinlan
t: +447730517944
tw: @Paul_Kinlan
LinkedIn: http://uk.linkedin.com/in/paulkinlan
Blog: http://paul.kinlan.me
Skype: paul.kinlan

Received on Wednesday, 23 November 2011 10:05:17 UTC