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

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

From: James Salsman <jsalsman@gmail.com>
Date: Tue, 8 Jun 2010 13:22:22 -0700
Message-ID: <AANLkTik6bZOX9f6D6_koXPT-uIGhdtzOGJLqiFDbT8Zd@mail.gmail.com>
To: Kenton Varda <kenton@google.com>
Cc: Tyler Close <tyler.close@gmail.com>, public-device-apis@w3.org
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 GMT

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