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

How would you match any particular powerbox request with a previously
"remembered" response?  Even two requests made by the same page for the same
resource type may be for fundamentally different purposes.  This is why it
has to be up to the customer side to remember the grant by holding on to the
URL, and up to the provider to decide (hopefully through consultation with
the user) whether to honor that URL long-term.

On Fri, Jun 25, 2010 at 3:59 PM, James Salsman <jsalsman@gmail.com> wrote:

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