[cap-talk] Granting access to web services

[Mark Seaborn]

Hi Dirk,

Thanks for your feedback.

On Fri, Feb 12, 2010 at 5:55 PM, Dirk Pranke <dpranke at chromium.org> wrote:

> Hi Mark,
>
> In reading this, I suspect I may have some of the same concerns that
> Tyler had about including too-many "cap-talk"-specific technologies
> without the obvious reason for them being there. The design doc is a
> bit elliptical and, having sufficient context I can reconstruct most of the
> design choices but I think it would be preferable to be explicit about
> them.
>

Fair criticism, I think.  The document is basically a tidied-up version of
my notes.  I can add some of the explanation below in order to explain the
design choices.


The way I looked at the spec, I saw I few different things.
>
> The first was a general powerbox UI flow for new services. While this
> idea by itself is pretty straightforward, what you're attempting to do
> with it isn't, IMO. Namely (a) you're attempting to make it generic,
> (b) you are supporting multiple providers, and (c) you are attempting
> to describe a way to register providers. I think it would be good to
> motivate each of these decisions and try to give examples that it will
> be workable and pleasing.
>

a) We are attempting to make this generic for two reasons:

* It is clear that there are many types of service that could use this
rendezvous/grant facility.  The list of use cases currently has 13 items.
It is likely that there are further uses that we have not thought of.  The
aim of the proposal is that new services can be implemented without having
to change the browser.

* We want to provide a uniform user interface across the different service
types, to help the user to develop expectations about how the UI works.  If
every type of service had a different trusted UI, the user's experience with
one would not carry over into another.


b) We are supporting multiple providers because:

* There are often genuinely multiple choices.  For selecting a image file,
there is a choice between:
 - taking a photo with a built-in camera
 - uploading an image from a local file
 - selecting an image from a photo album, e.g. on Flickr
 - selecting an image from a general-purpose cloud filesystem, e.g.
Tahoe-LAFS

* Even for services where there is usually only one choice, multiple choices
are still possible.  e.g. For geolocation, I can only be in one place at a
time (quantum physics notwithstanding).  However, it is still useful to
select another entity's location, e.g. to plot the location of my cat's GPS
tag on a map.

* If we can ask multiple choice questions, we are avoiding yes-or-no "Is
this OK?" security questions.  The user is performing an act of designation,
not merely confirmation.  This aims to follow the "not one click for
security" principle (to use the slogan from the title of the ScoopFS
paper).  Yes-or-no questions are usually bad because they do not offer the
user a genuine choice.

* Even if the filtered list of providers sometimes contains only one item
(e.g. geolocation), we hope the user will understand that they have a
choice, by virtue of having been exposed to the same UI in the
multiple-choice case.


c) We are attempting to provide a UI for registering new providers.  We
expect that some providers will be built-in/pre-installed -- in particular,
local devices, such as camera, audio, geolocation, and maybe a local
printer.  But other providers cannot be pre-installed, because they are
specific to the user accounts of whatever remote web services users choose
to use.

We also want to provide a means for building new services out of existing
services.  For example, a user concerned about privacy might want a
time-limited geolocation service which provides geolocation data for some
period of time before expiring.  A built-in geolocation service might not
provide this.  The user has the option of wrapping the built-in service with
one that provides this revocation feature.

An alternative to explicit registration of services with the powerbox is
some kind of implicit registration.  Consider the example of granting a
social networking site access to your Gmail contacts list.  Perhaps having
Gmail open in another tab is sufficient for your Gmail contacts to be listed
in the powerbox.  Gmail could advertise its contacts provider to the
browser/powerbox through a <link> element.


