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

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.

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?

>> 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.

> 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.

Received on Tuesday, 8 June 2010 20:23:05 UTC