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

On Fri, Jun 4, 2010 at 1:49 PM, James Salsman <jsalsman@gmail.com> wrote:

> On Fri, Jun 4, 2010 at 10:59 AM, Kenton Varda <kenton@google.com> wrote:
> > Sorry for the delay; I was on vacation.
> > On Thu, May 27, 2010 at 2:17 PM, James Salsman <jsalsman@gmail.com>
> wrote:
> >>
> >> On Wed, May 26, 2010 at 5:15 PM, Kenton Varda <kenton@google.com>
> wrote:
> >> > On Wed, May 26, 2010 at 4:19 PM, James Salsman <jsalsman@gmail.com>
> >> > wrote:
> >> >>
> >> >> I, for one, would feel a lot more comfortable if there was a MUST
> >> >> normative direction to provide a way for users to browse, and rescind
> >> >> at their option, all of their granted permissions, without having to
> >> >> depend on a provider's home interface.
> >> >
> >> > Are you hoping for this to work without communicating with the
> >> > provider's
> >> > server at all?
> >>
> >> I think so.  Why would that be difficult?  Do you contemplate
> >> recording a list of "provided resource URL"s in the user's browser?
> >> Why can't they be annotated with a human-readable description and the
> >> customer sites for which they provide access, and listed, each with a
> >> "revoke" button or link which would cause access to the resource to
> >> fail if selected?
> >
> > The problem is that in the current proposal, the provision is an
> arbitrary
> > message sent from the provider to the customer.  It is likely to contain
> > URLs which the customer will then use to contact the provider directly.
> >  Such communication is not obliged to go through the browser, and thus
> the
> > browser has no way of revoking such communication without the cooperation
> of
> > at least one of the two sites.
>
> I'm sorry, I read the proposal, but I thought the customer was a
> person, not a site.  Would you please explain the sense in which you
> are using the word customer?
>

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.  Neither is a person.


> Do you think that the DAP policy document allows situations in which
> permissions can not be revoked?  It seems to me that it does not, but
> my interpretation of the implications stated and diagrammed in could
> be flawed.
>

It is our intent that grants (of non-public resources, at least) should
always be revocable.  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.  If the two
sites wish to conspire against the user, one can always simply pass an
address to the other and open a direct channel, which the user obviously has
no way to block.

Meanwhile, server-to-server communication is useful for performance reasons
in many cases.  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.

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.

Note that for local devices, it can be the browser's responsibility to
provide the revocation interface, rather than device drivers'
responsibility.  This is more reasonable because a device driver can be
sandboxed in such a way that it doesn't have direct internet access -- thus,
unlike two arbitrary web sites, it would *not* be possible for a device
driver to conspire to form a direct channel to a customer site.  In any
case, this requirement would be part of a separate spec, as the Powerbox
spec does not distinguish between local devices and web services.


> > We assume that at least the provider is interested in cooperating with
> the
> > user's wishes....
>
> Is such an assumption safe over time?  Facebook's privacy policy
> changes are a useful example in the news.
>

If Facebook decides to give my data to a third party against my wishes, what
technical means could I possibly use to stop them?  I don't think there's
anything any standard can do about this.  The only defense is not to store
data with Facebook in the first place.


> > So, to revoke grants, we must talk to the provider.
>
> What do you contemplate as the ideal failure mode when a USB webcam
> which had been requisitioned under powerbox is unplugged?
>

Probably, the webcam's RESTful interface begins returning 500-level errors.
 Alternatively, the webcam API could define some mechanism for communicating
this event cleanly.  That would be up to the webcam protocol; the Powerbox
spec is agnostic.