Re: rewrite of section 4

On 13/6/12 06:56 , Greg Billock wrote:
> Thanks, Jean-Claude,
>
> The image I get here for web content is that the user should be
> allowed to expose the intent registrations to the page, and let it
> perform the picker functionality. Is that right? Are you suggesting
> this be installable in general? Or just for intents invoked in that
> app?
>
> That is, would the following API allow you to satisfy the use case you
> have in mind?
>
> IntentRegistration[] retrieveIntentHandlers();
>
> Then, coupled with explicit intents, the page could directly dispatch
> intents to services as it desired.
JCD: The additional APIs in my rewrite are not meant to be accessible to 
the pages.
They are meant to be usable only by a browser extension.
Sorry about not making that clearer.

>
> In addition to this, the browser could expose such an API as part of
> its extension mechanism to let other local code extend the picker (and
> presumably, to gain access to the list of registered handlers). I
> agree that the spec shouldn't mandate particulars of that extension
> mechanism.
>
> The big shift is that currently, although it is not explicitly called
> out in the spec, my assumption has been that the UA maintains
> confidentiality of registered services. This contract allows services
> to attach tokens to those urls, which aren't disclosed to any other
> app. If we expose the urls, it means the ability of services to count
> on their confidentiality will disappear. Perhaps that's not too much
> of a sacrifice, however.
JCD: I totally agree about the confidentiality.

>
> I think a larger concern is that exposing this API is enough of a
> privacy concern that it means we'd need to treat registered service
> urls differently. Installing an extension carries a much higher trust
> relationship than what users would expect from allowing a permission
> on a web page, it seems to me, and there are a lot of privacy
> implications in exposing persistent registered data like this.
>
> I'd like to see if we can solve these problems, however. Exposing this
> capability to web content is useful in several ways. It is a good
> approach to a set of use cases that web intents currently aren't that
> great for -- actions where there is a lot of data-dependent
> fragmentation which the client may understand, but the browser-based
> picker does not.
>
> I'm suspicious that having a more generic handle-all-invocations
> web-based WIA that requires a network fetch on every intent invocation
> is a performance penalty that in today's networking environment,
> browsers are going to be extremely reluctant to allow. Does that
> constraint push us towards an extension-only kind of support? Or
> perhaps an appcache'd page?
>
>
JCD: I do not see a use case for a generic, web-based WIA. I share your 
misgivings about requiring a network fetch for every intent invocation.
I see a use case for a browser extension providing different styles of 
enhancements over the browser-default WIA.
Example 1: a WIA that defines hierarchical intent directories, first 
looking into my own set of intents, then looking into my family's, then 
looking into home-wide directory (including registered guests).
Example 2: a WIA that delegates all the intent processing to a secure, 
policy-checking, webinos Personal Zone Hub

Thanks and 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 Wednesday, 13 June 2012 09:23:24 UTC