W3C home > Mailing lists > Public > public-device-apis@w3.org > June 2010

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

From: James Salsman <jsalsman@gmail.com>
Date: Mon, 14 Jun 2010 02:19:51 -0700
Message-ID: <AANLkTinFJKzqlenjKU6pGXtWoFyp_QIHB9wbRxqLcLHT@mail.gmail.com>
To: Kenton Varda <kenton@google.com>
Cc: Tyler Close <tyler.close@gmail.com>, public-device-apis@w3.org
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.

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.
Received on Monday, 14 June 2010 09:20:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:10 GMT