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

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.


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