264254 - move plugin finder logic to the client

Status: RESOLVED DUPLICATE of bug 836420

(Toolkit Graveyard :: Plugin Finder Service, defect)

Description

[Myk Melez [:myk] [@mykmelez]]

Currently, the code that determines which plugins are available lives in complex
conditionals in PluginFinderService.php on the server side.  Plugin data is
hardcoded into the file.  Nevertheless, the actual logic seems the same for all
plugins: we determine which plugin(s) support the submitted content type, verify
they're available for the user's platform, and then install the plugin
automatically and/or redirect the user to a manual installation URL depending on
which variants the plugin supports.

It would be better to publish an RDF file listing all available plugins and the
content types, platforms, and installation methods they support; have clients
periodically poll the server for updates to the file; and then determine which
plugins are available for a given content type on the client side rather than
the server side.

Doing this would give the user a better experience.  We currently tell the user
to "Install Missing Plugins" and "click here to download plugin" when they load
a page with unknown embedded objects, even if no plugins are available for those
objects.  We could (and should, currently) be sanguine, saying only "click here
to search for plugin" to avoid making promises we can't keep, but that still
makes users take the extra step of manually checking to see if a plugin is
available, and it introduces unnecessary uncertainty into the interface, since
we *do* know whether plugins are available for those objects, just not at the
right time and place currently.

Moving the logic server-side has the beneficial side-effect of reducing server
load significantly, since the server only has to serve a static file, and it
makes it easier to maintain a page listing available plugins, since we can
generate the page programmatically from the data in the file.  It's also similar
to how we check for software updates, and we can reuse some of the logic and
design in that component, if not its code.  We might optionally want to generate
platform-specific files to reduce the amount of irrelevant data being
transferred between server and client if it has any significant effect on
performance.

Comment 1

[Johnny Stenback (:jst)]

I'm not so sure I see the benefits here, but I do think there's value in having
a notification system for updates to the avaliable plugins, or the installed
plugins, rather. But that can be solved w/o moving the logic into the client if
the client just passes the server a list of the installed plugins.

I see more benefits to having much of this logic on the server than I do in
having it in the client.

Comment 2

[Doron Rosenberg (IBM)]

We would still need to poll the server for new updates when the user clicks on
the missing plugins button.  We would poll the server for a newer file, load the
whole file (potentially pretty large, unless we can just pull the new changes,
but that would require server side logic for versioning, etc), parse it and then
only figure things out.  

Granted we could do that in case the mimetype is not in the local cached rdf
file, but that has possible security issues - lets say macromedia.com gets
hacked, and we change the server side to point to a new domain - since we have
flash cached, we would redirect to the hacked site if we don't update the list
even if we know the mimetype (though how farfetched the example is :).  There is
also the issue of malicious software modifying the file, but I doubt we care
then, since the system is compromised anyways.  Client side rdf also opens the
doors to evil firefox distributions linking to evil xpis.  

If update gets hacked, well, we would still download the new hacked rdf list, so
none of the solutions are more secure in that relation.

I was actually thinking of something similar, mainly for enterprise deployments,
where say IBM would want some internal plugins listed but not on update - having
a local plugins cache would solve that problem.  It also solves the problem of
having to poll the server for plugin information which you mention, which is
indeed one of the problems the current model has.

A local plugin datasource is something I want to do for the above reason, but
there are probably some security concerns (dveditz?).  It is probably
technically feasible, and maybe we can just have a local list of the main
plugins outthere and keep the lesser deployed ones on the server.

But its up to the foundation to really decide, and I am busy with XForms for the
 near future (though this is beyond 1.0).

Comment 3

[Myk Melez [:myk] [@mykmelez]]

Johnny wrote:

>I see more benefits to having much of this logic on the server than I do in
>having it in the client.

What benefits are those?


Doron wrote:

