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

Re: Explicit intents privacy concern

From: Greg Billock <gbillock@google.com>
Date: Fri, 27 Jul 2012 08:17:51 -0700
Message-ID: <CAAxVY9esJODD5+48j7B2_skrxPdG+q9jJbuaZOtQf-63qBk4aQ@mail.gmail.com>
To: John Lyle <john.lyle@cs.ox.ac.uk>
Cc: public-web-intents@w3.org
On Fri, Jul 27, 2012 at 3:58 AM, John Lyle <john.lyle@cs.ox.ac.uk> wrote:
> On 25/07/12 18:22, Greg Billock wrote:
>>
>>
>> My argument is that what this means is that if that service is trying
>> to pass this data (explicitly) to another service, they'll just use
>> some other way to do it. I think this is an unnecessary and possibly
>> deleterious complication we should not introduce.
>>
>
> This is probably a stupid question, but what should my expectations be as an
> intent service provider?
>
> If I am an intent service, should I assume that the fact I'm receiving data
> originally from an intent invocation implies that there has been some form
> of user consent through the user agent for this action?  Because for normal
> intent invocation that seems reasonable.  But for explicit intents, that
> isn't the case.
>
> For example: an intent service which 'shares' an image by posting it to my
> social network profile.  If all intents require user consent then the social
> network intent service doesn't necessarily need to implement a consent stage
> itself.  After all, it may know that the request is coming from an
> authenticated user session, and the expected use pattern of clicking on a
> 'share' button is a pretty good indicator of consent.
>
> Should all intent services should 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.

>
> Thanks,
>
> John
>
>
> --
> John Lyle
> Research Assistant
> Department of Computer Science, University of Oxford
>
>
Received on Friday, 27 July 2012 15:18:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 July 2012 15:18:24 GMT