Web Intents and abuse

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?

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.

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

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.

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


Thanks heaps.