[whatwg] Proposal: <intent> tag for Web Intents API

[Simon Pieters]

On Mon, 12 Dec 2011 20:59:36 +0100, James Hawkins <jhawkins at google.com>  
wrote:

> On Thu, Dec 8, 2011 at 12:43 PM, Ian Hickson <ian at hixie.ch> wrote:
>> On Tue, 6 Dec 2011, James Hawkins wrote:
>>>
>>> One of the critical pieces of the API is a declarative registration
>>> which allows sites to declare which intents they may be registered for.
>>> The current draft of the API calls for a new HTML tag, <intent>, the
>>> attributes of which describe the service registration: [...]
>>
>> Separate from the issue of what precisely the element should look like,  
>> I
>> wonder if you could expand on the precise use case for the element. In
>> particular, I'm interested in whether this use case might also apply to
>> some of the register*Handler() methods we have now.
>>
>> Ideally, it would be good to have the current protocol and content type
>> handlers and the Web Intent stuff all use a coherent and consistent API.
>>
>
> Absolutely, we're very keen on providing RPH/RCH functionality via Web
> Intents.  Let me start with the use case for the intent element, then
> I'll get to R*H.
>
> *** Use cases ***
>
> The intent element serves as a declaration of functionality of a web
> app.  For example, Twitter exposes share functionality, Picnik exposes
> editing functionality, Dropbox exposes pick/save functionality, etc.
>
> Once the user accepts these registrations (gives permission), the UA
> can connect a client requesting a given set of functionality to the
> service that previously exposed that functionality.
>
> The fact that the element is declarative is a win wrt sites that may
> wish to crawl the web to index which web app handles which
> functionality.  See www.openintents.org/en/intentstable for an example
> of this for Android Intents.
>
> *** RPH/RCH ***
>
> registerProtocolHandler gives services a way to imperatively expose
> functionality that is to specific to protocols.  Web Intents will
> handle this use case by adding a scheme/URL pattern attribute to the
> intent registration.  Android Intents exposes scheme/URL pattern
> filtering as well, so this addition moves Web Intents that much closer
> to its model API.
>
> navigator.registerProtocolHandler("mailto",
> "https://www.example.com/?uri=%s", "Mail Service");
>
> becomes
>
> <intent scheme="mailto" title="Mail Service">
>  Click here to install our Mail Service application!
> </intent>

I'm not sure it's a good idea security-wise to have this feature as an  
element. Many sites use black-list based HTML filtering of user input, to  
filter out "bad" stuff like <script> elements. It's easy to argue that  
they are already screwed, but we still have to think about it when adding  
new features to the platform, because there are many such sites. It would  
be easy to inject an <intent> tag to such sites, whereas it is harder to  
call navigator.register*Handler.

Separately, I'm not so happy with having two APIs for the same thing. We  
don't enable anything new, but we double the attack surface, the cost to  
implement and test, authors need to not only learn both, but also need to  
learn (and argue) about which to use, and so forth. register*Handler has  
already been shipped in some browsers.


> registerContentHandler allows services to imperatively expose
> functionality that is specific to content types.  Web Intents will
> provide this use case by special-casing the intent element when no
> action is provided for a particular MIME type.
>
> navigator.registerContentHandler("image/png",
> "http://www.example.com/?foo=%s", "My Image Viewer");
>
> becomes
>
> <intent type="image/png" title="My Image Viewer">
>  Click here to install our Image Viewer application!
> </intent>
>
> Of course the fallback content is optional and determined by the
> service, but we believe it's a great way to expose fallback
> functionality via installable extensions/apps/whatnot.

The fallback would be more like "Your browser doesn't support the intent  
tag", no?


> *** Advantages ***
>
> Client-side handling.  For R*H, ?foo=%s normally requires server side
> processing.  With Web Intents, this data is passed completely
> client-side on the intent object.
>
> Wildcard matching.  R*H does not allow wildcard matching, where as Web
> Intents would allow a service to register for image/* in one succinct
> registration.

I guess these features could be added to register*Handler without adding a  
new element to register handlers.

> Thanks,
> James


-- 
Simon Pieters
Opera Software