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

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?