Re: [Powerbox] Fine-grained and non-installed providers

On Sun, Feb 28, 2010 at 6:09 AM, Mark Seaborn <mseaborn@chromium.org> wrote:

> On Sat, Feb 27, 2010 at 1:25 AM, Kenton Varda <kenton@google.com> wrote:
>
>> Recapping our lengthy discussion today:
>>
>> 1) We agreed (I think) that the powerbox should not only present
>> "installed" providers, but also any provider advertised in any
>> currently-open tab (including both <link> and <a> tags).  This allows the
>> user to quickly form connections between open tabs and to avoid cluttering
>> the installed provider list with providers she does not intend to use
>> frequently.  I think this will be a big UI win.
>>
>
> Let's call this UI idea "implicit temporary registration".
>
>  * "Implicit" because the user does not have to take any action beyond
> visiting a site for the site's providers to be listed in the Powerbox.
>  * "Temporary" because the providers are only listed while the providing
> site's tab is open.
>
> Firstly, I don't think this would work for <a> links.  If you open a
> directory listing of a Tahoe distributed filesystem, for example, it could
> contain a large number of <a rel=provider> links for registering each file
> or directory as a provider.  The browser/powerbox is not in a good position
> to nicely format its own display of this listing: this is best left to the
> original page.
>

OK, but if the page provides multiple resources which the user may be
interested in, how does the user choose one without installing it?  The goal
here is to avoid requiring the user to install every provider they wish to
use, because in many cases they may intend to use the provider only once.

We could say that the powerbox does not list <a> elements of open tabs, but
the page can provide multiple <link rel="provider"> elements, all of which
will be listed.


> It seems like this has a discoverability problem:  How would the user
> discover that they need to have Gmail open in another tab in order to grant
> Facebook access to their Gmail contacts?  Maybe there could be a note in the
> Powerbox dialog that suggests opening another tab.  Perhaps you could draw a
> sketch of how you would expect the Powerbox dialog to appear (like the
> diagram on http://plash.beasts.org/wiki/WebPowerbox)?
>

I imagine that the powerbox list would show a section titled "Currently-open
tabs".  This should make it obvious that if a currently-opened tab provided
the desired resource, it would show up there.


> The "implicit" aspect seems like it might allow a malicious site to spam
> the the user's list of providers, and maybe to spoof legitimate providers.
> So attacker.com might offer a printer provider, in the hope that the user
> selects this instead of a real printer.  Maybe you can mitigate the spoofing
> problem by listing providers along with the tab they come from in the
> Powerbox dialog, but this means you are now expecting users to identify tabs
> in a different context from usual.
>

Yes, I imagine that currently-open tabs would be listed separately from
installed providers.  They should also show the domain name of each provider
before the title, and a link to "go to this tab".  Given this, I don't think
spamming or spoofing are major concerns.


> How would implicit registration handle iframes?  Would you use the <link>
> elements from only top-level frames?
>

Good question.  They could be listed as subordinates of the parent frame,
perhaps collapsed by default.  Or they could just not be listed at all.  The
latter is probably safest.


>
>
>> 2) Since (1) means many pages would expose fine-grained providers even
>> when they don't intend for the user to install them, the UA should not
>> prompt the user every time a provider is encountered.
>>
>
> Yes, clearly the browser should not prompt the user just because the user
> has visited a page that offers a provider.
>
>
>> Instead, it could do something like display an icon which can be clicked
>> to install the provider, e.g. like some browsers do for RSS feeds.
>>
>
> That's a possibility, but it might not work very well on mobile browsers
> with limited screen space.  For example, the Android web browser has only a
> minimal URL bar.
>

Yes, we'd need a different UI there.  I think this should be left up to the
user agent.  I only suggested the icon as one example.


