- From: Greg Billock <gbillock@google.com>
- Date: Thu, 19 Jul 2012 09:44:28 -0700
- To: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
- Cc: "public-web-intents@w3.org" <public-web-intents@w3.org>
- Message-ID: <CAAxVY9dh_1u=Vum6VagieLywiYFZo5Jg496Em9M2=5C0nmKoOQ@mail.gmail.com>
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 UTC