Confirmed users
920
edits
Plugins:PluginDirectory/HowPluginDetectionWorks: Difference between revisions
Plugins:PluginDirectory/HowPluginDetectionWorks (view source)
Revision as of 14:57, 19 February 2010
, 19 February 2010→Version is not directly exposed
LesOrchard (talk | contribs) |
LesOrchard (talk | contribs) |
||
| (16 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
Building a service to help | Building a service to help identify plugins in need of upgrades is complicated. In a nutshell, the process consists of: | ||
* browser identification; | |||
* a local client plugin scan; | |||
* requests to a plugin directory search service; | |||
* and a local comparison of versions. | |||
This page seeks to provide details on how each of these steps work, as well as identifying shortcomings and oddities along the way. | |||
__TOC__ | __TOC__ | ||
| Line 21: | Line 28: | ||
Most browsers expose data on installed plugins to client-side JavaScript via a | Most browsers expose data on installed plugins to client-side JavaScript via a | ||
property named <code>navigator.plugins</code>. (Microsoft Internet Explorer is | property named <code>navigator.plugins</code>. (Microsoft Internet Explorer is | ||
an exception to this rule, but more on that later.) | an exception to this rule, [[Plugins:PluginDirectory/HowPluginDetectionWorks#The_Internet_Explorer_problem|but more on that later]].) | ||
=== navigator.plugins === | === navigator.plugins === | ||
The <code>navigator.plugins</code> property may be used as a list, with each | [https://developer.mozilla.org/En/DOM/Window.navigator.plugins The <code>navigator.plugins</code> property] may be used as a list, with each | ||
element in the list representing an installed plugin. Each of these elements | element in the list representing an installed plugin. Each of these elements | ||
generally exposes the following properties, each assigned by the plugin author | generally exposes the following properties, each assigned by the plugin author | ||
| Line 39: | Line 46: | ||
=== No reliable GUIDs or UUIDs === | === No reliable GUIDs or UUIDs === | ||
Across all plugins, there is no single reliable unique identifier - such as a GUID or UUID. | |||
This means that we'll need to use a combination of all of the above properties | This means that we'll need to use a combination of all of the above properties | ||
| Line 54: | Line 61: | ||
<code>navigator.plugins</code>. | <code>navigator.plugins</code>. | ||
Luckily, most plugins include some expression of a version in the name or | |||
description. But, this version does not always exactly match the | description. But, this version does not always exactly match the | ||
'''fully qualified version number''' of the plugin. Thus, there can be some | '''fully qualified version number''' of the plugin. Thus, there can be some | ||
| Line 61: | Line 68: | ||
For example, use the '''Tools > Add-ons''' menu in Firefox to open the Add-ons dialog | For example, use the '''Tools > Add-ons''' menu in Firefox to open the Add-ons dialog | ||
and view the Plugins tab. If you have "Shockwave for Director" installed, you may see | and view the Plugins tab. If you have "Shockwave for Director" installed, you may see | ||
it reported as version 11.5.6.606. However, this version is not usually available via | it reported as version 11.5.6.606. | ||
However, this version is not usually available via | |||
<code>navigator.plugins</code>. Instead, client-side detection code has to | <code>navigator.plugins</code>. Instead, client-side detection code has to | ||
inspect the description | inspect the description. [https://bug546727.bugzilla.mozilla.org/attachment.cgi?id=427718 On Windows, this reads "''Adobe Shockwave for Director Netscape plug-in, version 11.5''".] We can extract the version "''11.5''" from that text. | ||
Now, suppose that there were two releases of Shockwave for Director - say, versions 11.5.6.606 and | |||
11.5.7.235. | 11.5.7.235. If they both list "11.5" as the version in the | ||
description. Since client-side code can't see the real '''fully qualified version number''' | description, we're stuck. Since client-side code can't see the real '''fully qualified version number''' | ||
for either plugin, it can't tell a difference between the two. And, if it can't | for either plugin, it can't tell a difference between the two. And, if it can't | ||
tell a difference, then there's no way to decide whether an upgrade is advisable. | tell a difference, then there's no way to decide whether an upgrade is advisable. | ||
| Line 73: | Line 82: | ||
And, what's worse: Some plugins don't include a version number at all, neither in the the name nor description. (eg. Adobe Acrobat Reader has often presented this difficulty.) In this case, there's not much we can do besides shrug | And, what's worse: Some plugins don't include a version number at all, neither in the the name nor description. (eg. Adobe Acrobat Reader has often presented this difficulty.) In this case, there's not much we can do besides shrug | ||
and report the version as undetectable. | and report the version as undetectable. | ||
Our technique of last resort is to investigate custom hacks per-plugin to dig up version-related details. This tends to involve things like embedding a sample instance of the plugin and probing it for capabilities and information. But, this doesn't always work and can be very inefficient when it does. And, in the case of plugins with known vulnerabilities, this can expose the user to the very crashes and security problems that the plugin detection is meant to warn about. | |||
On the bright side, Firefox 3.6 and above ''does'' offer a version property in | On the bright side, Firefox 3.6 and above ''does'' offer a version property in | ||
| Line 81: | Line 92: | ||
('''Note:''' As of this writing, [https://www.mozilla.com/en-US/plugincheck/ the Plugin Check page] has not yet been revised to take advantage of the new version property in Firefox 3.6. So, the limitations described above still apply.) | ('''Note:''' As of this writing, [https://www.mozilla.com/en-US/plugincheck/ the Plugin Check page] has not yet been revised to take advantage of the new version property in Firefox 3.6. So, the limitations described above still apply.) | ||
==== The Internet Explorer problem ==== | |||
If you're using Microsoft Internet Explorer, none of the above applies. | |||
On IE, the <code>navigator.plugins</code> property is empty, and no plugin information is exposed. Thus, the only technique left available is to [http://developer.apple.com/internet/webcontent/detectplugins.html attempt to embed sample instances of known popular plugins and probe them for info/capabilities]. An error in embedding a plugin tells us it's not installed, but there's no way to get a full list of what ''is'' installed. | |||
Since this approach to plugin detection is so radically different than what works on most other browsers, we've been slow to work on support for IE. | |||
== Server-side plugin search == | == Server-side plugin search == | ||