>
>
>>
>> 3) Given that (1) encourages sites to expose providers of transient
>> resources while they are displayed, I think that they may want to be able to
>> prohibit installation of these providers.  Otherwise, if the user installs
>> them, they will just become broken links in the provider list, causing
>> confusion.  We didn't make any decision on this point.  What do you think?
>>
>
> Can you give some examples of transient providers?  None of the use cases
> in my list (in my notes at http://plash.beasts.org/wiki/WebPowerbox) are
> transient, such that you would not want to register them with the provider
> list.
>

This may be contrived...

Imagine a web app which can be used to generate sound waves.  You enter
parameters such as frequency, volume, shape, and phase of multiple waves,
which are then combined together.  Maybe you can even mix in some other
audio input resources from other sites.  Once you have this set up, you then
want to use this as an audio input resource in some other app.

This site does not want to save your sound stream and serve it forever.  It
just wants to function while you have the site open, and will discard
everything when you leave.  So, installing the provider would only leave you
with a broken link in your provider list, which is no good.


> I see the provider list as being very similar to a bookmarks list, so the
> same issues should apply there.  I don't know of any way for a page to say
> that its URL is transient and so should not be bookmarked.  (However, I
> wouldn't be surprised if there is a <meta> tag for this that no-one uses.)
>

On the web today, transient information usually only appears in two
contexts:
- POST responses.
- AJAX pages that have been manipulated by the user.

Neither of these can be bookmarked, since both involve state that is not
captured in a URL.  So, it's not really necessary for pages to mark
themselves unbookmarkable.

But providers *must* capture their state in a URL in order to grant their
resource, at least under the current spec.  So there needs to be some
explicit way to say "This URL will go away soon; please don't save it.".


>
>
>> 4) In the same discussion, but orthogonal to the above points, I suggested
>> that a provider should be able to specify the set/pattern of MIME types and
>> classes that it is able to serve.  The powerbox would then avoid presenting
>> providers which it knows cannot satisfy a particular request.
>>  Course-grained providers (e.g. "Google" or "Yahoo") would not use this --
>> once installed, they would be listed for *all* requests.  But, fine-grained
>> providers with narrow services would be able to use it.  Since it is
>> specifically when many fine-grained providers are installed that the user
>> would most need such filtering to take effect, this seems to fit together
>> nicely.
>>
>
> Yes, I have been assuming that providers would be able to declare the
> resource types they provide, and the powerbox dialog would display a list of
> providers that is filtered by resource type.
>

Well, the current spec does not define any mechanism for that, and Tyler's
intent was not to provide any.


> I have also been assuming that providers would be "fine-grained", in the
> sense that a provider would not offer wildly incompatible types of resource.
>

Tyler has a different vision.  He imagines that providers would be entities
like "Google" or "Yahoo".  Choosing "Google" would then direct you to
Google's site, where it would then help you choose a particular resource for
your request.  For such course-grained providers, it doesn't make sense for
the Powerbox to try to determine whether or not the provider can provide the
desired resource type -- even if Google provided a list of all types it
offers, this list would probably change on a regular basis.

I think that we need to think about both course-grained and fine-grained
providers.  Fine-grained providers explicitly list the types that they
offer, course-grained providers provide everything.  The user is likely to
have a small number of course-grained providers and a larger number of
fine-grained ones, so it's particularly important to filter the latter list.
 Luckily that's exactly what we can do.


> If the Powerbox is going to provide filtering by resource type, I think
> there are two issues we need to deal with:
>
> 1) Intersection matching:  Some kinds of resource might not yet have a
> single accepted standard interface, so some providers will want to offer
> multiple resource type names, e.g. "postscript-printer" and "pdf-printer".
> Similarly, a customer web app that can handle either of two resource types
> will want to list both type names in its request.  The Powerbox dialog
> should list a provider if there is an intersection between the requested and
> provided resource types.
>
> 2) Subtype matching:  Some resource types are subtypes of others.  For
> example, "image file" and "audio file" are both subtypes of "file".  If an
> image gallery web app requests an image file, the Powerbox should list both
> a take-a-picture camera provider and a local file chooser, but not a sound
> recorder.
>
> Ideally the Powerbox's filtering rules should produce the following
> outcomes:
>
>   Requested  || Powerbox displays:
>   type       || Sound recorder | Camera | Local file chooser
>   -----------||----------------|--------|-------------------
>   Audio file || yes            | no     | yes
>   Image file || no             | yes    | yes
>   Any file   || yes            | yes    | yes
>
> We don't want the Powerbox to have a hard-coded list of subtype
> relationships (e.g. that "image file" is a subtype of "file") and we don't
> want the local file chooser to have to list all the file types it could
> possibly provide ("image file", "audio file", etc.).
>
> I think the way to handle this is to encode subtype relationships into type
> names.  For example:
>  * Local file chooser provides "file/*"
>  * Sound recorder provides "file/audio"
>  * Camera provides "file/image"
> So "file/*" would match "file/image" and vice versa, but "file/image" would
> not match "file/audio".  This satisfies the truth table above.
>

This all sounds very interesting, but it's also getting uncomfortably
complicated for a standard.  And how does this extend to specific
interfaces?  What happens when we replace "file" with "implements the
com.example.File interface"?  Audio files don't implement a different
interface from regular files, unless you add a decoder adapter on top.

It seems like my music player would ask for "An implementation of
com.example.AudioOutput OR an implementation of com.example.File with MIME
type 'audio/*'".  How is this expressed?  And how does a provider satisfy
it?