W3C home > Mailing lists > Public > public-web-intents@w3.org > July 2012

Re: question on 4.1 explicit intents

From: Greg Billock <gbillock@google.com>
Date: Thu, 19 Jul 2012 09:44:28 -0700
Message-ID: <CAAxVY9dh_1u=Vum6VagieLywiYFZo5Jg496Em9M2=5C0nmKoOQ@mail.gmail.com>
To: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
Cc: "public-web-intents@w3.org" <public-web-intents@w3.org>
On Mon, Jul 16, 2012 at 4:35 AM, Jean-Claude Dufourd <
jean-claude.dufourd@telecom-paristech.fr> wrote:

> On 18/6/12 21:18 , Greg Billock wrote:
>
>> If you mean restrictions on which pages may invoke intents, I'd need to
>> hear more about the security threat model you're thinking about. I don't
>> see yet how it's a real threat to allow any page to invoke any intent.
>>
> JCD: Quoting one colleague:
> "If you extend intents to be able to communicate with local, client-side
> services (such as a smart TV) then an explicit intent seems like a big
> vulnerability - any webpage can attempt to invoke all local intent services
> it knows have implementation vulnerabilities.  This is also true of
> web-based systems, of course, but at least web pages are usually designed
> with malicious users in mind.
> We don't want Web Intents to turn into another ActiveX disaster, where
> everyone registers new intent services with a browser and all the
> vulnerable ones are exploited. "



OK, I see what you mean. I don't know if explicit intents would ever work
with local services, though. What URL would they target?



>
>
>
>  For non-explicit intents, the security policy is very open-ended -- that
>> is, the UA is free to dispatch the intent in a way that can be very
>> responsive to the preferences of the user (and that's the whole idea, after
>> all). One goal for explicit intents is that they can be used for intra-app
>> transitions. (That is, an app could be built of different intent handlers,
>> and the transitions in the app corresponding to good integration points
>> with other apps.) For that use case, app developers need to have
>> predictability in the way those invocations get handled. If there's a good
>> justification, interposing a registration step there is needed, but I don't
>> see that being needed at this point.
>>
> JCD: If the goal of explicit intents is in-app intents, then there should
> be a restriction on which intents can be called explicitly, such as intents
> registered by the same domain as the invoking page, in a CORS-like
> mechanism.
> The problem with explicit intents is specifically with outside invocation
> of locally-registered events, or more generally cross-origin invocations.



Something I think we need, and should perhaps make compulsory for explicit
intents, is an 'origin' parameter that can communicate to the service in a
secure way the identity of the caller. For explicit intents, this would be
attached specifically by the UA; for other cases, it could be vouched for
by the UA (that is, only written if the client includes it).



>
> Best regards
> JC
>
> --
> JC Dufourd
> Directeur d'Etudes/Professor
> Groupe Multimedia/Multimedia Group
> Traitement du Signal et Images/Signal and Image Processing
> Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France
> Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
>
>
Received on Thursday, 19 July 2012 16:44:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 19 July 2012 16:44:57 GMT