Re: Powerbox, revocation, modeless singular(?) dialogs, ACTION-188 (was Re: [Powerbox] New draft ...)

On Fri, Jun 18, 2010 at 9:37 AM, Kenton Varda <kenton@google.com> wrote:
> On Mon, Jun 14, 2010 at 2:19 AM, James Salsman <jsalsman@gmail.com> wrote:
>> On Wed, Jun 9, 2010 at 5:52 PM, Kenton Varda <kenton@google.com> wrote:
>>> On Tue, Jun 8, 2010 at 1:22 PM, James Salsman <jsalsman@gmail.com>
>>> wrote:
>>>>...
>>>> "Receiver" would make more sense to me in that context.
>>>
>>> Reasonable, although it's odd to think of the "receiver" as initiating
>>> the interaction, and of course it may not actually receive anything.
>>>  I'll leave this up to Tyler.
>>
>> Access to output devices such as speakers could be requisitioned in
>> the same way? I would love to mute sites selectively by domain! In
>> that case "accessor" would be better than "customer" or "receiver".
>>
>>>> ...If access defaults to denied (opt-in) and the permission granting
>>>> interface were the same as the permission revocation interface, modulo
>>>> a single boolean parameter (e.g. at the UI level with two radio
>>>> buttons and a "remember" checkbox such as in Adobe's Flash device
>>>> permissions dialog), that would make it a lot more likely that both
>>>> grants and revocations would be implemented.
>>>
>>> I'm not sure I understand.  The powerbox UI is only displayed when a site
>>> requests access to a resource.  It would be awkward to present a revocation
>>> interface for previous grants at the time of requesting a new one, and each
>>> request is independent, so we have no basis for displaying previous grants
>>> anyway.  How would you integrate revocation into this?
>>
>> I am hoping that the revocation interface can be a unified list of all
>> remembered permissions, with columns for device names, domains or some
>> other unambiguous description of who has been granted or denied access
>> to the device in each case, whether the permission was granted or
>> denied (alternately, remembered permissions and denials could be
>> grouped in separate sections of contiguous rows, if horizontal screen
>> space is at a premium), a column of revocation buttons, and possibly,
>> optionally, a column of date and timestamps, when there is enough
>> display width or maybe with horizontal scrolling.
>>
>> The Powerbox draft of 26 May 2010 says: "For more involved interaction
>> patterns, dealing with revocation might be inescapable. In this case,
>> the Provider  should keep track of granted permissions for provided
>> resources and provide a user interface for reviewing and revoking
>> outstanding permissions." -- Perhaps you should offer a modeless
>> dialog such as "_(accessor)_ is requesting access to the _(device
>> name)_: [Permit once] [Always allow] [Deny once] [Never allow]", but
>> only one at a time, with each required to be addressed before the next
>> is presented to the user.
>
> So, this is fundamentally not the way the powerbox works.  The customer does
> not request access to a particular device, it just asks for a particular
> type of resource.  The user then selects which resource to use.  The UI, *by
> design*, does not present a yes/no question to the user.  Therefore, "always
> yes" and "always no" don't make sense.
> Once selected, the provider may present a UI to the user asking how long the
> grant should last.  This UI understands the resource type and so can be
> tailored to ask the questions that make sense for it.

When the user selects a resource, perhaps there should be a "remember"
checkbox.  If the user denies the request for a type of resource,
perhaps there should also be a "remember" checkbox.  If those sorts of
things aren't specified, people are likely to be upset when they
aren't offered.

>> ACTION-188 needs a way to say the same thing:  a modeless dialog which
>> can't occur more often than one at a time.  Is "singular" a good term
>> for that?
>>
>> I also wonder what it means to permit access to the microphone,
>> camera, file system or contacts database "once" instead of "always" --
>> if we don't have a specific and operational definition that would be a
>> problem.  Does accessing the microphone once mean being able to make a
>> single recording (of any length?) Does accessing the contacts database
>> once mean reading a single contact?  If so, should that contact be
>> displayed with the permission request notification?
>>
>> The Powerpox draft goes on to say: "This user interface should be
>> accessible from the page referred to by the home attribute of the
>> Provider Document." -- I think this is the essence of my issue
>> earlier: a revocation interface with permissions for each device
>> listed in a separate location is worse than one with all the granted
>> permissions to be listed together. I can think of no reason they can't
>> or shouldn't all be in the same place.  People will appreciate being
>> able to review all of their permissions grants when they are thinking
>> about revoking just one, as long as the list doesn't grow too long.
>> The alternative, requiring the user to find the providers' "home"
>> attribute url and visit it, may usually be at least as much trouble as
>> a centralized permissions revocation list.
>
> What about an interface which allows the user to see a history of grants
> made, and click through any one of them to open that provider's "home"?
>  This way, we don't need to define an additional API between the UA and
> provider.  This is good because it would be hard to design an API that is
> appropriate for all provider types.

I'm not sure, a history of grants made seems useful, but not as much
as being able to review and remove current permissions.

Received on Friday, 25 June 2010 23:00:12 UTC