Re: Explicit intents - Discussion and proposals

On Fri, Sep 7, 2012 at 7:35 AM,  <Frederick.Hirsch@nokia.com> wrote:
> I have reviewed our list and meeting discussions regarding explicit intents and have some questions and proposals.
>
> (1) The first question is whether we need explicit intents at all or can remove them from the specification. There are some arguments against having them, as well as a use case that justifies them.
>
> First of all I propose we add the following language to the specification in the Use Cases section (based on the F2F discussion recorded in the minutes [1] ):
>
> [[
>
> 5.6 Enable Modular Applications
>
> The intents mechanism should enable the creation of applications that are assembled using dynamically composed modules. An example would be a photo editing application that incorporates components such as red-eye reduction, cropping and other photographic features which might have different implementations provided by external clients. It should be possible to have the choice of such components defined using web intents and be remembered without requiring repeated requests for user-selection and consent.
>
> ]]
>
> I believe this is the core use case for explicit intents, though it could also be met with non-explicit intents as long as it is possible to remember previous choices.

That's true in some cases. Fundamentally, explicit intents allows web
content to create their own picker-like functionality, so it's mostly
a way to make that capability available to web content. There are some
other use cases where explicit intents are needed -- Oauth-style flows
for instance.

>
> Is the need for explicit intents based on the need for a client to persist such choices across sessions? Otherwise, why shouldn't a client just be able to use regular intents, perhaps with the client pre-populating one or more choices in the list of choices (i.e. the 'suggestions' parameter)? It seems this would be better than explicit intents, after all, the user might know of a new and better red-eye removal program than the client, or not like the default client choice [2].
>
> (2) If we have explicit intents then we need to clarify the consistency and model of user implicit consent
>
> Intents and explicit intents appear to have a different user interaction model.  Let me summarize what I think the models are based on the spec and Greg's email [3]:
>
> Intents (not explicit):
>
> 1. User accesses client page and causes an event to occur (e.g. clicks 'edit button') which causes intent activity to start.
>
> 2. UA presents list of choices, user selects choice, this is implicit consent to use *that* choice. This choice can be remembered by UA.
>
> 3. Data is passed to chosen service, which is used. No consent need be obtained by service, so service can simply operate, simplifying deployment.

I think we will end up with a best-practices recommendation that
services separately verify user intention. Given that default
selections may be used by the UA, it will be jarring to use a service
which just flickers on and closes immediately, especially when that
service is used as a default.

> Explicit intents
>
> 1. User accesses client page and causes an event to occur (e.g. clicks 'edit button') which causes intent activity to start. Note that if event is on page load the user may never have made a choice.

Page load wouldn't carry a user gesture.

> 2. Data is passed to chosen service, which is used. Consent must be obtained by service (when it matters).
>
> These two models are inconsistent, both for the user and for the service provider. The explicit intent scenario opens the possibility for mistake, such as no consent being obtained by anyone, if the service does not obtain it.
> Requiring the service to obtain it is inconsistent, more work for the service provider, and possibly a  barrier for adoption of the service. [4]
>
> Step 1 is not "informed consent", as the user does not know whether the functionality is built in to the service or not and if not which 3rd party is being used, or the event may not even be the result of user action.  Thus I suggest this is not adequate - in addition the user does not know where this explicit intent is dispatched to, and may have concerns about certain providers (sometimes for good reasons).
>
> Regardless it might be more productive to focus on the consistency and functionality issues and get at the question that way:
>
> 1. how can a modular application built using explicit intents allow the user to easily substitute other choices for the functionality?
>
> I'd argue to allow regular intents, but use the 'suggestions' to provide the functionality that is now based on explicit intents. Yes, there will be one user selection but then it should be transparent.
>
> 2. how can a service avoid having to obtain consent when using explicit intents if assuming the action at the client page is not good enough ?

