Web Intents and abuse

On Tuesday, November 22, 2011, 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.

I'm hoping that a pop-up/infobar isn't a requirement.

Firefox has a concept of Frecency [1], and I'd hope that Agents could apply
it here too. Assume that a UA only considers recognizing advertisements for
Providers on top level resources, and that it ignores pages/sites where the
user doesn't linger/interact for less than threshold T (to avoid evil
redirect insertions). When the user reaches a site that wants to perform an
Action and the UA provides the user a list of Providers, it can present the
list favoring:
* favorites
* frecency of used providers for the action
* frecency of used providers of other actions (selecting by domain and
limiting to those who provide tis action)

It could also provide details such as:
* time/location of discovery
* picture of top level page that advertised the service

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

UAs aren't necessarily required to remember anything, however sometimes
they will compete to do their best to help their users. If a user indicates
a lack of interest in a certain provider, the user could be annoyed to be
repeatedly offered that provider.

But again, I'm advocating only showing providers when an action is needed
and not when a provider is available.

> Or is this responsibility deferred to the site, using cookies to opt you
out?

Relying on sites for opt out is clearly foolhardy.

However, a site clearly *could* choose not to offerto be a provider for a
given user. E.g. if I tell facebook that I don't want to use its Chat
service, it could stop offering it to me so that when I use a new UA, that
UA doesn't Discover FB Chat and instead shows me Gtalk which is what I
happen to use.

> How does the user know that the title="" of the service actually matches
the provider?

Please see my introduction [2] section §12 for one possible approach to
dealing with questionable providers.

> Can I trick users into revealing their data by claiming to be
title="picassa service" on my own evli website?

You can always *try* to trick users. And as you can at least fool some of
the people some of the time, you will succeed, some of the time. If UAs
evolve to include a reputation provider, then yurtask may become harder.

> Is the URL also displayed at registration time? This would be a strong
suggestion.

No, humans do *not* understand urls, and UA vendors have wisely ignored rfc
MUST requirements to show URLs [3]. For specs currently in draft, we have
sent feedback [4] to editors informing them that this kind of requirement
is harmful.

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

This TF was formed to specify these things, see my list of deliverables §1
[5].

As such, we could put in limits or not, and UAs may evolve limits if we
fail to strike the correct balance. Feedback about UCs or risks is welcome.

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

While you might think it's bad, it might not be as bad as you think. The
main problem with such a provider is that it should have no origin and thus
there would be no way for the original advertising site to talk to it or
revoke it. As long as it runs in its own origin and doesn't have trust to
anything, it isn't more harmful than any other resorce. Providers do *not*
run with the permisions of their requester. And servers are free to refuse
connections without a Referer.

> I would strongly suggest that only top-level frames should be allowed to
register Intents, intent tags in <iframe> should be ignored.

This seems reasonable (in fact I noted the same above).

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

We shouldn't be at the nit level, as no formal Draft has been submitted to
the TF. That said, would you accept name= over action=?

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

Users don't understand urls. If you use a Developer UA, or a Debug mode,
I'm sure you'll have access to the url. See earlier for thigs a UA might
provide. As a general rule, specifying UI is an area that fails miserably,
it's generally best to let  UAs evolve and compete.

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

Again, there is no formal draft. That said, this does seem to be the plan.

> When the Intent Provider's page is loaded in the "inline" disposition,
it's still in an iframe from its own domain, correct?

I think you're asking the wrong forum as there's no formal draft and it's
unfair to TF members to be asked to comment on non-submitted content.

> We absolutely need to avoid giving the provider full access to the client
page and vice versa.

This is a goal of Opacity §2 [6].

> When the intent provider's page is loaded, do they get a referer (sic)
header?

They might, but it wouldn't be the requesting page. It could be something
to indicate "hi, this is an Intent session".

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

This might be something an intent provider could control. Or they migt be
forced to provide urls that encode e.g. temporal login credentials (which
the provider would be renewing as the user visits the site normally, and
could server side block if the user changes credentials).

> What is the interaction when an SSL client page wants to invoke a service?

As users need to be able to register any provider of their choice, we can't
forbid an insecure provider.

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

I don't think that's up to the requesting site.

The UA could warn users about insecure providers in its chooser.

[1] http://en.wiktionary.org/wiki/frecency
[2] http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0038.html
[3] sorry, no time now
[4] http://lists.w3.org/Archives/Public/public-device-apis/2010May/0027.html
[5] http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0011.html
[6] http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0011.html