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

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

From: Kenton Varda <kenton@google.com>
Date: Wed, 9 Jun 2010 17:52:00 -0700
Message-ID: <AANLkTikk1sa5sq3dN-JE0-iPwkg5KYRFH3QRRem0tQ6E@mail.gmail.com>
To: James Salsman <jsalsman@gmail.com>
Cc: Tyler Close <tyler.close@gmail.com>, public-device-apis@w3.org
On Tue, Jun 8, 2010 at 1:22 PM, James Salsman <jsalsman@gmail.com> wrote:

> On Mon, Jun 7, 2010 at 5:11 PM, Kenton Varda <kenton@google.com> wrote:
> >
> >... we propose that the UA exposes local devices at URLs which can receive
> > XMLHttpRequests within the same browser instance.  Thus these devices
> look
> > exactly the same as web servers to said scripts.  This allows the same
> > Javascript code to be used to access local devices and remote devices,
> which
> > is clearly valuable in the case of devices like contact lists and
> calendars.
>
> In that case, I can't see why the browser or UA can't handle
> permission management per the DAP policy spec directly.
>

It can.  For local devices, the UA is the provider.  So if the powerbox spec
says that the provider must provide a revocation interface, that means the
UA must provide that interface.


> To avoid further misunderstandings on my part -- and thank you for
> clearing that one up; I'm sorry it got us sidetracked with so many of
> my questions (e.g. about NATs) being irrelevant -- are you using the
> terms "user agent" and "browser" interchangeably here?
>

Yes.


> >> Referring to a web site as a customer -- a term which usually connotes
> >> if not denotes the ultimate beneficiary of a service -- makes it
> >> difficult to understand your proposal.  If some other web site is
> >> referred to as a customer of my input devices, contacts list, or file
> >> system, I am inclined to wonder whether the referrer is putting their
> >> interests above mine.  Is that reasonable?
> >
> > What word would you prefer?
>
> "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.


> > The best I think we can do is require that providers implement a
> revocation interface.
>
> I agree, but you may be able to go further: ...
>
> >... if the provider implementation is not interested in being
> > secure, there is nothing we can do in the protocol to make it secure.
>
> ...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?
Received on Thursday, 10 June 2010 00:52:51 GMT

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