For example, the genericity of the dialog: access to a camera is
> straightforward, but how do we cleanly build a UI that allows for all
> of the other uses cases as well? It feels like either you get one
> uber-complex dialog, or you get a multi-stage dialog that could
> perhaps be too painful for any single use case. By virtue of it being
> generic, do we open the risk that the requesting web page has too much
> control over the parameters (and hence the user clicking on a single
> "GET" button can't perceive the complexity and/or react accordingly)?
>
> For multiple providers, do we believe that this will be a common
> occurrence?


Yes, I think so.  I went through a list of potential use cases and found I
could come up with a story for every type for why there could be multiple
providers:
http://plash.beasts.org/wiki/WebPowerbox/UseCases

There are very few object types that are really singletons.

Or more strongly, that any UI designer will actually allow
> someone to be exposed to this choice?
>

You mean a browser UI designer?  I don't see why not.  Browsers present all
kinds of choices.  The choice the powerbox presents is certainly more
meaningful than the interaction involved in clicking through a warning about
a self-signed certificate.

If I right-click on a link in Firefox, I get a choice between
 * Bookmark This Page
 * Save Link As
 * Send Link
 * Copy Link Location
This seems like a similar kind of choice.  There are 4 built-in providers
for sending URLs to:
 * bookmarks
 * filesystem
 * e-mail
 * clipboard

For service types where only one provider is configured, the browser could
be configured to jump straight to the provider tab (assuming it is an
interactive provider) without presenting a list of providers.

For example, to select a file to upload, the browser can jump straight to
the local file chooser if no remote file choosers or image capturers are
configured; or image capturers could hang off a trusted local file chooser
tab.

It's OK for some providers and service types to be given special treatment
by the browser.  It's just that there should be fallback behaviour for
service types that the browser doesn't know about.


For registering providers, I'm a little hesitant about the whole
> concept of multiple providers here. I'm not sure that you can sensibly
> paper over the local/remote distinction in the type of resource you're
> giving access to. For example, in a camera API, something has to
> actually fetch the image. If the provider is local, the image is
> local. If the provider is remote (e.g., Picasa), is the browser
> responsible for fetching it and then turning it into a real image that
> gets uploaded (or handed to the caller)?


In principle, the web app can fetch the image data from the service with a
GET request, and then do with it whatever it wants (display it locally or
upload the data with a POST).

In practice, two things get in the way:

* Support for handling binary data in Javascript is not very good.  We can
get around this by passing the image by reference, by passing around the
image URL instead of image data.  So the image can be displayed by using the
image web-key in an <img> element.  If we want to copy an image from Flickr
to Facebook, we can pass Facebook the Flickr image URL; the browser does not
need to fetch and re-upload the image.

* Being behind a NAT/firewall gets in the way.  Though we can pass Facebook
a Flickr URL, we can't pass it a URL served by a local camera web service.
Tyler's idea is that an image service URL can support two operations:
  - GET, which returns the image data.
  - POST, which takes a URL argument X, and POSTs the image data to X.
Hence a web app can ask the local camera web service to POST the image data
to Facebook.


Also, this assumes that
> everyone implements the same service provider API, which seems like a
> pretty big assumption.
>
> In the case of choosing between a "live" local image and a previously
> stored one (or a "live" GPS location and a fake client-specified one),
> it makes sense, but again I'm a bit worried that we'd be building in a
> bunch of complexity that would never see the light of day (I'm
> thinking of the "accept" attribute on the input type="file" element
> here, which AFAIK was maybe only implemented by Opera).
>

Actually "accept" is also implemented in the Android web browser.  If a web
app accepts image files, you get a choice between selecting an existing file
or going to the camera app to take a photo.  This influenced the idea of
interactive providers in the Web Powerbox proposal.

(Well, I have seen that demonstrated in Android, but when I tried using
Flickr on my Android phone just now, I just saw buttons labelled "Uploads
Disabled".)


Then, you have the whole petname/webkey aspect of the proposals, which
> are somewhat orthogonal.
>
> And the aspects about permission management which is perhaps out of
> scope for your proposal.
>

By permission management do you mean review and revocation of grants?

Cheers,
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20100213/91a4d63c/attachment.html