>We would still need to poll the server for new updates when the user clicks on
>the missing plugins button.  We would poll the server for a newer file, load 
>the whole file (potentially pretty large

True, but there are only a handful of popular plugins, so this won't happen very
often.


>Granted we could do that in case the mimetype is not in the local cached rdf
>file, but that has possible security issues - lets say macromedia.com gets
>hacked, and we change the server side to point to a new domain - since we have
>flash cached, we would redirect to the hacked site if we don't update the list
>even if we know the mimetype (though how farfetched the example is :).

As long as we poll the server regularly for updates to the file (just as we
currently do for the "updates to Firefox" file) the time period during which a
user could potentially be vulnerable is small.  And this raises another point,
which is that we should be checking for security updates to installed plugins
just as we check for such updates to the browser and extensions (if we aren't
doing so already).

>There is also the issue of malicious software modifying the file, but I doubt
>we care then, since the system is compromised anyways.

There's not much we can do to protect ourselves once the system as a whole is
compromised.  Even with our current approach, malicious software could redirect
users to a different plugin finder service.

>Client side rdf also opens the doors to evil firefox distributions linking
>to evil xpis.  

How is that different from evil Firefox distributions linking to evil plugin
finder services linking to evil XPIs?

Comment 4

[Johnny Stenback (:jst)]

(In reply to comment #3)
> >I see more benefits to having much of this logic on the server than I do in
> >having it in the client.
> 
> What benefits are those?

The ability to make changes to the service on the server and have the clients
benefit from it directly, and the ability to log what plugins people are running
into most and improve our service based on those logs. That IMO outwheighs any
benefits we'd get from moving this logic to the client.

And so far server load has hardly been an issue, and theoretically it server
load should drop as the majority of our users get their plugins and hardly ever
hit this service again...

[...]
> As long as we poll the server regularly for updates to the file (just as we
> currently do for the "updates to Firefox" file) the time period during which a
> user could potentially be vulnerable is small.  And this raises another point,
> which is that we should be checking for security updates to installed plugins
> just as we check for such updates to the browser and extensions (if we aren't
> doing so already).

None of this can be done any more efficiently if more of this logic is on the
client. Currently we don't do anything to check for updates to the plugins etc,
that's something that we *do* need to build into the client, probably as part of
the extension update checking, or as a separete, though similar system. But
whether the logic for selecting plugins etc lives on the client or server
doesn't change any of this, AFAICT. Something to do for an upcoming Firefox
version...

IMO reducing server load is the only real benefit to move this logic away from
the server, but so far that's hardly a problem AFAICT.

Comment 5

[Myk Melez [:myk] [@mykmelez]]

>>>I see more benefits to having much of this logic on the server than I do in
>>>having it in the client.
>> 
>> What benefits are those?
> 
>The ability to make changes to the service on the server and have the clients
>benefit from it directly, and the ability to log what plugins people are
>running into most and improve our service based on those logs.

The vast majority of server-side changes would still propagate to the client
under the logic-on-client model, and we can just as easily log plugin requests
by redirecting clients through the server to their plugins for known content
types (still much less intense than dynamic page compilation and processing) and
including content type in the request parameters when repulling the static file
for unknown content types.


> And so far server load has hardly been an issue

The service runs on iguana, which has experienced load-related slowness and
outages.  Server load isn't an insignificant consideration under our current
operating constraints.


>But whether the logic for selecting plugins etc lives on the client or server
>doesn't change any of this, AFAICT.

Agreed.  This is a separate bug, although its fix may touch some of the same code.

> IMO reducing server load is the only real benefit to move this logic away from
> the server, but so far that's hardly a problem AFAICT.

The other benefit is not misleading our users with admonishments to download
code we can't provide or aren't sure about.  But then, that'll be rare if we
know about all popular plugins, so perhaps it doesn't really matter.

Comment 6

[Doron Rosenberg (IBM)]

I still think if we shipped with major plugins in the rdf file, server load
would go down and we still can keep the server for "lesser" plugins add plugin
updates.

This is a post 1.0 thing, and I think it falls under enterprise stuff so I could
work on it :)

Comment 7

[Doron Rosenberg (IBM)]

Tentitivly targetting 1.1 with:

This would require a pfscache.rdf, which would store plugin finder service
servers and plugins (which are linked to an server).  So an theoretical IBM
internal Firefox would be able to fetch IBM's JVM from an internal server and go
to update for flash.

Whenever we look for a plugin not in the cache, we go to the main server
(determined by the pref we already have), get the info and add it to the cache
as well.

Comment 8

[Doron Rosenberg (IBM)]

clearing target.  After thinking and talking to foundation people, the benefit
for this is minimal, as the traffic problems are the hosted plugins, not the
finder service.

Enterprise wise it makes sense to just have a proxy PFS that handles whatever
the enterprise needs and hands off to the foundation server the rest.

Comment 9

[alanjstr]

What we need is to put plugins on UMO.  I'd like to see PFS integrated with the
user interface there. 

Comment 10

[Doron Rosenberg (IBM)]

Please bring update out of beta first.