W3C home > Mailing lists > Public > public-web-intents@w3.org > August 2012

Re: Explicit intents privacy concern

From: Greg Billock <gbillock@google.com>
Date: Fri, 24 Aug 2012 11:32:41 -0700
Message-ID: <CAAxVY9c__-URMc13HAsuXecF2AQL=czZRT7PciACG1o5Ok052g@mail.gmail.com>
To: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
Cc: public-web-intents@w3.org
On Fri, Aug 24, 2012 at 2:34 AM, Jean-Claude Dufourd
<jean-claude.dufourd@telecom-paristech.fr> wrote:
> On 27/7/12 17:17 , Greg Billock wrote:
>>
>> On Fri, Jul 27, 2012 at 3:58 AM, John Lyle <john.lyle@cs.ox.ac.uk> wrote:
>>>
>>> Should all intent services provide an authorisation step (or perhas
>>>
>>> an 'undo' step) when they receive a request made via intents?
>>
>> Basically, yes. The best practices there are to provide a confirmation
>> or verification step for the user.
>>
> JCD: Ooops ? This means that for normal intent invocation, there will be two
> consenting user actions, and for explicit intent invocation, only one.

In most cases, we expect the user will be using a default, and so not
see the picker at all.

The two consenting user actions, in both explicit and normal cases,
are 1) the gesture on the client page enabling startActivity(), and 2)
the confirming gesture (recommended) on the service side, confirming
the completion of the task. (Obviously there may be a lot more
operations on the service side, depending on what's being done.)

> This sounds bad.
> It would be much better to have a unified behaviour between normal intent
> invocation and explicit intent invocation (i.e. always require active
> consent), so that the intent provider does not need to impose a (possibly
> second) consent action.
> 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 Friday, 24 August 2012 18:33:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:47 UTC