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

On Sat, Jun 5, 2010 at 3:57 PM, James Salsman <jsalsman@gmail.com> wrote:

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


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


> How will that work over NATs?
>

Access must be from Javascript running in the browser, unless the device's
protocol allows for negotiating a direct connection (which would be up to
that protocol, and outside the scope of the powerbox spec).


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

What word would you prefer?


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

The best I think we can do is require that providers implement a revocation
interface.


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

Right.  In this case, the provider is the local system, and it is up to the
local system to implement a revocation interface for the devices it
provides.  I'm not sure I understand your objection here.


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

I don't think NAT is a large barrier here.  Given that the user agent must
necessarily be directly connected to both the customer and provider sites
already, it's unlikely that they are behind mutually-exclusive NATs.  And
server-to-server communication is an optimization; in the worst case, the
app can fall back to messaging through Javascript.


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


I supported all three assertions in my previous message.


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

All of these points assume one end is a local device, connected to the same
machine as the user agent.  We're trying to propose a solution which allows
for web services and local devices to be treated the same.  Again, this is
clearly important for things like contact lists and calendars.  It's also
important for the thin-client future where "local devices" won't all be
connected to the same machine.


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

I'm saying that if the provider implementation is not interested in being
secure, there is nothing we can do in the protocol to make it secure.
 Trying to do so is a waste of effort, adding costs with only illusionary
benefits.