[cap-talk] Granting access to web services

[Kenton Varda]

On Thu, Feb 11, 2010 at 7:36 AM, Mark Seaborn <mseaborn at chromium.org> wrote:

> Yes, the widget would be a DOM element, implemented by the browser and
> rendered as a button.
>
> For requesting a service, we can use <input> with a new "type" attribute
> value, or use "type=file" so that it falls back to file upload on browsers
> without powerbox support.
>
> For registering a provider, <input> is not appropriate.  <input> works for
> file upload but there is no equivalent for file download, so I think we'd
> want a new element, but I'm not sure what to call it.  Probably not
> "<output>". ;-)
>
> We should provide Javascript libraries implementing these widgets -- maybe
>> the scripts would actually be hosted by the powerbox server?
>>
>
> I'm not sure what you mean here.  If the widgets aren't implemented by the
> browser (in the ideal case, not a prototype), what would a library
> implement?
>

I see your @chromium.org e-mail address, but my experience so far is that
the Chrome people have zero interest in entertaining this idea.  So, I'm
operating under the assumption that there will be no browser support ever.
 If that turns out wrong, great!  But I think we're most likely to be
successful if we don't rely on support from chrome or W3C.


>
>
>>  - In addition to the UI you describe, we should support drag-and-drop
>> direct from a provider site to a requester site.  As with drag-and-drop for
>> opening files, power users will find this more convenient than going through
>> "save" and "open" dialogs.  This is straightforward to implement if the
>> provider and requester use widgets like I described in the previous point.
>>
>
> I was thinking that the request-service and register-provider buttons could
> be overloaded so that not only can you click on them to open a dialog, you
> can also drag-and-drop one onto the other to perform a grant.
>
> This would work fine for non-interactive providers.
>
> I am not so sure about interactive providers.  We could open a new tab
> after the drag-and-drop, but this seems like it would be disorienting.
> There is some precedent for requiring further interaction after a
> drag-and-drop:  on Windows, right-button-dragging a file opens a menu to
> choose between Copy, Move and Create Shortcut.  However, that is only a
> small menu.
>

I think the whole "interactive providers" thing is not necessary in the
drag-and-drop case anyway.  Remember that in a drag-and-drop scenario, the
user already has the provider site open.  Therefore, if any interaction
needs to be done with the provider, the user can just do it before making
the grant.

For example, in the camera case, the user would use the camera's web
interface to take a picture, then drag and drop *just the picture* onto the
requester.

This suggests that maybe the whole "interactive provider" idea is a bit
overcomplicated.  Maybe we should be thinking of it as the power box
providing links to sites which might be used to obtain the desired resource.

So for example, if a requester wants a picture, the power box would present
the user with:
- Use blank picture.
- Use your avatar picture.
- Link to paint app, which you can use to create other pictures.
  - List of previous pictures created with this app.
- Link to camera app, which you can use to take pictures.
  - List of previous pictures created with this app.
- Link to filesystem app, where you might find pictures.
  - List of recently-opened picture files.

When the user clicks on one of the links, it opens in a new tab, and the
powerbox somehow signals to the site that a resource of a particular type is
desired.  The user interacts with the site, and then it posts the resource
back to the powerbox.

I guess it ends up being the same thing, but sounds less complicated when
explained this way.


> I must say I have a hard time imagining how cross-tab drag-and-drop can be
> made easy-to-use.  Wouldn't the user have to arrange two browser windows
> side by side?  Or would the browser provide a shortcut to open two tabs side
> by side in the same window?  I don't think I've ever used drag-and-drop
> between browser tabs.  The last GUI I used that used drag-and-drop
> extensively like this was RISC OS.
>

Maybe I'm unusual in that I often use multiple browser windows in addition
to multiple tabs.  In Chrome, you can just tear off one of the tabs to make
both visible at once, then drag/drop.  I can say confidently that this would
be the most usable interface for *me*.  If other people find other
interfaces more usable, then we should provide those interfaces too.


>
>  - The powerbox should provide a UI for visualizing all established
>> connections between requesters and providers, showing activity occurring on
>> these connections, and allowing the user to revoke connections.
>>
>
> In my proposal the browser/powerbox does not mediate the connections, so it
> cannot show activity on those connections.  In fact, it cannot enforce
> mediation, because the two parties involved have network access and can
> arrange to bypass any mediation.
>
> So it's up to the provider to offer a review and revocation facility, which
> can be reached via its info_url.  I think this is more useful than putting a
> revocation facility into the browser/powerbox, because the provider can
> display the information in the form that is most appropriate to the service
> it provides.  If a provider doesn't offer revocation, it's possible to wrap
> it to make a provider that does.
>
> That said, it may be useful for some services to voluntarily be mediated
> through the browser/powerbox, so that they can be revoked automatically when
> the tab is closed, e.g. for tab-lifetime-limited camera access.
>
> Also, the powerbox can keep a log of all the grants it has established,
> even if it can't revoke them itself.
>

Right, I was imagining a voluntary system where essentially the powerbox
advises the requester and provider that the user no longer wants this
connection open.  If both the requester *and* the provider chose to conspire
to keep the connection open, they can do so.  But that seems unlikely -- in
almost all cases, at least one of the two would be "on the user's side".

My point here was more about making things accessible to the user.  If I
want to know what grants I have made, I shouldn't have to go around to every
provider to check.  And if I need to revoke a grant quickly, I should not
have to browse through some possibly-badly-designed web site to do it.  The
powerbox seems like a good place to put a unified interface for this.

And sure, the provider should provide its own interface, too, with
additional information.  In fact, maybe it should even provide a gadget
which can be integrated into the powerbox UI.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20100212/0d48fc8d/attachment.html