- From: James Salsman <jsalsman@gmail.com>
- Date: Fri, 25 Jun 2010 15:59:44 -0700
- To: Kenton Varda <kenton@google.com>
- Cc: Tyler Close <tyler.close@gmail.com>, public-device-apis@w3.org
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