The consent model is intended to assure the service that the user has
made an purposeful action to invoke some operation on it, whether on
the source page (in the case when the UA is activating a default) or
on the mediating picker UI (when there is no default being used). The
registration model is intended to assure the user that no service is
activated unless they have specifically approved its use (by
"installing" it, whatever that means in the context of the UA). I
think our language here is that no intent is to be dispatched to an
endpoint until the user has approved that use for the endpoint. That's
true for explicit intents as well as regular intents.



> 3. Can we make the specification simpler, clearer and easier to understand by removing explicit intents, yet retain the functionality?
>
> I think the spec language gives a hint that consistency is an issue by first stating ' if this "service" attribute is present, it SHOULD NOT display a service selection mechanism to the user.'  and subsequently stating
> 'The User Agent MAY provide a way for the user to intercept even an explicit invocation.'.
>
> It would be much simpler if we could use the same intent mechanism uniformly.

Agreed. Where I think explicit intents are most useful is in allowing
intents to be used by apps as internal transitions, and in making it
possible to build picker-like functionality in web content. If both of
these goals should really be non-goals, or accomplished through other
means, then I think we should get rid of explicit intents. I don't see
the user consent inconsistency as it stands, however. I'd prefer an
argument for getting rid of explicit intents that directly addresses
the use case. I think we can address consistency problems, but it'd be
more interesting if the use cases themselves are either mistaken or
out of scope; then we can just get rid of it and not have to think
about consistency. :-)

> (3) Local services
>
> I'm not sure we should readily dismiss Jean-Claude's earlier concern about the risk of an explicit intent using a URL to access local device services without any mediation - though it seems this attack vector would depend more on the implementation of the API that accepts that URL and invokes the local service (a Sys Apps WG item).
>
> I suggest we add a "Security Considerations" section before the Privacy Considerations section as follows:
>
> [[
>
> 5. Security Considerations
>
> Care should be taken with any intent that is provided locally on a device to ensure appropriate access control use of device information or functionality. This is out of the scope of this specification but needs to be addressed by implementers.
>
> ]]
>
> (4) Same origin for explicit intents
>
> We discussed that explicit intents should be same origin as the client [5]. This needs to be stated in 4.1 on Explicit Intents. I assume CORS would not apply, we might need to be clear on that.
>
> (5) "speedbump" [6]
>
> Greg, To be clear, I think you are arguing against  [7] the 'speedbump' approach discussed at the F2F, and that we not require any mechanism at the service that requires consent or user interaction.
> I think we need to talk about the larger issue of whether intents would be successful and usable with 'suggestions' while removing 'service' (explicit intents).

Yes. I don't think that the speedbump accomplishes a security or
privacy goal. I do think there's a consent goal to be accomplished,
and that accomplishing it potentially looks similar to the speedbump.
(I'm not sure at this point.)

> Summary: can we address the use cases, obtain greater simplicity, consistency and understanding by removing explicit intents? If not, how should we resolve the concerns discussed by a number of people on the list around this area?
>
> I include some specific proposals - add specific use case and security considerations (we will probably have other security considerations if we think about it).
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
> [1] http://lists.w3.org/Archives/Public/www-archive/2012Jul/att-0020/minutes-2012-07-10.html#item09
>
> [2] http://lists.w3.org/Archives/Public/public-web-intents/2012Jul/0055.html
>
> [3] http://lists.w3.org/Archives/Public/public-web-intents/2012Jul/0051.html , http://lists.w3.org/Archives/Public/public-web-intents/2012Jul/0058.html
>
> [4] [a] http://lists.w3.org/Archives/Public/public-web-intents/2012Jul/0064.html
>
> [5] http://lists.w3.org/Archives/Public/public-web-intents/2012Jul/0045.html
>
> [6] http://lists.w3.org/Archives/Public/public-web-intents/2012Jul/0061.html
>
> [7] http://lists.w3.org/Archives/Public/public-web-intents/2012Jul/0062.html
>
>
>
>

Received on Friday, 7 September 2012 17:16:42 UTC