Explicit intents - Discussion and proposals

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. 

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.

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.

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 ?

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.

(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).

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 14:36:33 UTC