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

Re: [Powerbox] New draft based on further collaboration and prototyping

From: James Salsman <jsalsman@gmail.com>
Date: Thu, 27 May 2010 14:17:53 -0700
Message-ID: <AANLkTikAufjWTaWCaJktOKDhNdY2mC3POZ1IqIet7j1z@mail.gmail.com>
To: Kenton Varda <kenton@google.com>
Cc: Tyler Close <tyler.close@gmail.com>, public-device-apis@w3.org
On Wed, May 26, 2010 at 5:15 PM, Kenton Varda <kenton@google.com> wrote:
> On Wed, May 26, 2010 at 4:19 PM, James Salsman <jsalsman@gmail.com> wrote:
>>
>> I, for one, would feel a lot more comfortable if there was a MUST
>> normative direction to provide a way for users to browse, and rescind
>> at their option, all of their granted permissions, without having to
>> depend on a provider's home interface.
>
> Are you hoping for this to work without communicating with the provider's
> server at all?

I think so.  Why would that be difficult?  Do you contemplate
recording a list of "provided resource URL"s in the user's browser?
Why can't they be annotated with a human-readable description and the
customer sites for which they provide access, and listed, each with a
"revoke" button or link which would cause access to the resource to
fail if selected?

Say there is a USB microphone -- if it were physically unplugged you
would want an attempt to access it to fail, and I hope you contemplate
some kind of error diagnostic in a case like that (although I can't
find anything saying so in the Powerbox draft.)  I don't see why you
couldn't have a similar HTTP error condition for user-revoked access.

> Or, are you just saying you don't trust providers to
> implement a proper revocation UI and so would like to require that they
> honor an API as well?

Well, device drivers in general don't always implement complete
functionality, so from my perspective, having thought about this for
less than a day so far, I can't see why a revocation API would be less
complicated than a separate review-and-optionally-revoke user
permissions list interface which -- if revocation were selected by the
user -- would cause errors similar to, but not the same as, the error
you would expect when a device is disconnected.

> On the other hand, there are a few benefits to an API, other than being a
> better-defined requirement:
> * The UA could provide a unified interface to see and manage all grants ever
> made.

I'm not seeing why an API is necessary for that.

> * The UA could implement automatic revocation of grants when the user
> navigates away from the customer site, which I believe will end up being the
> desired policy in the majority of use cases.  (Some use cases call for
> long-lived grants, of course.)

I agree strongly with the idea of offering a choice between permanent
and host site-based session access, which is what Abobe Flash offers
for microphone and webcam access.

Best regards,
James Salsman
Received on Thursday, 27 May 2010 21:18:26 GMT

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