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: Sat, 5 Jun 2010 15:57:34 -0700
Message-ID: <AANLkTikV8K_FQadXPLBVntA7lWO3gTiQzNggBNNj1hsY@mail.gmail.com>
To: Kenton Varda <kenton@google.com>
Cc: Tyler Close <tyler.close@gmail.com>, public-device-apis@w3.org
On Fri, Jun 4, 2010 at 10:34 PM, Kenton Varda <kenton@google.com> wrote:
> In the Powerbox doc, the "customer" is the site which requests and receives
> access to the resource, while the "provider" is the site implementing and
> exporting the resource.

You propose that devices, the file system, and databases like contacts
be provisioned as RESTful servers on user hardware under the Powerbox
scheme?  How will that work over NATs?

>  Neither is a person.

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?

> It is our intent that grants (of non-public resources, at least) should
> always be revocable.

Good.  How do you intend to manifest that intent in your proposal?

> However, once a communication channel exists between
> the customer and provider sites, it is technically impossible to enforce
> revocability without cooperation from at least one of them.

Revocability can always be enforced at the physical layer, and any
user with physical access to a system MUST be able to do the
equivalent without resorting to wire cutters, in my reading of the DAP
policy document.

> server-to-server communication is useful for performance reasons

I'm a huge peer-to-peer fan, but again, the reality of NATs is not
going away any time soon.

> Therefore, requiring all communication to pass through the
> user agent seems like a net loss -- it does not provide any real security
> guarantees, it harms performance, and it severely limits protocol
> flexibility.

Do you have any support for those assertions?  A user agent can
establish a persistent stream, decide whether or not to do so with a
javascript or native application, and I don't see any examples of the
flexibility to which you refer.  With typical support from modern
operating systems, socket references can often be communicated to
processes other than the user agent.  Pseudoterminals have been an
established technology for doing so since at least the 70s on unixes.

> You can make the argument that if Powerbox-negotiated channels start out
> proxied through the UA, then it would help protect the user against provider
> implementations that are simply too lazy to provide a revocation interface.


>  However, I think this is a fairly weak argument next to the costs involved
> in proxying.  It is in the best interests of providers to be secure and
> prevent exploitation of their services, and to that end they will implement
> revocation.

Weak?  Are you suggesting that security through wishful thinking is acceptable?

> If Facebook decides to give my data to a third party against my wishes, what
> technical means could I possibly use to stop them?

Stop giving them your data.  The same works for school administrators
eavesdropping on students at home through fixed laptop cameras and
microphones, which has also been in the news recently, as well as in
the courts now.
Received on Saturday, 5 June 2010 22:58:05 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:44 UTC