Closed Bug 956905 Opened 10 years ago Closed 10 years ago

Publish JSON list of all plugins for use on /plugincheck

Categories

(Websites :: plugins.mozilla.org, defect)

Product:
Websites
Component:
plugins.mozilla.org
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jpetto, Assigned: espressive)

References

Details

Attachments

(6 files)

Screen Shot 2014-03-05 at 08.13.07.png
55.35 KB, image/png
Details
Screen Shot 2014-03-05 at 10.39.42.png
67.33 KB, image/png
Details
Screen Shot 2014-03-05 at 10.41.20.png
50.34 KB, image/png
Details
Screen Shot 2014-03-10 at 18.24.13.png
369.83 KB, image/png
Details
Adobe Flash versions in 2013
46.94 KB, application/pdf
Details
publish_json_list.diff
8.38 KB, patch
Details | Diff | Splinter Review 
The plugin check page (http://www.mozilla.org/en-US/plugincheck/) is currently broken in Aurora 28 due to navigator.plugins[] no longer exposing all installed plugins.

The fix will require an update to the client side JavaScript (bug 938885), which requires a published list of all available plugins to enumerate over.

From cpeterson's comment in bug #938885 (https://bugzilla.mozilla.org/show_bug.cgi?id=938885#c22):

> The server needs to publish the list of known plugins' plugin name, display
> name, version numbers, URL to plugin install page, and possibly a plugin
> MIME types. The list could be JSON, XML, CSV or whatever, but JSON would be
> a JS-friendly good choice. A human-readable list is available here:
> https://plugins.mozilla.org/en-us
> 
> Some plugin names include a version number that changes with every release
> (e.g. "QuickTime Plug-in 7.7.3"), which the client can't use to query
> navigator.plugins["QuickTime Plug-in 7.7.3"]. If the user might have an old
> "QuickTime Plug-in 6.0" installed, the plugin won't be found even though it
> needs to be updated. For those plugins, the published list should include a
> MIME type that is unique to that plugin so the client JS can find the plugin
> using navigator.mimeTypes["video/quicktime"].enabledPlugin which is the same
> Plugin object returned by navigator.plugins["QuickTime Plug-in 7.7.3"].
> 
> Example plugin info for a server list:
> 
> Plugin Name: "Shockwave Flash" i.e. navigator.plugins["Shockwave Flash"].name
> Display Name: "Adobe Flash Player" i.e. the name displayed to the user on
> the Plugin Check page
> Version Number: "11.9.900.170" i.e. navigator.plugins["Shockwave
> Flash"].version
> MIME Type: "application/x-shockwave-flash" (though MIME Type is not really
> needed for this plugin because the Plugin Name "Shockwave Flash" is the same
> across all version.)
> Installer URL: <some adobe.com URL>
> 
> Plugin Name: "QuickTime Plug-in 7.7.3" i.e. navigator.plugins["QuickTime
> Plug-in 7.7.3"].name
> Display Name: "Apple QuickTime" i.e. the name displayed to the user on the
> Plugin Check page
> Version Number: "7.7.3" i.e. navigator.plugins["QuickTime Plug-in
> 7.7.3"].version
> MIME Type: "video/quicktime"
> Installer URL: <some apple.com URL>

The above bug has additional details if needed.
Blocks: 938885
schalk could you take a look? thanks!
Flags: needinfo?(schalk.neethling.bugs)
(In reply to Carsten Book [:Tomcat] from comment #1)
> schalk could you take a look? thanks!

Hey Carsten,

I can surely handle the JS side however, I do have a question in this regard. Why is the completion timeline for this work? The reason as I ask is that this seems to be an ideal time to rewrite just about everything with regards to the JS side of plugin check but, this will obviously take some time as well which I am not sure we have.

Also, in terms of the server side changes to expose the JSON list, is there someone assigned to that? If not, is this still one of the bits of code that is written in PHP or has this been migrated over to Python/Django?

Thanks!
Flags: needinfo?(schalk.neethling.bugs) → needinfo?(cbook)
Schalk: on the browser side, our current plan is to release the navigator.plugins change in Firefox 29 (which hits the Release channel on April 29). The browser change is currently in Aurora 28, but #ifdef'd off for Beta and Release. If you need more time, please just say so and we can hold this change in Beta for an extra release.
Schalk, I think it's better to make the minimal - or reasonable - change needed for this bug here, and make the big rewrite in a separate bug. This ensures timely deploy of this change, not holding up Firefox, and the rewrite can be done without time pressure to get it done nicely.
This is PHP (Kohana). If you're confident looking at it Schalk, be my guest. Other option is for me to do it.
(In reply to Laura Thomson :laura from comment #5)
> This is PHP (Kohana). If you're confident looking at it Schalk, be my guest.
> Other option is for me to do it.

Can you point me to where the code for this lives?
So, I looked over some of the code of the current plugins.m.o and it seems this function almost provides us with everything we need and, can most likely be extended to return everything we need. Am I correct in my assumption here?

http://viewvc.svn.mozilla.org/vc/projects/plugindir/trunk/application/controllers/plugins.php?view=markup

 /**
42 	* Produce a JSON index of all plugins with release counts.
43 	*/
44 	function index_json()
45 	{
46 	$this->auto_render = FALSE;
47 	$name_counts = ORM::factory('plugin')->find_release_counts();
48 	$out = array();
49 	foreach ($name_counts as $count) {
50 	$out[] = array(
51 	'pfs_id' => $count->pfs_id,
52 	'name' => $count->name,
53 	'release_count' => $count->count,
54 	'description' => $count->description,
55 	'modified' => $count->modified,
56 	'href' => url::site('plugins/detail/' .
57 	$count->pfs_id . '.json')
58 	);
59 	}
60 	return json::render($out, $this->input->get('callback'));
61 	}
Flags: needinfo?(laura)
Flags: needinfo?(cpeterson)
Flags: needinfo?(cbook)
If that is the case, then this is the end point: https://plugins.mozilla.org/en-us/plugins/index_json

which will return a big ol array of these:

{
  "pfs_id":"telestream-flip4mac",
  "name":"Windows Media Components for QuickTime",
  "release_count":"5",
  "description":"The Flip4Mac WMV Plugin allows you to view Windows Media content using QuickTime.",
  "modified":"2012-05-30 08:40:19",
  "href":"https:\/\/plugins.mozilla.org\/en-us\/plugins\/detail\/telestream-flip4mac.json"
}

The above contains very little of what we need but, it contains the detail URL that returns a bunch of info, for example: https://plugins.mozilla.org/en-us/plugins/detail/telestream-flip4mac.json

{
    "meta": {
        "pfs_id": "telestream-flip4mac",
        "name": "Windows Media Components for QuickTime",
        "description": "The Flip4Mac WMV Plugin allows you to view Windows Media content using QuickTime.",
        "vendor": "Telestream",
        "url": "http://windows.microsoft.com/en-US/windows/products/windows-media-player/wmcomponents",
        "modified": "2012-05-30 08:40:19",
        "created": "2010-03-03 17:30:48"
    },
    "aliases": {
        "literal": [
            "Flip4Mac Windows Media Plugin",
            "Windows Media Components for QuickTime"
        ],
        "regex": [
            "Flip4Mac Windows Media Plugin.*"
        ]
    },
    "mimes": [
        "application/x-mplayer2"
    ],
    "releases": [
        {
            "status": "outdated",
            "version": "2.2.1",
            "detected_version": "2.2.1",
            "detection_type": "original",
            "os_name": "*",
            "platform": {
                "app_id": "*",
                "app_release": "*",
                "app_version": "*",
                "locale": "*"
            }
        }.....

Soooo, I am thinking. We need a new function that combines the results of index_json with details i.e.

Get all plugins using index_json
Iterate over those and get each plugin's details
Build a new JSON object that contains all the information we need
Return that at a new end point, perhaps, plugins/list_plugins
While this is all being figured out, can I propose that I start on the client side bits working against a mock such as this?

[
    {
        "pfs_id": "telestream-flip4mac",
        "plugin_name": "Windows Media Components for QuickTime",
        "display_name": "Windows Media Components for QuickTime",
        "version_number": "11.9.900.170",
        "description": "The Flip4Mac WMV Plugin allows you to view Windows Media content using QuickTime.",
        "mime_type": "application/x-shockwave-flash",
        "url": "http://adobe.com/",
    },
    {
        "pfs_id": "shockwave-flash",
        "plugin_name": "Shockwave Flash",
        "display_name": "Adobe Flash Player",
        "version_number": "11.9.900.170",
        "description": "Shockwave Flash 12.0 r0",
        "mime_type": "application/x-shockwave-flash",
        "url": "http://adobe.com/",
        "advisory_url": "http://adobe.com/why-u-should-not-use-version"
    }
]

The advisory_url added for the second plugin is related to https://bugzilla.mozilla.org/show_bug.cgi?id=882309. I am not sure if we carry this information and, whether it is relevant or, should be retrieved from somewhere else.
That looks solid. My only concern is that I'm not sure what the existing function is used for - if we need to modify it I don't want to regress something else.
Flags: needinfo?(laura)
(In reply to Schalk Neethling [:espressive] from comment #9)
> If that is the case, then this is the end point:
> https://plugins.mozilla.org/en-us/plugins/index_json

You may not notice this when you're an employee, but from the Internet, this gives an LDAP login prompt.
(In reply to Laura Thomson :laura from comment #11)
> That looks solid. My only concern is that I'm not sure what the existing
> function is used for - if we need to modify it I don't want to regress
> something else.

I agree and will not mangle the existing methods and instead introduce a new one for our specific needs.
Another question I have is whether I can run this locally connecting to a remote DB or, will I have to run everything locally?

In the second case, which DB does this use and, who would I need to talk to, to get a drop of the DB? Thanks!
(In reply to Ben Bucksch (:BenB) from comment #12)
> (In reply to Schalk Neethling [:espressive] from comment #9)
> > If that is the case, then this is the end point:
> > https://plugins.mozilla.org/en-us/plugins/index_json
> 
> You may not notice this when you're an employee, but from the Internet, this
> gives an LDAP login prompt.

Yes, plugins.m.o is behind LDAP but, I believe some of the end points are not, such as the one currently accessed by plugincheck.
The plugin info in comment 10 looks like everything the front-end will need to check plugins. If you want to minimize the response size, you could omit the "pfs_id" info because the front-end does not need it. :)
Flags: needinfo?(cpeterson)
FAO those who maintain the Server side.

Observation: I noticed the following from Schalk Neethling [:espressive]'s post in Comment 10:
https://bugzilla.mozilla.org/show_bug.cgi?id=956905#c10

>    {
>        "pfs_id": "shockwave-flash",
>        "plugin_name": "Shockwave Flash",
>        "display_name": "Adobe Flash Player",
>        "version_number": "11.9.900.170",
>        "description": "Shockwave Flash 12.0 r0",
>        "mime_type": "application/x-shockwave-flash",
>        "url": "http://adobe.com/",
>        "advisory_url": "http://adobe.com/why-u-should-not-use-version"
>    }

A. the Advisory URL is no longer working:
>        "advisory_url": "http://adobe.com/why-u-should-not-use-version"
This URL is now 404.

B. I use the following URL

http://www.adobe.com/software/flash/about/

to check if the 'installed Flash' (in various browsers including IE) is the best version.

From this, on 21 January 2014, I see that
"Firefox, Mozilla, Netscape, Opera (and other plugin-based browsers)"
on WINDOWS
should now use "12.0.0.43" (not "11.9.900.170" which is in quoted Comment).

You will see Flash, for Firefox, on Macintosh (12.0.0.38) and Linux (11.2.202.335) use other versions.

DJ-Leith
(In reply to Schalk Neethling [:espressive] from comment #14)
> Another question I have is whether I can run this locally connecting to a
> remote DB or, will I have to run everything locally?
> 
> In the second case, which DB does this use and, who would I need to talk to,
> to get a drop of the DB? Thanks!

You can get a database dump from Sheeri.
Assignee: nobody → schalk.neethling.bugs
I have shared both the pfs2_mozilla_org and plugins_mozilla_org SQL exports from yesterdays backups on Google drive with :espressive. They are just MySQL exports, and you can import them using the "mysql" commandline program as per the bottom of https://dev.mysql.com/doc/refman/5.6/en/mysql.html or you can use a GUI like MySQL Workbench. (note that the files are compressed, and need to be uncompressed before importing).
(In reply to Sheeri Cabral [:sheeri] from comment #19)
> I have shared both the pfs2_mozilla_org and plugins_mozilla_org SQL exports
> from yesterdays backups on Google drive with :espressive. They are just
> MySQL exports, and you can import them using the "mysql" commandline program
> as per the bottom of https://dev.mysql.com/doc/refman/5.6/en/mysql.html or
> you can use a GUI like MySQL Workbench. (note that the files are compressed,
> and need to be uncompressed before importing).

Thanks a lot!
Looking at the properties mentioned in comment 1, I am thinking that we need more than just version number, as the latest, safe version number can be different depending on the OS so, we should probably have:

"versions": [
        {
            "os": "windows",
            "version": "12.0.0.43"
        },
        {
            "os": "mac",
            "version": "12.0.1.43"
        },
        {
            "os": "linux",
            "version": "11.0.0.43"
        }
    ]
One thing to note about the above though is, knowing which is the latest is also not trivial as, for example, Flash has a *bunch* of releases that are returned from the details call and the majority of those are marked as status=latest ;p
Reading comment 1 again now:

"The server needs to publish the list of known plugins' plugin name, display
> name, version numbers,...."

I am wondering if the intention was that we will include all released for a plugin and, if there is a vulnerability url for a specific release, we can include that as well.
All you need is the first safe version, and the errata for that version (which will show the vulnerability of all versions below it).
You can't get more data than we have in the database, so don't overengineer it.
(In reply to Ben Bucksch (:BenB) from comment #24)
> All you need is the first safe version, and the errata for that version
> (which will show the vulnerability of all versions below it).
> You can't get more data than we have in the database, so don't overengineer
> it.

Do we want to split this by OS though, as in comment 21? I know Linux does not always share the same version number as the rest.
Are there many bugs that are OS specific? I think not. If WhateverPlugin 2.4.5 on Windows is vulnerable and 2.4.6 fixes it, then Linux 2.4.5 is likely to be vulnerable, too - no matter whether there's a fix or not.
(In reply to Ben Bucksch (:BenB) from comment #26)
> Are there many bugs that are OS specific? I think not. If WhateverPlugin
> 2.4.5 on Windows is vulnerable and 2.4.6 fixes it, then Linux 2.4.5 is
> likely to be vulnerable, too - no matter whether there's a fix or not.

One thing I find really puzzling is that a release can be marked as latest, but also have a vulnerability url. I can imagine that there are times when there has been no new release to fix the vulnerability but, there are a bunch of those.

Should we perhaps get the version that is marked as latest but does not have a vulnerability url? Even with those though, there are duplicates. I wonder whether the data is just not as clean as it needs to be.

To my mind there should be a status such as latest_safe or have latest but, have anything other than the latest be marked as outdated or, vulnerable, if there is a vulnerability url.

Here is what you would get for Flash:
http://sneethling.pastebin.mozilla.org/4082511
> really puzzling is that a release can be marked as latest, but also have a vulnerability url.

Of course. When a bug is found and the company didn't fix it yet.

I don't know what the DB has, but we need at least 2 versions: First safe version (or last vulnerable version), and a recommended version. "first safe" / "last vulnerable" means if the user has anything below, he must act. "recommended" version is the one that the user should preferably install when he does act.

More important than OS differences will be branches: E.g. Java has a version 6, 7 and 8 our there. Each of them get security fixes. E.g. 6.0.55 is vulnerable and 6.0.56 has the fix, but 7.1.43 is also vulnerable to the same bug, and 7.1.44 has the same fix.

You have the server source code, right? Can you look how they implement this, and based on that, make a proposal for a protocol for the plugin information needed by the algo?
(In reply to Ben Bucksch (:BenB) from comment #28)
> > really puzzling is that a release can be marked as latest, but also have a vulnerability url.
> 
> Of course. When a bug is found and the company didn't fix it yet.
> 
> You have the server source code, right? Can you look how they implement
> this, and based on that, make a proposal for a protocol for the plugin
> information needed by the algo?

Yes, I have the site up and running locally, so, let me have a look.
This is the current status of what is being produced for a plugin on the server side:

{
    "plugin_name": "adobe-flash-player",
    "display_name": "Adobe Flash Player",
    "version": [
        {
            "status": "latest",
            "version": "12.0.0.43",
            "detected_version": "12.0.0.43",
            "detection_type": "*",
            "os_name": "win",
            "platform": {
                "app_id": "*",
                "app_release": "*",
                "app_version": "*",
                "locale": "*"
            }
        },
        {
            "status": "vulnerable",
            "vulnerability_description": "vendor information",
            "vulnerability_url": "http://helpx.adobe.com/security/products/flash-player/apsb14-02.html",
            "version": "11.9.900.170",
            "detected_version": "11.9.900.170",
            "detection_type": "*",
            "os_name": "*",
            "platform": {
                "app_id": "*",
                "app_release": "*",
                "app_version": "*",
                "locale": "*"
            }
        }
    ],
    "mime-types": [
        "application/x-shockwave-flash",
        "application/futuresplash"
    ],
    "url": "http://www.adobe.com/go/getflashplayer"
}

I know for Java we have to jump through a couple of hoops to have the latest and last vulnerable for each of the major version out in the wild but, ignoring that for the moment, does the above look like what we are after?
Flags: needinfo?(laura)
Flags: needinfo?(cpeterson)
Schalk: yes, this plugin metadata looks like everything the client side will need! :)
Flags: needinfo?(cpeterson)
(In reply to Chris Peterson (:cpeterson) from comment #31)
> Schalk: yes, this plugin metadata looks like everything the client side will
> need! :)

Great! Now just to jump through the Java loops and we can move on to the client side.
Flags: needinfo?(laura)
(See post by Ben Bucksch (:BenB) in comment # 28)

> ... Java has a version 6, 7 and 8 our there. Each of them get security fixes.
> E.g. 6.0.55 is vulnerable and 6.0.56 has the fix, but 7.1.43 is also vulnerable to the same bug,
> and 7.1.44 has the same fix.

Can you treat each 'Java family' as a separate Plugin?
So, track 'Java 6' and 'Java 7' and 'Java 8' separately.


(See post by Schalk Neethling [:espressive] in comment # 27) 
> Here is what you would get for Flash:
> http://sneethling.pastebin.mozilla.org/4082511

This is an excellent illustration of how many versions there have been of Flash.
If Internet Explorer is still in scope (I think it is) then you may have to
produce lists for each OS & browser: e.g. Windows & IE, Windows & Firefox, Mac & Firefox etc.

See also
"RFE an "About plugincheck" page, visible from plugincheck"
bug 965812
In 965812 I have asked 'what is the current scope for plugincheck'? and I have illustrated, near the end, a current 'false positive' with Flash in IE. 

DJ-Leith
> This is an excellent illustration of how many versions there have been of Flash.

Actually, we don't need all these. If version 5.3 is vulnerable, we can assume that 5.2 is vulnerable as well, unless we know otherwise.

Algo in client (proposal):
1. Take currently locally installed version
2. Find this version in the list
3. If not found, find the next higher version that is in the list.
   (e.g. if you have 5.2, and 4.5 and 5.4 are in the list, take 5.4.)
4. If that version is "latest", you're OK
5. If that version is "vulnerable", propose an upgrade.
I agree with :BenB that we do not need to list all of the versions for a plugin. At the moment I am returning two versions of a plugin. The latest releases and then the most recent marked as status=vulnerable.

For Java, I can treat each version as a separate plugin and the logic will basically be the same except, I would think that even the latest version of say Java 6 would be either marked as vulnerable or outdated so, for these I can most likely just grab the latest two, if there is even two (for example for Java 5 we only have one release in the DB). Does that work?

Then with regards to the OS, browser etc. separation, I thought we might very well need to do this but, I am a little uncertain what we have decided. Do we want to separate each plugin into OS, browser etc or, are we going to do as suggested in https://bugzilla.mozilla.org/show_bug.cgi?id=956905#c26 (which is basically what I am currently doing as mentioned above).
Schalk, for the algo above, the server could output versions only when the status changes:
1. Start with highest version, output that
2. Work downwards (second highest version etc.):
- If the status is the same as the last: skip
- If the status is different from the last: output
- If the major version (first component) is different from the last: output in any case
  (even if same as last)
Ben,

Seems like we are going to have to split this information by OS, at the least, because of scenarios such as these: http://sneethling.pastebin.mozilla.org/4146504 (see the last two releases)

Unless the above data is just wrong.
Flags: needinfo?(ben.bucksch)
(In reply to Ben Bucksch (:BenB) from comment #36)
> Schalk, for the algo above, the server could output versions only when the
> status changes:
> 1. Start with highest version, output that
> 2. Work downwards (second highest version etc.):
> - If the status is the same as the last: skip
> - If the status is different from the last: output
> - If the major version (first component) is different from the last: output
> in any case
>   (even if same as last)

This also does not always work out well as there are a couple of instances when one runs into this pattern:

1. latest
2. vulnerable
3. outdated
4. vulnerable
5. outdated
6. vulnerable

;)

Unless we break on the first vulnerable release or, break as soon as the new list has reach a depth of at least two releases. The first would possibly be the better of the two.
If I apply the algo mentioned in comment 38, we will look at the following for Java:

http://sneethling.pastebin.mozilla.org/4146524
> Seems like we are going to have to split this information by OS

You could make the content of the OS field a factor in whether you can "compress" (skip releases) or not.
Or you make separate lists when "OS" is not "*", but that would complicate the data format.
Flags: needinfo?(ben.bucksch)
(In reply to Ben Bucksch (:BenB) from comment #40)
> > Seems like we are going to have to split this information by OS
> 
> You could make the content of the OS field a factor in whether you can
> "compress" (skip releases) or not.
> Or you make separate lists when "OS" is not "*", but that would complicate
> the data format.

Agreed, I prefer the first suggestion.
Please re-read bug 965812 before the rest of this comment.

I have been a very happy user of the plugincheck service and I'm keen that it continues to work with Firefox 28+.
I'm adding comments in a spirit of constructive suggestions. I apologise for the length.

Next are four topics / points that I know I don't know the precise facts but which Schalk (and others) either know or can find out from their colleagues at Mozilla.

In my view, a clear understanding of these points will enable all of you, who are providing the service and working on this bug (and bug 938885), to enable the 'new plugincheck service'.

Until now, when checking a visiting Firefox browser, the site has 'discovered plugins' (by using enumeration).  These are then checked.

In the future, the 'new plugincheck service' will have to 'use the list of tracked plugins' (from the database) to 'drive the checking process'.  In bug 965812 I said:

> Instead of enumerating the 'visiting browser's plugins', the new 'plugincheck web site' will now
> 'go through the appropriate list (from the JSON)' of plugins, one by one, and see if it is installed
> and, if it is, if it is up to date.


The four points are:

1. Scope
> "Plugin Check for Everyone"
> by Johnathan Nightingale
> 11 May 2010
> http://blog.mozilla.org/security/2010/05/11/plugin-check-for-everyone/
>

Included in Johnathan Nightingale's post is:

" ... We believe that plugin safety is an issue for the web as a whole, so while our initial efforts focused on building a page that would work for Firefox users, the team has since expanded plugin check coverage to work with Safari 4, Chrome 4, and Opera 10.5. We have added support for Internet Explorer 7 and 8 for the most popular plugins, as well, but since IE requires specific code to be written for each plugin it will take us a little longer to get to full coverage. ..."

>
> Is this still the best scope? - has it widened (or narrowed) since May 2010?
> Which browsers are you able to assess at plugincheck?
> For example, is Opera in scope? See bug 875058
> Which Operating Systems are you supporting?

While I would like the plugincheck service to cover many browsers and many Operating Systems there may be limits to the scope.  The scope might have an ESSENTIAL part and a 'nice to have'.

For the purpose of discussion, in this comment, let us suppose that the scope of plugincheck is ONLY
Windows & IE (limited)
Windows & Firefox
Macintosh & Firefox
Linux & Firefox

If more browsers (or Operating Systems) are in the scope then bear that in mind as you consider the points below.


2. The Plugins that are tracked in the Database.

> ... human-readable list of the 'plugins that are tracked in the database', IIUC, available at:
> https://plugins.mozilla.org/en-us
> However, this requires a LDAP login (so I've not seen it).

As the 'new plugincheck service' is going to be 'driven by the list' one has to be clear which are in the scope to be tracked.  For each one (e.g. Flash) the database will need information for every [current and recently declared "vulnerable" ] version of that plugin, by browser and by OS.

There might be 12 or 60 or 120 plugins that are tracked: I don't know. Each will have to be assessed for each browser and OS.  Let us suppose that there are 60.  Using the example scope of 4 OS & browser combinations (above) the total current versions will be x4 (i.e. 240) and the 'penultimate version' / 'most recent, now vulnerable version' will also be x4 (another 240).


3. When a new version of a Plugin is released, how is the database updated?

To use a recent example.

On 14 January 2014 (which was also a 'Microsoft patch Tuesday') I used plugincheck and 'all was green' (i.e. "Up to Date").
However, I also consulted us-cert as a 'defence in depth', and Adobe had released a new version of Flash.
In recent months, Adobe have often done this to coincide with 'patch Tuesday'.

"Current Activity"
http://www.us-cert.gov/ncas/current-activity

The archive of this notice, about Flash, is at:

"Adobe Releases Security Updates for Adobe Flash Player"
Original release date: January 14, 2014
http://www.us-cert.gov/ncas/current-activity/2014/01/14/Adobe-Releases-Security-Updates-Adobe-Flash-Player

This then pointed to
Adobe Security Bulletin APSB14-02
http://helpx.adobe.com/security/products/flash-player/apsb14-02.html

Both sites, as well as the very helpful

http://www.adobe.com/software/flash/about/

were telling me to update Flash.

I did this on one PC late on 14 January 2014.
After I had done this all was 'still green' ("Up to Date").

At the time I assumed that I had 'seen the warnings' before you, at Mozilla, had had a chance to update the database.
I was a little puzzled that they were still green after the update (I was half expecting an Unknown).

As I'm in the UK I tend to do most of the patching on Wednesday (15-Jan-2014) and I aim to have it all completed by the end of the week.  I did notice that before and after (on 15 Jan) all was 'green' at plugincheck.

In an ideal world (and assuming the scope is)
Windows & IE (limited)
Windows & Firefox
Macintosh & Firefox
Linux & Firefox

Then, on 14 January 2014, four records would have been added to the database
Windows & IE, Flash 12.0.0.38
Windows & Firefox, Flash 12.0.0.43
Macintosh & Firefox, Flash 12.0.0.38
Linux & Firefox, Flash 11.2.202.335

These four plugins are all different files.  In this case there are three 'version identifiers'.
One can NOT assume that all 'plugin authors' will use the same 'version identifier' for all their
plugins across all the OSs that THEY are supporting.

ALSO, after adding new 'plugin record' one should search the Database find all previous versions of Flash and update ANY that are 
"status": "latest" to become
"status": "vulnerable" and add the 
"vulnerability_url": "http://helpx.adobe.com/security/products/flash-player/apsb14-02.html"

Was this done?
I don't think so.  In particular, I wonder if those who update the database
A. Add records for EACH plugin by Browser and OS.
B. THEN check that the 'previous version's record' is amended to show that it is now vulnerable.

The circumstantial evidence for my doubt includes:

A. My observations, posted on 21-Jan-2014, in Comment 17
Where I had noticed that the "version_number" (of Flash) did NOT match the description
>        "version_number": "11.9.900.170",
>        "description": "Shockwave Flash 12.0 r0",
and that "11.9.900.170" was no longer the 'best version to use' (it had been on 13-Jan-14).
This might explain my experience of observing a 'green' for 11.9.900.170 AND 12.0.0.43
(for Firefox on Windows on 14, 15 and 16 Jan 2014). 


B. (See post by Schalk Neethling [:espressive] in comment # 27) 
> Here is what you would get for Flash:
> http://sneethling.pastebin.mozilla.org/4082511
where there are MANY "status": "latest" versions of Flash.


C. (See post by DJ-Leith in bug 965812)
>
> Using Internet Explorer (on 30 January 2014) and
> http://www.mozilla.org/en-US/plugincheck/
> 
> I am told "... support for Internet Explorer is limited. ..." and that
>
> "Shockwave Flash 12.0.0.38" is "vulnerable"
> 
> However, 
> http://www.adobe.com/software/flash/about/
> confirms that "12.0.0.38" is the best version for IE.
> 
> The best version for Firefox (since 14 January 2014) has been "12.0.0.43".


As we all know, vulnerabilities are being discovered all the time!
Adobe released a new set of Flash plugins on 4 February 2014.

See

"Security updates available for Adobe Flash Player"
Release date: February 4, 2014
Vulnerability identifier: APSB14-04
Priority: See table below
CVE number: CVE-2014-0497
Platform: All Platforms
http://helpx.adobe.com/security/products/flash-player/apsb14-04.html

"... Adobe is aware of reports that an exploit for this vulnerability exists in the wild ..."

This page also has,
"... For users of Flash Player 11.7.700.260 and earlier versions for Windows and Macintosh, who cannot update to Flash Player 12.0.0.44, Adobe has made available the update Flash Player 11.7.700.261, which can be downloaded here. [URL] ...".  The link lead one to
http://helpx.adobe.com/flash-player/kb/archived-flash-player-versions.html
where there is a link to download the 11.7.700.261 version.

I'm pleased to add that within hours plugincheck was correctly identifying the previous versions as "vulnerable".
It also (on 4 February 2014) said that 12.0.0.44 was "Up to Date" in Firefox AND IE (on Windows).


4. Code
I've not looked at any code: I don't have the expertise to comment on code.

One way to think of the 'JSON list' is 'like a report'.
It is up to you to decide if 'one big list', which is 'sliced up by JS at the web site' into 'by OS & browser' is better than selecting at the database server 'by OS & browser'.

I imagine that when a 'user with a browser' comes to https://www.mozilla.org/en-US/plugincheck/
the Javascript will 'detect the OS & browser' and then use the 'appropriate list of tracked plugins' (from the database) to 'drive the checking process'. So, I expect that you will have to make changes to the Javascript on the web site too.

One could generate the JSON report(s) daily, every hour etc - your choice.

(See also Schalk Neethling [:espressive] in Comment 2)
> ... this seems to be an ideal time to rewrite just about everything with regards to the JS side of plugin check ...


So, turning the first three points into questions.

1. What is the scope of the plugincheck service? In particular, which Operating Systems and which browsers?

2. Which plugins (by OS and browser) are you tracking?

3. Does the database need any maintenance and/or revised procedures to allow it to provide a robust set of quality data to 'drive the new plugincheck service'?

I am thinking that someone may need to run some queries to find all the "status": "latest" plugins and to update the records for any that are now, in fact, vulnerable.

I am also wondering:
- is their enough detail in the database to allow us to select by OS & browser?
- can we rely on "os_name": "*" to be correct? (It might be when the record is about an out of date plugin that is now "vulnerable".)

DJ-Leith
DJ, we're not touching the existing plugin check page that you appreciate. From what I know, it's not going away. This is just an additional data channel to support new Firefox versions.

> plugins that are tracked ... Let us suppose that there are 60.  Using the example scope of 4 OS
> browser combinations (above) the total current versions will be x4 (i.e. 240) and
> the 'penultimate version' / 'most recent, now vulnerable version' will also be x4 (another 240).

I don't know exactly, but it's more like 5-10 plugins - the ones that everybody has and that are the major attack vectors.
Second, as discussed in comment 40 / 41 we only need to track per OS if they are actually different per OS. That's not always the case.
Ditto per browser - they usually don't differ per browser at all (if we're talking about NPAPI only).

> One could generate the JSON ... daily, every hour etc - your choice.

At least, the JSON could be cached, yes, given that it's the same for every client. This can make the server a lot faster.
DJ, the new plugin check service is expected to work in other browsers, like Chrome and Safari, just like the current plugin check service does.
Hey all,

I am still forging through this, have been of sick for two days or so and though I would provide an update. So, I am taking a bit of a different approach to the data but, with the same desired outcome of course.

I am working from the original big data set and reducing and reducing until we get to only what we need. At this point I am down to having all releases for a plugin, per OS and then for each OS I only include the latest, first instance of outdated and the first instance of vulnerable so, that gives us three possible releases per OS, per plugin.

I am going to reduce this further by cross checking versions between operating systems and only keeping those version, and OS, where there is a difference.

However, with that said, the data I get back from the DB does make this process more cumbersome then it needs to be I believe and in some cases, the data looks to be simply incorrect, or outdated itself. A case in point would be to have a look at the past at:

http://sneethling.pastebin.mozilla.org/4276134

If you look at the third  set(array) at line 89, you will see that this is for all operating systems and, is for the Flash player plugin but, what you will also notice is the version numbers and the related statuses. This is obviously wrong as from that one reads:

11.9.900.170 - vulnerable
11.8.800.168 - outdated
but
11.3.300.0 - latest

If then also look at for example the version numbers for specifically Windows, you will see that the actual latest version is 12.0.0.43

I am not entirely sure what to do about this. We can either:

1) Fix up the data, which might be cumbersome and take some time, as it is all manual or,
2) Define whether it is safe to actually just ignore the releases marked as '*' and only concentrate on those assigned to an actual OS.

There are other small things as well like some being marked win and other Windows and one entry for Windows NT 6, but those are easily handled in a case statement.

I would love to hear everyone's feedback and suggestions on the above. Thanks!
Flags: needinfo?(cpeterson)
Flags: needinfo?(cbook)
Flags: needinfo?(ben.bucksch)
• I understand why we would want to track a plugin's "vulnerable" versions in addition to the latest version (so we can show the user a bigger warning), but why do we need to track "outdated" version?

• How is our version data maintained? I have filed bugs to request plugin version updates, but maybe we can build a more reliable system. Could we automate it with a daily cron job that scrapes version numbers from web pages on (for example) adobe.com [1] or Wikipedia [2]?

[1] http://www.adobe.com/software/flash/about
[2] https://en.wikipedia.org/wiki/Adobe_Flash_Player
Flags: needinfo?(cpeterson) → needinfo?(schalk.neethling.bugs)
(See post by Chris Peterson (:cpeterson) from comment #44)
> DJ, the new plugin check service is expected to work in other browsers,
> like Chrome and Safari, just like the current plugin check service does.

Good to have this confirmed that, as far as we know, the scope is still quite wide: in terms of both browsers and OS.

(See post by DJ-Leith from comment #42)
> 1. Scope
> > "Plugin Check for Everyone"
> > by Johnathan Nightingale
> > 11 May 2010
> > http://blog.mozilla.org/security/2010/05/11/plugin-check-for-everyone/
> > 
> 
> Included in Johnathan Nightingale's post is:
> 
> " ... We believe that plugin safety is an issue for the web as a whole,
> so while our initial efforts focused on building a page that would work
> for Firefox users, the team has since expanded plugin check coverage to
> work with Safari 4, Chrome 4, and Opera 10.5. We have added support for
> Internet Explorer 7 and 8 for the most popular plugins, as well, but since
> IE requires specific code to be written for each plugin it will take us a
> little longer to get to full coverage. ..."
> 
> > 
> > Is this still the best scope? - has it widened (or narrowed) since May 2010?
> > Which browsers are you able to assess at plugincheck?
> > For example, is Opera in scope? See bug 875058
> > Which Operating Systems are you supporting?

****
The 'plugincheck service' has always, and will continue, to rely on the
quality of the data in the database.
****

As Ben Bucksch (:BenB) said in comment #43

> This is just an additional data channel to support new Firefox versions ...

The 'current plugincheck service' relies on getting information from the database.  I think Schalk knows how - he has worked on the 'plugincheck web site'.

I imagine that this is NOT 'totally automated' i.e. driven by an algorithm.
I imagine some human, intelligent, decisions are made.

Do any readers of this bug know any of the people who put data into the database?
Perhaps they could comment.

Schalk has already pondered if data, as it is currently in the backup of the
database he received on 22 January 2014, is inaccurate.

"inaccurate" might be the wrong word.
What I'm thinking is that, for it to be a source for an 'automated system' - the JSON list -
we may need to:

A. Make a manual check to make sure that there is one ONE "latest" record for each
Plugin (by OS and browser).  All other (older versions) should be marked "vulnerable",
if the vendor has declared that, or "outdated".

This would be a 'one off exercise'.

See also, for another way of saying this (comment # 42):
> I am thinking that someone may need to run some queries to find all the
> "status": "latest" plugins and to update the records for any that are now,
> in fact, vulnerable.
> 
> I am also wondering:
> - is their enough detail in the database to allow us to select by OS & browser?
> - can we rely on "os_name": "*" to be correct? (It might be when the record is
>     about an out of date plugin that is now "vulnerable".)

B. Have a new procedure that when a 'new plugin record is made' a check is also made so that
the 'previous version's record' is amended to show that it is now vulnerable.

(see post by Schalk Neethling [:espressive] in comment #45)
> 1) Fix up the data, which might be cumbersome and take some time, ...

In my opinion, I think this might be the best thing to do in the medium term.


Ben Bucksch said, in comment #4,

> Schalk, I think it's better to make the minimal - or reasonable - change needed
> for this bug here, and make the big rewrite in a separate bug.

My comment on this is: if you are making an additional 'communication channel'
between the database and the 'plugincheck web site' you may wish it to cover
all your medium term needs and not just the narrow scope required for Firefox 28+.

If the 'JSON data channel' (this bug) could provide 'all the data needed'
(current version and 'most recently declared vulnerable / outdated')
for each plugin - for all OS and browsers (in scope) - then the 'plugincheck web site'
(bug 938885 and bug 965812) could use this source. 

(see Schalk Neethling [:espressive] in comment #45)
> I am working from the original big data set and reducing and reducing
> until we get to only what we need. At this point I am down to having all
> releases for a plugin, per OS and then for each OS I only include the
> latest, first instance of outdated and the first instance of vulnerable so,
> that gives us three possible releases per OS, per plugin.
> 
> I am going to reduce this further by cross checking versions between
> operating systems and only keeping those version, and OS, where there is
> a difference.

In my opinion, a good approach.
Once the data has been cleaned the ambiguities should, I hope, be gone. 

DJ-Leith


PS

See
Adobe Security Bulletin, APSB14-02, 14 January 2014
http://helpx.adobe.com/security/products/flash-player/apsb14-02.html

This is NOT the latest Flash security update.
It does illustrate that Adobe do use many version numbers for Flash.

Windows and Firefox, 12.0.0.43
Windows and IE, 12.0.0.38
Macintosh and Firefox (as well as Opera and Safari), 12.0.0.38
Linux and Firefox, 11.2.202.335

PPS

I agree with all Chris Peterson's points in comment #46.
(In reply to Chris Peterson (:cpeterson) from comment #46)
> • I understand why we would want to track a plugin's "vulnerable" versions
> in addition to the latest version (so we can show the user a bigger
> warning), but why do we need to track "outdated" version?

For some plugins such as Java that has multiple 'supported' versions, we do not always have a latest anymore and there is for example only an outdated or vulnerable. In the latter case, it is simple and the user will simply be told to upgrade but, with outdated, it is a bit more tricky. With those, there is no real 'identified' vulnerability so, we could/should not just say upgrade, but should suggest it more subtly. Although, I personally feel, if you are not running that latest we should simply inform the user to upgrade for their own security.

On a side note, on the current plugincheck page we do keep track of outdated as well.
https://github.com/mozilla/bedrock/blob/master/media/js/plugincheck/check-plugins.js#L61

Do we perhaps want to remove this and only 'toggle' between, up to date, unknown and vulnerable?

> 
> • How is our version data maintained?

At the moment this is all manual and handled, as far as I know, by :Tomcat (Carsten Book)

(In reply to DJ-Leith from comment #47)
> 
> As Ben Bucksch (:BenB) said in comment #43
> 
> > This is just an additional data channel to support new Firefox versions ...
> 
> The 'current plugincheck service' relies on getting information from the
> database.  I think Schalk knows how - he has worked on the 'plugincheck web
> site'.
> 
> I imagine that this is NOT 'totally automated' i.e. driven by an algorithm.
> I imagine some human, intelligent, decisions are made.

At the moment the plugin page (mozilla.org/plugincheck) works by querying the plugins service for each plugin it finds in turn and updates the plugin page with the status returned from this service.

> What I'm thinking is that, for it to be a source for an 'automated system' -
> the JSON list -
> we may need to:

There is some talk about how we can make the plugin service more automated, perhaps :Tomcat can expand on this?

> 
> A. Make a manual check to make sure that there is one ONE "latest" record
> for each

I agree we should update the DB to ensure the data is less ambiguous.

>  
> Ben Bucksch said, in comment #4,
> 
> > Schalk, I think it's better to make the minimal - or reasonable - change needed
> > for this bug here, and make the big rewrite in a separate bug.
> 
> My comment on this is: if you are making an additional 'communication
> channel'
> between the database and the 'plugincheck web site' you may wish it to cover
> all your medium term needs and not just the narrow scope required for
> Firefox 28+.

I completely agree and it is something that puzzle me. There is a lot of time and effort going into this JSON service and it would be a pity to end up only using it for the upcoming Fx releases and not get the benefit of having a, much simpler, unified plugincheck web page by having all supported browsers and operating systems use this same service.
Flags: needinfo?(schalk.neethling.bugs)
(In reply to Schalk Neethling [:espressive] from comment #48)

> > • How is our version data maintained?
> 
> At the moment this is all manual and handled, as far as I know, by :Tomcat
> (Carsten Book)
> 

indeed, its all copy and paste at the moment , so all purely manual


> > What I'm thinking is that, for it to be a source for an 'automated system' -
> > the JSON list -
> > we may need to:
> 
> There is some talk about how we can make the plugin service more automated,
> perhaps :Tomcat can expand on this?
> 
> > 

yeah i talked with my manager and will follow up maybe this week (was out sick last week)
Flags: needinfo?(cbook)
I understood "outdated" as "no longer supported" = "gets no more security fixes" = implies "vulnerable".
Is this materially correct?
If so, we should treat it as vulnerable. There are tons of users with really outdated Java versions which have more holes than Swiss cheese.
Flags: needinfo?(ben.bucksch)
espressive, we have the source code of the server-based plugin check. Can't you look there for advise on how to use the data in the database? If the old algorithm was wrong or bad, I'm all for fixing it, but it seems we're a bit at a loss here, so I'd like to at least know what the old algorithm did.
(In reply to Ben Bucksch (:BenB) from comment #50)
> I understood "outdated" as "no longer supported" = "gets no more security
> fixes" = implies "vulnerable".
> Is this materially correct?
> If so, we should treat it as vulnerable. There are tons of users with really
> outdated Java versions which have more holes than Swiss cheese.

its correct for me from the logic of your argument but in the current logic of plugincheck vulnerable plugins need preferable a link to a security advisory. So current vulnerable plugins are plugin version who have a security advisory for that specific version
That makes sense. "vulnerable" = known security holes with advisory. "outdated" = implied vulnerable.

To me, that suggests that the wording to upgrade for outdated versions should be even stronger than for vulnerable (or at least as strong), because they presumably have more holes. "vulnerable" just needs additional UI code for the link to the security advisory.
(In reply to Carsten Book [:Tomcat] from comment #52)
> (In reply to Ben Bucksch (:BenB) from comment #50)
> > I understood "outdated" as "no longer supported" = "gets no more security
> > fixes" = implies "vulnerable".
> > Is this materially correct?
> > If so, we should treat it as vulnerable. There are tons of users with really
> > outdated Java versions which have more holes than Swiss cheese.
> 
> its correct for me from the logic of your argument but in the current logic
> of plugincheck vulnerable plugins need preferable a link to a security
> advisory. So current vulnerable plugins are plugin version who have a
> security advisory for that specific version

Yes, I do only include a release as a vulnerable release if it has a vulnerability url.

In terms of the current end point used for plugincheck, the process is basically that, on the client side the installed plugins and version is detected and then the PFS service is called for each plugin in turn, asking for information about that specific plugin version, for the particular OS and browser.

The important difference now is that we want to build a clean data structure, for all the plugins in the database but, only return information that are relevant for each plugin. We would then check the detected version for each plugin agains this new JSON object instead of shooting of Ajax calls to the PFS service/DB for each installed plugin.

So, it is important that we ensure that the data we end up with is accurate and fulfil our needs. It is taking longer than I believe most people thought it would, but I really think it is worth the effort. I will have a new JSON dataset ready for review tomorrow.
So, we can basically basket the vulnerable and outdated as both vulnerable, with the main difference being, vulnerable will have vulnerability URL to link to and outdated, might point one to a search on google for something like:

'Latest stable release for pluginname'

Basically the same kinda thing as we currently for unknown plugins i.e. the Research button.
> asking for information about that specific plugin version, for the particular OS and browser.

I meant what the server is doing. For example, you're asking the server for Java version 6.0.23, and the server doesn't happen to have that exact version in the DB. What does it return?

> I really think it is worth the effort

Agreed!

> might point one to a search on google for something like: 'Latest stable release for pluginname'

The download URLs for the plugins are normally fixed, so unless we have a specific upgrade path and download URL for a particular version, we can just keep one download URL for each plugin, and send the user there. E.g. for Java: http://www.java.com/download/
(In reply to Ben Bucksch (:BenB) from comment #56)
> > asking for information about that specific plugin version, for the particular OS and browser.
> 
> I meant what the server is doing. For example, you're asking the server for
> Java version 6.0.23, and the server doesn't happen to have that exact
> version in the DB. What does it return?

I have to revise my answer a little, from the server side, the plugincheck page actually asks for all versions of the plugin so, all versions of Java, Flash etc. not specific version.
To be even clearer regarding the server side, it asks for all plugins of a specific list of mime-types. 

From the client side, it looks like it will be marked as unknown:

https://github.com/ossreleasefeed/Perfidies-of-the-Web/blob/master/perfidies.js#L271
So, I wish to sketch a scenario and elicit some feedback on whether my thinking is correct or, whether I have gone of the tracks (NOTE: Stupid question might be ahead also, might contain traces of nuts):

We have a JSON list with the data we are happy with.

On the client side the list is loaded via Ajax.

Once loaded we start iterating through each plugin in the list.

For each of these, we grab the list of mimetypes, iterate over each and attempt to find it in the navigator.mimeTypes array

    navigator.mimeTypes['mime/type'];

If we find a match, we check enabledPlugins for this mimeType

    navigator.mimeTypes['mime/type'].enabledPlugin;

---

Now, at this point I have some questions:

1) If we have iterated through all of the mimeTypes for this plugin, found the mimeType(s) but, none of the mimeTypes had an associated enabled plugin (navigator.mimeTypes['mime/type'].enabledPlugin is always null), we skip the plugin. (This means, we know there are plugins that can handle the mimeType, the user just does not have such a plugin installed)

2) If we do not find any of the listed mimeTypes for the current plugin in the JSON in navigator.mimeTypes -  Skip? (So basically we have a plugin in our DB that can handle this/these mimeType(s) but, the browser does not have any knowledge of it)

3) If we do find the mimeType and the enabledPlugin is not null - Get the name and see if it matches our plugin:

    navigator.mimeTypes['mime/type].enabledPlugin.name === currentPlugin.name

3.1) If it matches, get the version number:

    navigator.mimeTypes['mime/type].enabledPlugin.version

and use this to determine whether the user's version of the plugin is up to date, outdated, or vulnerable, based on the data in the JSON list.

3.2) It does not match, mark as unknown? (i.e. unknown plugin for this mimeType)


4) Do we at this point discard the remaining mimeTypes (seeing that we have found a match) there might still be in the list for this plugin and continue to the next plugin or, do we continue going through the remaining listed mimeTypes for the current plugin?

- EOF

I will most likely have more questions, but this is it for now. I just wanted to step back and take a look at the big picture for a moment.
Flags: needinfo?(cpeterson)
Flags: needinfo?(cbook)
Flags: needinfo?(ben.bucksch)
(In reply to Schalk Neethling [:espressive] from comment #59)
> Now, at this point I have some questions:
> 
> 1) If we have iterated through all of the mimeTypes for this plugin, found
> the mimeType(s) but, none of the mimeTypes had an associated enabled plugin
> (navigator.mimeTypes['mime/type'].enabledPlugin is always null), we skip the
> plugin. (This means, we know there are plugins that can handle the mimeType,
> the user just does not have such a plugin installed)

There is also the possibility that navigator.mimeTypes['mime/type'].enabledPlugin is NOT null but also not equal to the expected plugin name in our database.

Instead of implementing loops within loops with complicated logic to break early, a simpler approach might be to split the process into two steps:

1. Create a list of all installed plugins by enumerating the JSON's known mimeTypes, querying navigator.mimeTypes, and collect the enabledPlugins into a map. Using the plugin name as a map key will let us remove redundant plugin entries (where a plugin handles multiple mimeTypes, which is very common).

2. Enumerate the map of installed plugins, querying the JSON plugin names and checking installed version numbers.

This is the pseudocode I am imagining:

    // Gather a list of all installed plugins for JSON's known mimeTypes.
    installedPlugins = {}
    for knownMimeTypeName in JSON.mimeTypes {
        mimeType = navigator.mimeTypes[knownMimeTypeName]
        enabledPlugin = mimeType || mimeType.enabledPlugin
        if enabledPlugin {
            // insert into map by plugin name to dedupe multiple plugin entries from multiple mimeTypes.
            installedPlugins[enabledPlugin.name] = enabledPlugin
        }
    }

    // Check installed plugin versions against JSON's known plugin versions.
    for installedPluginName in installedPlugins {
        knownPlugin = JSON.plugins[installedPluginName]
        if knownPlugin {
            installedPlugin = installedPlugins[installedPluginName]

            // check plugin version
            if installedPlugin.version === knownPlugin.version {
                display happy message about installed plugin is the latest known version
            } else if installedPlugin.version is newer than knownPlugin.version {
                display warning about outdated plugin!
            } else {
                display warning about unexpected plugin version from the future?!
            }

            // also check whether installed plugin is vulnerable (irrespective of version)
            if knownPlugin.isVulnerable {
                display warning about vulnerable plugin!
            }
        } else {
            display warning about installed plugin not known by our database?!
        }
    }


> 2) If we do not find any of the listed mimeTypes for the current plugin in
> the JSON in navigator.mimeTypes -  Skip? (So basically we have a plugin in
> our DB that can handle this/these mimeType(s) but, the browser does not have
> any knowledge of it)

Yes.


> 3) If we do find the mimeType and the enabledPlugin is not null - Get the
> name and see if it matches our plugin:
> 
>     navigator.mimeTypes['mime/type].enabledPlugin.name === currentPlugin.name
> 
> 3.1) If it matches, get the version number:
> 
>     navigator.mimeTypes['mime/type].enabledPlugin.version
> 
> and use this to determine whether the user's version of the plugin is up to
> date, outdated, or vulnerable, based on the data in the JSON list.
> 
> 3.2) It does not match, mark as unknown? (i.e. unknown plugin for this
> mimeType)
>
> 4) Do we at this point discard the remaining mimeTypes (seeing that we have
> found a match) there might still be in the list for this plugin and continue
> to the next plugin or, do we continue going through the remaining listed
> mimeTypes for the current plugin?
Flags: needinfo?(cpeterson)
> navigator.mimeTypes['mime/type].enabledPlugin.name === currentPlugin.name

I think you'll need some sort of substring match, right? From what I know, versions are sometimes in the name, and plugins like to change their display names.

> do we continue going through the remaining listed mimeTypes for the current plugin?

It may be that a plugin is configured to handle only a subset of the types it can handle, yes.

And, as Chris said, the mimetype might be handled by another implementation. (E.g. PDF plugin not from Adobe, Quicktime handled by mplayer etc.)
Flags: needinfo?(ben.bucksch)
Here is the latest data object we would end up with for, for example Flash:
http://sneethling.pastebin.mozilla.org/4336873

I am very hesitant on keeping the 'all' list as, from what I have seen so far, the data it contains is not useful at all. Thoughts?
Flags: needinfo?(cpeterson)
Flags: needinfo?(ben.bucksch)
Perhaps only keep 'all' if either win, mac, or lin is empty?
For example, the Yahoo Browser Plus plugin only has information in 'all':
http://sneethling.pastebin.mozilla.org/4336946
adding dburns to this bug, in case the A-team or so can help think about ideas about automating
Flags: needinfo?(cbook)
Thanks for the sample.

A lot of that data makes no sense to me. If 11.8 is "outdated", then 11.3 will hardly be the "latest". Likewise, I would be surprised to see that 11.2 is fine on linux, while 11.7 on Mac and Windows are known to be vulnerable.

First order of business needs to be to get the data straight and matching reality. Only then can you make an efficient data structure. (Compare comment 41.)
Flags: needinfo?(ben.bucksch)
Ben,

I agree, that is what I see often, especially with the 'all' group. The versions and status looks completely incorrect.
Delighted to read comment # 48 through to comment # 67.

I have also read the comments in perfidies.js
https://github.com/ossreleasefeed/Perfidies-of-the-Web/blob/master/perfidies.js
I think I understand the comments, I'm not claiming that I understand the JavaScript.


FAO Carsten Book [:Tomcat]
Thanks for maintaining the database: I'm one of MANY who finds it, and the
'plugincheck service' - which relies on it, useful.

(see Carsten Book [:Tomcat] comment # 49)
> > > What I'm thinking is that, for it to be a source for an 'automated
> > > system' - the JSON list - we may need to:
> >
> > There is some talk about how we can make the plugin service more automated,
> > perhaps :Tomcat can expand on this?
> >
> > 
> 
> yeah i talked with my manager and will follow up maybe this week ...

Like others, I also think it would be very good to make sure that there is
only ONE "latest" record for each plugin (by OS and browser).


(In reply to Schalk Neethling [:espressive] in comment #59)

> ... wanted to step back and take a look at the big picture for a moment ...

My understanding of the big picture is described using a broader brush
(that is less code centric).

****
Existing / current, OLD, plugincheck service
****

Old 1. User, with browser comes to 'plugincheck web site'
https://www.mozilla.org/%LOCALE%/plugincheck/

The US version of 'plugincheck' is at
https://www.mozilla.org/en-US/plugincheck/

Old 2. 'plugincheck web site' detects browser and OS
(I assume this and I assume this detection is coded
in JavaScript - [I don't KNOW]).

Old 3. 'plugincheck web site' uses enumeration to discover
all plugins installed in browser.
I'll call this the "detected in browser, by enumeration, list".
In anthropomorphic English:
"Please give me a list of the plugins you have installed (and I'll
then check these for you)."

Old 4. Then each plugin in the "detected in browser, by enumeration, list"
is assessed by the 'plugincheck web site' using the
"Plugin Finder Service" (PFS) - perfidies.js etc.

Old 4.1 Each can be classified / categorised as

DISABLE:          "should_disable", (perfidies.js - line 165 ff for comments)
VULNERABLE:       "vulnerable",
MAYBE_VULNERABLE: "maybe_vulnerable",
OUTDATED:         "outdated",
MAYBE_OUTDATED:   "maybe_outdated",
CURRENT:          "latest",
UNKNOWN:          "unknown",
NEWER:            "newer".

Old 5. The 'plugincheck web site' then displays the plugins in the
"detected in browser, by enumeration, list"
with appropriate colors, warnings, 'Research links' etc.



****
The NEW plugincheck service
****
(required for Fx28+ because of
"disallow enumeration of navigator.plugins" bug 757726)

"Fix plugincheck to not use plugin enumeration" bug 938885

and this bug:
"Publish JSON list of all plugins for use on /plugincheck" bug 956905

New 1. User, with browser comes to 'plugincheck web site'
NO CHANGE from Old 1.

New 2. 'plugincheck web site' detects browser and OS
NO CHANGE from Old 2.

New 3. 'plugincheck web site' uses the 'JSON list' to
'drive the detection process'.

For EACH plugin in the 'JSON list' test to see if the
'visiting browser' has this plugin installed.

In anthropomorphic English:
"Have you got AA installed?, Have you got AB installed?, Have you got BB installed?,
Have you got Java 6.xx installed?, Have you got Java 7.xx installed?"

https://en.wikipedia.org/wiki/Java_version_history


Example
navigator.plugins["Unity Player"].name // get plugin by SPECIFIC name.
See
http://cpeterso.com/blog/02013/11/cloaking-plugins-to-limit-browser-fingerprinting/

If it is installed, then also detect version of the installed plugin.

New 3.1 produce a list of plugins called:
"detected in browser, by direct interrogation, list"

How this 'New 3' could be done is discussed in comment # 60.

See comment #59 through 67 where the difficulty of producing a useful
'JSON list' directly from the database is discussed.

New 4.

New 4A. EITHER - compare each plugin in the
"detected in browser, by direct interrogation, list"
with the 'JSON list' - to assess if they are "vulnerable",
"latest" etc.  In order to do this you will have to be confident
that the 'JSON list' has ALL the data you need.

New 4B. OR - use the existing PFS service and all of Old 4.1 (above).
So very similar to Old 4 and Old 4.1.

New 5. The New 'plugincheck web site' will then display the plugins in the
"detected in browser, by direct interrogation, list"
with appropriate colors, warnings etc.

There will be NO "Unknown" plugins (and so no 'Research links').
See, "Other 1 - "unknown" plugins", below.

So, key questions:

A. Do you want to use the 'JSON list' JUST to do step New 3:
"detected in browser, by direct interrogation"?
I.e. use New 4B, the existing PFS service and all of Old 4.1 (above)
to do the 'assessment of each plugin that has been discovered by
direct interrogation'.

If so, you could have a simple, manually maintained 'JSON list'.
You could also have a simple, automatically generated 'JSON list'.

B. Do you want to use the 'JSON list' to also answer the question:
"Is this plugin, in the [detected in browser, by direct interrogation, list]
vulnerable?".

If so, the 'JSON list' will need to have a lot of accurate data.
This may well be the 'way to go' in the medium term.


So, how does my 'big picture' compare with Schalk's - in comment # 59?

It may turn out that in order to automatically produce a 'JSON list' to do
'New step 3' (to ask the specific questions) so much work will have to be
done to tidy the database that you could also use this list to do the
assessment of the plugins (provide answers about "latest", "vulnerable").


Questions for Schalk:

How many plugins are listed at
https://plugins.mozilla.org/en-us ?

Are they similar in number, and similar in 'main name' e.g. "Adobe Acrobat",
"Google Earth Plugin" etc (i.e. I'm not counting all the versions) to the
'JSON list'?


Two Other points

Other 1 - "unknown" plugins

As noted in
"RFE an "About plugincheck" page, visible from plugincheck"
bug 965812 there will be NO "unknown" plugins in the
NEW plugincheck service.

If they are NOT in the 'JSON list', they will not be in the
"detected in browser, by direct interrogation, list" because you
have NOT asked if they are installed.

See also 
"Plugincheck doesn't show any results for the Unknown Plugins"
bug 973352

Any 'JSON list', simple or detailed, could be a source for the
"About plugincheck" page - for bug 965812.


Other 2 - Fix plugincheck to NOT use ANY plugin enumeration

A good test of the NEW plugincheck service, when you are ready to test it,
would be to set the "plugins.enumerable_names" preference to the empty string "".

This would then NOT use enumeration for ANY plugin at the
'plugincheck web site'.  All detection would be 'driven by the JSON list'.

See bug 952914 where DJ-Leith wrote:

> In https://bugzilla.mozilla.org/show_bug.cgi?id=757726#c105
> Chris Peterson (:cpeterson) wrote:
> 
> >   * Renamed "plugin.enumerableNames" pref to "plugins.enumerable_names"
> >   * Added special pref value '*' to disable all plugin hiding
> 
> So if you, via "about:config", change the "plugins.enumerable_names" preference to "*"
> all sites (including 'plugincheck') can still use enumeration of ALL plugins.
> 
> Once you have been to the site that YOU want to 'allow enumeration' you can then
> either
>   'set it back to default' (right click the line and choose "Reset")
> or
>   you can browse all sites with 'no enumeration allowed' by choosing the empty string "".


FYI, since 20 December 2013, I have been using Aurora as my MAIN browser with the
"plugins.enumerable_names" preference set to "Shockwave"
(NOT the default for 28+ of "Java,Nexus Personal,QuickTime,Shockwave").
I have yet to find a site that I use (apart from plugincheck) that I can't
use.  I'm not a 'typical browser' (I do have NoScript and RequestPolicy on
all my profiles).

DJ-Leith
(In reply to Schalk Neethling [:espressive] from comment #62)
> Here is the latest data object we would end up with for, for example Flash:
> http://sneethling.pastebin.mozilla.org/4336873
> 
> I am very hesitant on keeping the 'all' list as, from what I have seen so
> far, the data it contains is not useful at all. Thoughts?

I'm not familiar enough with this data to comment. :|
Flags: needinfo?(cpeterson)
> I agree, that is what I see often, especially with the 'all' group.

Note that not only the "all" group is wrong. At least "linux" was totally bogus, too.
The data seems to be completely neglected.

We don't need much, actually. Please see comment 26 and 28.
- Only a handful of plugins have several branches that the vendor actively maintains with security updates.
- Only very few bugs are OS-specific. Most security bugs affect all versions of the plugin. So when you have a security errata for 7.0.34 on Windows, then Linux version 7.0.23 can be assumed to be affected, unless we have information to the contrary.
- For most plugins, anything lower than the newest vulnerable version is outdated. That should make it fairly simple.

So, it should be too difficult to get the data straight, and to make a short list of latest vs. outdated.
bug 973352 looks related but I'm not sure whether to mark it as a duplicate. 

Is this something that should be tracked for Firefox 28?
(In reply to Liz Henry :lizzard from comment #71)
> bug 973352 looks related but I'm not sure whether to mark it as a duplicate. 
> 
> Is this something that should be tracked for Firefox 28?

This will only affect Firefox release 29, see https://bugzilla.mozilla.org/show_bug.cgi?id=938885#c30
Small update, we track 37 plugins in the DB
And here is the list:

string(8) "ActiveGS"
string(27) "Adobe Acrobat NPAPI Plug-in"
string(18) "Adobe Flash Player"
string(12) "Adobe Reader"
string(22) "Adobe Shockwave Player"
string(7) "Aliedit"
string(23) "Alipay security control"
string(11) "BrowserPlus"
string(25) "BrowserPlus (from Yahoo!)"
string(44) "Citrix Online Web Deployment Plugin 1.0.0.64"
string(23) "Citrix Receiver Plug-in"
string(21) "DevalVR - QTVR player"
string(17) "DivX® Web Player"
string(19) "Google Earth Plugin"
string(18) "Google Talk Plugin"
string(36) "Google Talk Plugin Video Accelerator"
string(31) "IcedTea Java Web Browser Plugin"
string(31) "InstantAction.com Game Launcher"
string(15) "iPhotoPhotocast"
string(19) "MetaStream 3 Plugin"
string(13) "Microsoft DRM"
string(47) "Microsoft® Windows Media Player Firefox Plugin"
string(16) "QuakeLive Plugin"
string(17) "QuickTime Plug-in"
string(21) "RealJukebox NS Plugin"
string(62) "RealNetworks(tm) Chrome Background Extension Plug-In (32-bit) "
string(10) "RealPlayer"
string(25) "RealPlayer Version Plugin"
string(47) "RealPlayer(tm) HTML5VideoShim Plug-In (32-bit) "
string(19) "Silverlight Plug-In"
string(5) "Totem"
string(12) "Unity Player"
string(13) "VidXWebPlayer"
string(22) "VLC Multimedia Plug-in"
string(17) "WacomTabletPlugin"
string(38) "Windows Media Components for QuickTime"
string(49) "Windows Media Player Plug-in Dynamic Link Library"
string(24) "Java Runtime Environment"
Here is the latest version of the JSON object:
http://sneethling.pastebin.mozilla.org/4380607

You will see that I have bundled all of the known mime types together at the bottom. The reason for this is, the following snippet of code:
http://sneethling.pastebin.mozilla.org/4380643

This uses the known mime types (hard coded in the snippet above), to detect installed plugins. This works great in both Fx release and nightly as well as Webkit based browsers.

One of the caveats is that getting the version information is not as straightforward as it is in Fx though as other webkit based browsers does not expose the version information inside enabledPlugin but, seems to stick it either in the name or description.

To get at this is not a big challenge though but, Flash throws a small spanner in the works in that, on Mac (from what I have seen so far, perhaps also Linux), it does not use semantic version numbers but marks Flash as, for example 12.0 r0 ugh...

Then there is our friend Java, which needs special attention as well as Internet explorer versions before IE11 because, before IE11, there is no navigator.plugins nor navigator.mimeTypes and plugin detection and version info, needs to be one via the ActiveXObject.

For Java and IE I believe we can continue to use http://www.pinlady.net/PluginDetect/ as the solution.

Thoughts and suggestions more than welcome.
Status: NEW → ASSIGNED
Flags: needinfo?(dj.4bug)
Flags: needinfo?(cpeterson)
Flags: needinfo?(ben.bucksch)
espressive, I would recommend to not change the normal plugin check at all. On the server, just publish the data we need, as a new function. On the client, it's Firefox only.

The existing plugin check page should be untouched. Otherwise you make the project much larger than necessary. Cross browser support is hairy and hard to test, simply out of scope for this bug. This would risk the whole change here.

Please make a change that is as small as possible, to move the webpage side of the check into Firefox. Limit the change.
Flags: needinfo?(ben.bucksch)
Flags: needinfo?(dj.4bug)
LGTM
Flags: needinfo?(cpeterson)
Thanks all for the feedback, I am going to start stitching this together.
During my continued work I have changed the JSON object to this:
http://sneethling.pastebin.mozilla.org/4444398

I am sure I will make more tweaks to it ;)
Slight tweak, separating plugins from mimeTypes:
http://sneethling.pastebin.mozilla.org/4444745
espressive, the mimetypes should be hanging off the plugin, i.e.
        "adobe-flash-player": {
            "display_name": "Adobe Flash Player",
            "mimetypes" : [ "application/x-shockwave-flash", "application/futuresplash" ]
            "versions": {
               ...
Ok, so I am happy to report that I am basically done with all the work on this and will post the info. probably tomorrow, on how everyone can go about testing the changes.

With that said, there are a couple of items I ran into as I have been working more and more in depth with the data etc.

1) First thing, in the data there is another OS reported on, SunOS do we want to include this in our JSON data or just ignore it? I am not even sure that the OS will be reported correctly and do not really have any way to test it myself.

Here is the data that is currently being left out, with regards to sunos:
http://sneethling.pastebin.mozilla.org/4469672

2) Looking at the known mimeTypes I get from the DB related to Java and manually testing them in the browser using either navigator.mimeTypes['mimtype'] or navigator.plugins['mimtype'] (for good measure), the only Java related item that is returned is for the Java Applet plugin so, it seems we will still need to Pinlady [http://www.pinlady.net/PluginDetect/Java/] detection for actual JavaSE detection. Here is the last of mimeTypes:
http://sneethling.pastebin.mozilla.org/4469677

I will look over this again and make absolutely sure I am not missing anything. Please let me know any thoughts or suggestions anyone has or whether I missed something.
Flags: needinfo?(cpeterson)
Flags: needinfo?(ben.bucksch)
Java is pretty cumbersome, yes, and something like pinlady is probably going to be required. Note that we can really only rely on the non-applet detection techniques, since Java is click-to-play both in browsers and in Java itself and unlikely to actually run anywhere. If we could tell pinlady not to fallback to applet detection that would be great.
(In reply to Schalk Neethling [:espressive] from comment #83)
> 1) First thing, in the data there is another OS reported on, SunOS do we
> want to include this in our JSON data or just ignore it? I am not even sure
> that the OS will be reported correctly and do not really have any way to
> test it myself.

I would just drop SunOS/Solaris data. :) Mozilla doesn't provide official Firefox builds for Solaris. The macromedia.com download links in that json are 404. Adobe does not list Solaris as supported for the current version of Flash (12), though it does list support in Flash 11:

http://helpx.adobe.com/flash-player/kb/archived-flash-player-versions.html#main_Archived_versions


> 2) Looking at the known mimeTypes I get from the DB related to Java and
> manually testing them in the browser using either
> navigator.mimeTypes['mimtype'] or navigator.plugins['mimtype'] (for good
> measure), the only Java related item that is returned is for the Java Applet
> plugin so, it seems we will still need to Pinlady
> [http://www.pinlady.net/PluginDetect/Java/] detection for actual JavaSE
> detection. Here is the last of mimeTypes:
> http://sneethling.pastebin.mozilla.org/4469677

How does pinlady does non-applet detection work? Does JavaSE not register any MIME types visible in navigator.mimeTypes[]?
Flags: needinfo?(cpeterson)
The problem with Java is that the version reported to us is something like "10.51.2.13" which is almost meaningless. The actual plugin name is Java(TM) Platform SE 7 U51 and that's more interesting, but also it supports a whole boatload of MIME types such as application/x-java-applet;jpi-version=1.7.0_51 that let you determine the exact Java version from the MIME type list.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #84)
> Java is pretty cumbersome, yes, and something like pinlady is probably going
> to be required. Note that we can really only rely on the non-applet
> detection techniques, since Java is click-to-play both in browsers and in
> Java itself and unlikely to actually run anywhere. If we could tell pinlady
> not to fallback to applet detection that would be great.

I was thinking about the fact that Java is click to play and wondered how this will work because I know the pinlady detection always used to inject an applet that would report back the information about the Java version and such.

However, it much be doing it some other way as well as http://www.pinlady.net/PluginDetect/Java/ seems to detect the information just fine.
Just to make sure I am not losing it and that this has always been so (I seem to remember that it is) ;) We report on whether 'Java' is vulnerable or up to date by displaying the status of the Java Applet plugin (see attached) but, under the covers we are comparing the version of Java i.e. 1.7.5.0 etc. and not the applet plugin version which currently stands at 14.9.0 (on mac)

i.e. We basically have to find the application/x-java-applet;jpi-version=... with the highest jpi-version number and compare that with the known latest version number I get back from the plugins DB and ignore the version I get from enabledPlugin.version

This is completely doable, it just means additional work when it comes Java.
Flags: needinfo?(cpeterson)
Flags: needinfo?(benjamin)
How we currently display a vulnerable Java version. Or is plugin vulnerability separate?
So, I just updated my version of Java on Mac 10.9.2 running Firefox 27.0.1

With this, after restarting Firefox, the live production plugincheck (http://www.mozilla.org/en-US/plugincheck/) no longer reports on Java. The really weird thing is, if I type in the console:

navigator.mimeTypes;

And then click on the resulting MimeTypeArray object, I could usually filter the array so I only see mime-types related to Java. If I do that now, the array is void of anything Java related.

Doing the same for navigator.plugins results in the same.

http://screencast.com/t/tyqO4k8sWEbz

There is also no entry for Java anything in neither about:addons nor about:plugins


One thing to note though is that navigator.javaEnabled(); returns false.

FYI, in Nightly it all works fine.
espressive: I don't know how Plugin Check has been checking Java or how we should going forward. Does Java applet content actually work in Firefox 27? Are you testing the same profile with Firefox 27 and Nightly 30?
Flags: needinfo?(schalk.neethling.bugs)
(In reply to Chris Peterson (:cpeterson) from comment #91)
> espressive: I don't know how Plugin Check has been checking Java or how we
> should going forward. Does Java applet content actually work in Firefox 27?
> Are you testing the same profile with Firefox 27 and Nightly 30?

At the moment it uses pinlady detection, from what I know. The profiles for Release and Nightly are separate.
Flags: needinfo?(schalk.neethling.bugs)
Even though the browser responds with false on navigator.javaEnabled see screen shot.
Even though the browser responds with false on navigator.javaEnabled see screen shot.
So, running the new plugin detect against the data compiled from the last DB drop I got from Sheeri, I get the following results:

"---------------- Plugin start"
"Shockwave Flash"
"12.0.0.70"
"12.0.0.38"
"11.7.700.225"
"---------------- Plugin start"
"Google Talk Plugin"
"5.1.4.17398"
"2.8.7.6830"
0
"---------------- Plugin start"
"Google Talk Plugin Video Accelerator"
"0.1.44.29"
"0.1.44.15"
0
"---------------- Plugin start"
"Java Applet Plug-in"
"Java 7 Update 51"
"6.0.31"
"6.0.29"
"---------------- Plugin start"
"QuickTime Plug-in 7.7.3"
"7.7.3"
"7.7.1"
"7.6.4.0"
"---------------- Plugin start"
"Silverlight Plug-In"
"5.1.20913.0"
" 5.1.20913.0"
"5.1.10411"

NOTE: If the last of the version numbers is a 0 it means there was no vulnerable release. 

I have asked Sheeri today for a dump of the latest from the prod DB so I will update my local data and see what I get now.
Made some tweaks to the Java version exposed by the browser, so now we have:

"---------------- Plugin start"
"Shockwave Flash"
"12.0.0.70"
"12.0.0.38"
"11.7.700.225"
"---------------- Plugin start"
"Google Talk Plugin"
"5.1.4.17398"
"2.8.7.6830"
0
"---------------- Plugin start"
"Google Talk Plugin Video Accelerator"
"0.1.44.29"
"0.1.44.15"
0
"---------------- Plugin start"
"Java Applet Plug-in"
"7.0_51"
"6.0.31"
"6.0.29"
"---------------- Plugin start"
"QuickTime Plug-in 7.7.3"
"7.7.3"
"7.7.1"
"7.6.4.0"
"---------------- Plugin start"
"Silverlight Plug-In"
"5.1.20913.0"
" 5.1.20913.0"
"5.1.10411"
I should have noted, the order is:

installed
latest
vulnerable
Flags: needinfo?(benjamin)
espressive: 

* The installed versions are greater than the "latest" versions. Are the rows mislabeled?
* Is the Silverlight latest version " 5.1.20913.0" have a space in the string?
Flags: needinfo?(cpeterson) → needinfo?(schalk.neethling.bugs)
(In reply to Chris Peterson (:cpeterson) from comment #98)
> espressive: 
> 
> * The installed versions are greater than the "latest" versions. Are the
> rows mislabeled?
> * Is the Silverlight latest version " 5.1.20913.0" have a space in the
> string?

Yep, I am awaiting a new 'dump' from the prod DB, I am running against one from 2014-01-22
Flags: needinfo?(schalk.neethling.bugs)
(In reply to Schalk Neethling [:espressive] from comment #89)

> How we currently display a vulnerable Java version. Or is plugin vulnerability separate?

I think that Java (Java Platform, Standard Edition or Java SE) is installed machine wide.
Some people use JRE (Java Runtime Environment) as an abbreviation.
I think that the Plugins (if installed correctly) are also machine wide (in all browsers and all Profiles e.g. Nightly 30 and Release 27.0.1).

However, over the years there have been many issues with updating Java.
It has been common for a Profile to have more than one 'Java Plugin' following a Java update.

It is also possible to have Java plugins in one Profile but not in another (this in not normal).
This happened to Schalk - see comment #90 - I'll say more below.

> How we currently display a vulnerable Java version. Or is plugin vulnerability separate?
I think that 'plugincheck' is only testing the plugin (installed in the visiting browser).
So, as the example in comment #90, because there was no 'Java plugin' in Fx 27.0.1
it was not tested.

I think once the 'Java plugin' is detected the version of the JRE is then inferred
as Benjamin Smedberg [:bsmedberg] said in comment # 84 and comment # 86.


Schalk, as I think you appreciate, in Fx 30 you CAN still use the current 'plugincheck'
if you set 
> ... the "plugins.enumerable_names" preference to "*"

However, as I also said in comment #68, I am recommending that the new plugincheck
works without ANY enumeration (i.e. set "plugins.enumerable_names" to the empty string ""
when you are testing the 'new 28+ plugincheck').


Schalk, for the issue in comment #90 with your Fx 17.0.1 profile
you might find the following sheds some light:

"If the Java plugin does not appear in the Add-ons Manager even though Java is installed"
http://kb.mozillazine.org/Java#If_the_Java_plugin_does_not_appear_in_the_Add-ons_Manager_even_though_Java_is_installed

"Firefox 26 (Mac) blocks Java permanently"
http://forums.mozillazine.org/viewtopic.php?f=38&t=2785961

The OP desertman posted a link that illustrated:
> ... On the left is Safari 6.1.1 (with Java working after getting permission), 
> on the right is Firefox 26 (claiming that there is no Java installed).

Solution (in desertman's case) was:

> For whatever reason Firefox on my computer was set to open in 32-bit mode - then
> the Java plugin does not work. As soon as I put this back to normal (= 64-bit mode)
> Java worked again.


"What Version of Java Are You Using?"
http://javatester.org/version.html

I like Michael Horowitz's site.
There are several tests here - not just testing the plugin.

> On a computer with multiple web browsers, be sure to check the Java
> version in every browser. I say this because multiple copies of Java
> can sometimes be installed with different browsers using different copies.
> Also, Java can be enabled in one browser and disabled in another.
>  
> Note: The portion of Java that runs programs is referred to as either
> the Java Run-time Environment (JRE) or the Java Virtual Machine (JVM).

Schalk, see also "Java on Macs" much further down on the http://javatester.org/version.html page

DJ-Leith
Plugincheck running in Nightly \o/
espressive: Awesome work! Is this running on a staging server? http://www.mozilla.org/plugincheck/ does not recognize all my plugins.
Flags: needinfo?(schalk.neethling.bugs)
Hey Chris,

No, this is locally so, basically the *real* testing can start now. What I have done though is create a copy of the plugin-check page and made it part of the tests in Perfidies [https://github.com/ossreleasefeed/Perfidies-of-the-Web/tree/new-plugincheck] in a branch called new-plugincheck.

I am going to update the README to explain how to test this locally but basically, you point the JS to a local copy of the JSON data that would normally be returned from the server and you can test away. All you really need is some form of a http server, the built in one that comes with Python works just fine.

For example, I added the following line to my .bash_profile:

    https://github.com/ossreleasefeed/dotfiles/blob/master/.bash_profile#L45

The inside the cloned dir of Perfidies I just do:

    server

And can then access the test page via:

    127.0.0.1:8000/tests/plugincheck.html

Will update this bug once I have updated the README but, we are close.
Flags: needinfo?(schalk.neethling.bugs)
Readme updated with instructions for testing this locally on any machine (pretty much ;))

https://github.com/ossreleasefeed/Perfidies-of-the-Web/tree/new-plugincheck#development-and-testing

Let me know if anything is unclear or does not work.
With regards to the data in plugins.m.o I see some issues we are going to run into, especially on Windows, but also on Mac to a certain degree with regards to inconsistent vulnerable and latest release numbers. (To be honest, it might also be the code that is extracting this incorrectly, which I will double check).

For example with regards to Flash:

Under 'all'

latest = 12.0.0.70
vulnerable = 12.0.0.44

Under 'win'

latest = 10.0.45.0
vulnerable = 11.7.700.224

Under 'mac'

latest = 10.3.183.90
vulnerable = 11.7.700.225

This is based on a DB extract of ~1 week ago. If it turns out that this *is* an issue with the data on plugins.m.o and not the code building the JSON, what would you suggest is the quickest and easiest way to resolve this?

I am thinking:
1) Remove the entries for Windows and Mac and have them just fall back to 'all'
2) Update the entries for Windows and Mac to match that in 'all'

Let me know your thoughts. Thanks!
Flags: needinfo?(cbook)
So, I did a couple of queries against my local extract of the DB and the numbers I provided in my previous email, is indeed what is reflected in the DB.
(In reply to Schalk Neethling [:espressive] from comment #105)

> I am thinking:
> 1) Remove the entries for Windows and Mac and have them just fall back to
> 'all'
> 2) Update the entries for Windows and Mac to match that in 'all'
> 
> Let me know your thoughts. Thanks!

Hm first both sounds good. But i wonder if this does not result into problems. We had cases where plugin vendors like adobe pushed a new Flash release and as example:

windows version were like x.x.2
and mac like x.x.3 

and the previous version x.x.1 was marked as vulnerable

where both releases came at the same time and both of them fixed a security problem. So plugincheck had to know which version is mac and windows

So following your suggestions for 1/2 would that result in the situation that with version x.x.2 on windows and as latest version x.x.3 (on mac) that windows user would get anything else then latest/up-to-update ? Or would that result in some error messages for windows users ?
Flags: needinfo?(cbook)
(In reply to Carsten Book [:Tomcat] from comment #107)
> (In reply to Schalk Neethling [:espressive] from comment #105)
> 
> So following your suggestions for 1/2 would that result in the situation
> that with version x.x.2 on windows and as latest version x.x.3 (on mac) that
> windows user would get anything else then latest/up-to-update ? Or would
> that result in some error messages for windows users ?

So, I do not suggest we go ahead and just remove the individual entries for windows and mac and keep only all, what I am saying is that, currently, when there is data for all, windows and mac, the information in 'all' seems valid but, the information for windows and mac seems out of date.

So, we can be al means continue to have these separate entries for each OS, the only thing we need to be sure of is that we keep the information consistent and up to date for all operating systems as well as 'all'.

As you can see from comment 105, currently for windows users, the Flash version marked as latest, is older than the version marked as vulnerable so, this will definitely cause problems when checking whether someone's plugin is in fact up to date or vulnerable:

Windows
--------
latest = 10.0.45.0
vulnerable = 11.7.700.224
so the issue is that some plugin vendor are starting now (or have already) some kind of branches for latest and older OS Versions like adobe.

They have 12.0.0.77 as general and "For users of Flash Player 11.7.700.269 and earlier versions for Windows and Macintosh, who cannot update to Flash Player 12.0.0.77, Adobe has made available the update Flash Player 11.7.700.272, which can be downloaded here." 

In some cases this also depended of the the OS Version a User use and so we would need to know always which OS this affects etc and need to take care of it, which complicates the Plugincheck check work and also is a issue for Schalk and his work on the databases.

So i guess we need to decide here to solve this kind of roadblock what we want to do here:

1.) focus on the latest Plugin Version on a OS 
or 2.) support all branches from a Plugin Vendor which would require a lot more work and also makes the database a little screwed with a lot more entries for every case (OS Version depended etc) and is a development issue

I'm in favor for 1 to avoid also issues that we already have with too many version entries in plugincheck but i wanted to collect feedback on this :)
Flags: needinfo?(cpeterson)
Flags: needinfo?(benjamin)
Couple of things also to note here:

1) The updated version of BrowserDetect that is being used inside plugincheck now only returns for example Mac, and no longer a string such as Intel Mac OS X 10.9

  -- This means getting the latest and vulnerable version for a specific OS version is impossible.

2) With that said however, navigator.oscpu gives me "Intel Mac OS X 10.9" for example, the question is, how well is this property supported by various browsers and, is it's return value consistent across browsers and operating system versions.

3) Answer to the above, only Fx supports the beautiful property. Now, the OS version bits can be extracted from navigator.userAgent but, here are inconsistencies we need to consider when deciding how to move forward.

  -- On Mac using Fx I will get something like Macintosh; Intel Mac OS X 10.9
  -- On Mac using Chrome I will get something like Macintosh; Intel Mac OS X 10_9_2
  -- On Windows 7 using IE I will get it reported as Windows NT 6.1

And that is only for three browsers on two different operating systems O_O
I don't understand comment 109: it has already been the case for a long time that there are multiple secure versions of Flash, and we just need to be able to support that. They have ESR releases as we do: AIUI they still have supported versions of Flash 10.3 for some enterprise customers.
Flags: needinfo?(benjamin)
I think Plugin Check should support all stable branches of a plugin. Flash 11.7.x.y and Flash 12.0.x.y are effectively different products
Flags: needinfo?(cpeterson)
I agree with comment 111 and comment 112 but, does this effect the new plugin check work we are doing for Fx29+

What I mean is will a user be able to run Fx29+ on a OS version that does not support the latest version of Flash i.e. 12.0.x and can only support one of the branches such as 10.3 or 11.x ?

As I am typing this I am thinking the answer is going to be yes. The bigger question then is how do we handle all of these OS version v. plugin versions and ensure that we are comparing the right data against the right data.
I don't think that the OS has much to do with it (or should have much to do with it).

Certain versions of Flash are safe on all platforms:

12.0.x.y
11.7.x.y
11.2.x.y
10.3.x.y

If a user has any of those, we should indicate that they are "safe" (no matter what the platform).
Ok, so that means, instead of getting the most 'latest' (horrible english) version from the DB, we should get all versions that are marked as 'latest', and if a user has any of those, they are safe, correct?

So, with that in mind, we should first, before anything else, check if the user has one of these versions and only then, if none matched, determine whether the installed version is vulnerable.
or, can we just simply say that if your installed version does not match any of the latest versions, across os, we have, it is vulnerable?
Flags: needinfo?(cbook)
Flags: needinfo?(benjamin)
ugh, I meant for the current OS.

* We need editing of comments in Bugzilla
Hrm. I think it's more like:

* vulnerable if less than 10.3.x.y
* vulnerable if between 10.4... and 11.2.x.y
* vulnerable if between 11.3 and 11.7.x.y
* vulnerable if between 12.0 and 12.0.x.y
Flags: needinfo?(benjamin)
(In reply to Schalk Neethling [:espressive] from comment #116)
> or, can we just simply say that if your installed version does not match any
> of the latest versions, across os, we have, it is vulnerable?

hm i guess we cannot say this (also there might be at sometime just updates, so more outdated then vulnerable in such cases) - but in general benjamin with comment 118 is right
Flags: needinfo?(cbook)
(In reply to Carsten Book [:Tomcat] from comment #119)
> (In reply to Schalk Neethling [:espressive] from comment #116)
> > or, can we just simply say that if your installed version does not match any
> > of the latest versions, across os, we have, it is vulnerable?
> 
> hm i guess we cannot say this (also there might be at sometime just updates,
> so more outdated then vulnerable in such cases) - but in general benjamin
> with comment 118 is right

So, after the discussion that started at https://bugzilla.mozilla.org/show_bug.cgi?id=956905#c46 I have removed outdated from the JSON and only gather latest and vulnerable. Should I reintroduce outdated?
How about:

if version in latest_versions:
  'up to date'
if version in vulnerable_versions:
  'vulnerable'
if version > latest_versions[0]:
  'newer, so basically up to date'
else:
  'unknown/outdated, vulnerable'

Thoughts?
Flags: needinfo?(cbook)
Flags: needinfo?(benjamin)
Flags: needinfo?(ben.bucksch)
(In reply to Schalk Neethling [:espressive] from comment #121)
> How about:
> 
> if version in latest_versions:
>   'up to date'
> if version in vulnerable_versions:
>   'vulnerable'
> if version > latest_versions[0]:
>   'newer, so basically up to date'
> else:
>   'unknown/outdated, vulnerable'
> 
> Thoughts?

hm sounds good to me
Flags: needinfo?(cbook)
So, I have change the logic that generates the JSON to now, include all latest releases for a plugin except, where a release is marked as latest but, also has a vulnerability_url, as to me, this seems to indicate that, that release is actually vulnerable.

I am then now also including all vulnerable release for a plugin, but only if we have a vulnerability_url.

With those changes in place, Flash would now look something like this:
http://sneethling.pastebin.mozilla.org/4634113
Interestingly for linux we do not have any vulnerable releases or, we have no vulnerable releases that has a vulnerability_url so, perhaps I should include releases marked as vulnerable, even if it does not have a vulnerability URL.
As mentioned on IRC, we have no vulnerable releases in the DB for Flash (not sure if this is also the case with other plugins) so, the questions is, do we then for Flash on linux simply have:

if version in latest_versions:
  'up to date'
if version not in latest_versions:
  'vulnerable'
Oh, meant to indicate that the reason for their being no vulnerable releases for Flash on Linux in the DB could be because of https://bugzilla.mozilla.org/show_bug.cgi?id=968726, but Carsten can probably give some more info on that if needed.
Flags: needinfo?(cbook)
Flags: needinfo?(benjamin)
Attached file Adobe Flash versions in 2013 — 
Adobe Flash versions in 2013
(In reply to  Benjamin Smedberg [:bsmedberg] from comment # 111)

> ... it has already been the case for a long time that there are multiple secure versions
> of Flash, and we just need to be able to support that. They have ESR releases as we do: AIUI 
> they still have supported versions of Flash 10.3 for some enterprise customers.

(In reply to Chris Peterson (:cpeterson) from comment # 112)
> I think Plugin Check should support all stable branches of a plugin. Flash 11.7.x.y
> and Flash 12.0.x.y are effectively different products

I also agree with both comments (111 and 112).
Schalk, I think you may have to test for 'each branch of Flash' as if they were "different products".

The ESR version of Flash (and other popular plugins e.g. Adobe Reader) should also (in my opinion as a lower priority) be included in the database.  Once the database has the correct data I think you will be able to get 'high quality answers' from the database into the JSON (see comment # 17 and # 47).


Flash - Extended Support Release (ESR)

The 'current plugincheck' (bug was reported on 2014-03-01) is not able to deal with the
current ESR of Flash. The user who made the initial report, mustafacan, was on "Windows NT 6.3" which, I guess, is Windows 8.1 [or possibly Windows Server 2012 R2]) see:

"Mozilla plugincheck says latest Flash Player 11.7 (Extended Support Release) is vulnerable and tells me to update"
bug 978505


Back to this bug: there has been a lot of discussion about the database.
IIUC, Carsten Book [:Tomcat] does most of the hard work in maintaining it.

(In reply to Carsten Book [:Tomcat] comment # 49)
> ... i talked with my manager and will follow up maybe this week ...

Carsten, are you able to get any extra time / resource to 'improve the database'?
Is the attached spreadsheet, in comment # 127, of any use to you?
Are you tracking ESR versions of Adobe Flash or Adobe Reader plugins?


Nobody is claiming the data is perfect.
Is the data 'good enough'?

A1. Yes, the 'real plugincheck' relies on it.  Some plugins (e.g. Flash ESR) are possibly not tracked.
I will propose how it could be improved (see *** Database *** below).

A2. Yes, Schalk has been able to use it.

He got a local copy (comment # 20)
He created a local 'JSON list' that can extract 37 plugins 'to drive the discovery process (to use in place of enumeration of a visiting browser's plugins)'.  See comment # 75 for the list and comment # 76 for the JSON object (as at 2014-02-24).

Then, on 2014-03-10 (see comment # 101), using Nightly (Fx 30) and the local database, local JSON and local copy of the 'plugincheck site' (the Perfidies etc) he was able to 'detect and test' six plugins

Adobe Flash Player
Google Talk Plugin
Google Talk Plugin Video Accelerator
Java Runtime Environment
QuickTime Plugin-in
Silverlight Plug-in

These six are a subset of the 'list of 37', in comment # 75 - excellent.
The JSON, IIUC, can now 'drive the discovery of the plugins'.


Schalk, you said (in comment # 48)

> At the moment the plugin page (mozilla.org/plugincheck) works by querying the plugins
> service for each plugin it finds in turn and updates the plugin page with the status
> returned from this service.

Now that 'the local JSON' can find six of your plugins, can you then use the 'existing
method' to check if they are 'latest', 'vulnerable' etc?

None will be 'unknown' because you can only 'discover them' if they are 'in the list of the 37'
(the JSON object as in comment # 75 and # 76).

If you can, then the 'new 28+ plugincheck service' will be almost as good as the existing
service.

If you can, you might be able to proceed to [bug 965812] and bug 938885.
Work on the database could be done in parallel.
Work on the database would be useful in any case.

If you can NOT, because the database needs more work, then you'll need to wait for this.


*** Database ***

The 37 plugins in comment # 75 are a very good start.
However, I think we may need to track 'more than one branch' of the plugin for SOME of them.
So, we may end up tracking about 50 to 60 plugins.


Flash Versions.

Adobe have often used different version numbers for their 'latest Flash' depending on OS and browser.

e.g. 

From 2014-01-14 (APSB14-02)
http://helpx.adobe.com/security/products/flash-player/apsb14-02.html

Until 2014-02-04 (APSB14-04) [for 3 weeks]
http://helpx.adobe.com/security/products/flash-player/apsb14-04.html

The main versions of Flash were:
Windows (Internet Explorer), 12.0.0.38
Windows (Firefox), 12.0.0.43
Macintosh (Firefox), 12.0.0.38
Linux (Firefox), 11.2.202.335

Also
Flash ESR (Windows and Macintosh), 11.7.700.260
Shockwave (Windows and Macintosh), 12.0.7.148

I cite Flash because it is:
ubiquitous, frequently updated, has an 'ESR version' and is often being exploited in the wild.
It is a hard case (puns intended).

Other plugins will be much easier to track.

See the attached spreadsheet, in comment # 127.

Looking at the last two dozen Adobe Security Bulletins (APSB), which start in
December 2012 and cover all of 2013 I make the following observations:

In all (25 of 25) the 'version of Flash for Linux' is NOT the same as the version for Windows.
In all (25 of 25) the 'ESR of Flash' is NOT the same as the version for Windows.
In some (5 of 25) the 'version of Flash for Macintosh' is NOT the same as the version for Windows.
In most / all (at least 20 of 25) the 'version of Shockwave' is NOT the same as the version of Flash for Windows.

I propose that we track 6 versions:
Shockwave (Windows and Macintosh) and '5 Flash versions',
Flash for Windows and IE
Flash for Windows and Fx
Flash for Macintosh and Fx
Flash for Linux
Flash ESR (Windows and Macintosh)

The database already 'tracks Shockwave as a separate plugin vs Flash'.
(from comment # 75)
> string(18) "Adobe Flash Player"
> string(12) "Adobe Reader"
> string(22) "Adobe Shockwave Player"


*** Stage 1 - Tidy the Database ***

I propose that each of the 37 plugins is assessed by Carsten Book [:Tomcat] and his colleagues.

For each:
- does the author release plugins for different browsers and/or OS with the SAME version number?
    If "yes" then you only need to track one branch for the plugin.
    If "no", e.g. '2 branches plus an ESR' you would track 3 branches for the plugin.
        For the database you would have 3 different "pfs_id"s.

Once you have a complete list (which might be about 50 plugin names - each with a unique "pfs_id") you would then find, in the 
database, ONE 'latest version'.
All the others, in that branch / the "pfs_id", should be updated as "vulnerable".
The "vulnerability_url" should be added.


Using the example of "pfs_id": "shockwave-flash".

Or (from comment # 76)
> Here is the latest version of the JSON object:
> http://sneethling.pastebin.mozilla.org/4380607

"plugin_name": "adobe-flash-player" 

If the version is old (older than the 25 I've listed in the spreadsheet, in comment # 127) and you don't KNOW the exact "vulnerability_url" you could use e.g.
http://helpx.adobe.com/security/products/flash-player/apsb14-02.html
because this declares ALL 'old versions' vulnerable.

You would end up with a database with only
37 (to about 60) unique "pfs_id"s (or "plugin_name"s).
For each "pfs_id" (or "plugin_name") only ONE "latest" and many "vulnerable" or "outdated".

I presume that "pfs_id": "shockwave-flash" has become "plugin_name": "adobe-flash-player",
in some of the examples above in this bug, because of comment # 16.

The data in comment # 10 might be 'just an example'.
>        "pfs_id": "shockwave-flash",
>        "plugin_name": "Shockwave Flash",
>        "display_name": "Adobe Flash Player",
>        "version_number": "11.9.900.170",
>        "description": "Shockwave Flash 12.0 r0",
>        "mime_type": "application/x-shockwave-flash",

However, if we end up tracking Shockwave (Windows and Macintosh) and '5 Flash versions'
(as I proposed) no 'single version of Flash' would have this specific combination.

>        "plugin_name": "Shockwave Flash",
would go with
>        "description": "Shockwave Flash 12.0 r0"

and
>        "display_name": "Adobe Flash Player",
would go with
>        "version_number": "11.9.900.170",

Next, is from the spreadsheet (from comment #127).
======
Date              2013-12-10	
APSB              APSB13-28	
Adobe URL         http://helpx.adobe.com/security/products/flash-player/apsb13-28.html	
Windows and IE    11.9.900.170	
Windows and Fx    11.9.900.170	
Macintosh and Fx  11.9.900.170	
Linux and Fx      11.2.202.332	
Flash ESR         11.7.700.257	
Versions	  3 / 5	               In addition, 12.0.7.148 is ALSO 'latest' (see APSB13-28 – next).
Days since previous APSB            28	
Count of APSB since start of 2013   16

Date              2013-12-10	
APSB              APSB13-29	
Adobe URL         http://helpx.adobe.com/security/products/shockwave/apsb13-29.html	
Windows and IE    12.0.7.148	
Windows and Fx    12.0.7.148	       I think, plugincheck will 'detect this as Flash'.
Macintosh and Fx  12.0.7.148	
Linux and Fx      N/A	               No Linux or ESR
Flash ESR         N/A	
Versions          N/A	
Days since previous APSB           N/A	
Count of APSB since start of 2013   17	
======

So, if the data in comment # 10 is 'just an example' all is OK.
If it is not, then it may be a symptom of poor data in the database.

Comment # 17 assumed that the 'data was directly from the database', and it was therefore
a combination of two plugins: a "Shockwave Flash" (possibly 12.0.7.148) and
an "Adobe Flash Player" version "11.9.900.170".  Both were current in December 2013.


*** Stage 2 - Procedure for new versions of 'branches of tracked plugins' ***

Once you have 37 (to about 50) 'branches of tracked plugins'; each with its own "pfs_id"
and "plugin_name", you will need a procedure for adding new versions of the BRANCH.

I propose that you find the ONE record which is "latest", update this record to "vulnerable",
add the "vulnerability_url"
  (or make it "outdated" and add a 'outdated_url'
    [I don't know if this field is in the data dictionary - or possibly just use the
     "vulnerability_url" for "outdated" as well as "vulnerable"])
BEFORE you add the NEW record for the new version in the BRANCH.

At the end, there should still be only ONE "latest" per branch.  Using the example, from the
spreadsheet, when Adobe have an "Adobe Security Bulletin" for Flash there would be
5 'Flash branches' to update.  If the "Adobe Security Bulletin" was about Shockwave there
would be only one branch to update.

Of course, you may have a better procedure but it does appear that there many more records in the database that are "latest" than one would expect.


*** Quickly discovering new versions of 'tracked plugins' ***

I imagine that you may well receive 'advance notice of new versions' from the authors.

Have you considered Rob's excellent suggestion in bug 850992
"Automate Plugincheck Script running on the Server to detect newest versions."?

He proposes having a check for new versions of plugins that the 'plugincheck service' is tracking.

> ... All we need to do ... ... is have the Script running on the Server check if ANY User
> has a newer version of the Plugin installed than what the Script
> [DJ-Leith: the 'plugincheck service'] thinks is the newest version. When that occurs
> ONE mail can be sent to a small List of Maintainers, and they can manually check if
> our Script on the Server is OK or if it needs to be updated.

I think perfidies.js can find "newer" versions.

(from comment # 68)
> Old 4.1 Each can be classified / categorised as
> 
> DISABLE:          "should_disable", (perfidies.js - line 165 ff for comments)
> VULNERABLE:       "vulnerable",
> MAYBE_VULNERABLE: "maybe_vulnerable",
> OUTDATED:         "outdated",
> MAYBE_OUTDATED:   "maybe_outdated",
> CURRENT:          "latest",
> UNKNOWN:          "unknown",
> NEWER:            "newer".

It may be possible to get a 'report on "newer" plugins seen' as people visit the plugincheck web site.

So, I think there are practical ways to improve the quality of the data in the database.

DJ-Leith
Blocks: 990856
Attached patch publish_json_list.diff — — Splinter Review 
This is the patch file for the server side changes. Laura, if you have time to review the code that would be great but, anyone is free to review.
Attachment #8403231 - Flags: review?(laura)
Ignore the SVN patch, tuns out all of this lives on Github as well. Sent pull request:
https://github.com/lmorchard/plugindir/pull/1
Depends on: 1000321
The code for this bug has landed on stage i.e. plugins.allizom.org

Carsten is going to poke at it to ensure that my additions did not break anything in the process. This is highly unlikely but, better safe. The generation of the JSON list, which is what this bug is all about, I can confirm works:

https://plugins.allizom.org/en-us/plugins/plugins_list
Once this PR lands, it will close this bug: https://github.com/mozilla/bedrock/pull/1997
This is in production \o/
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: needinfo?(cbook)
Resolution: --- → FIXED
Hi
It seems that this same bug exists for the coming firefox version 30!!!
(In reply to AYMAN from comment #135)
> Hi
> It seems that this same bug exists for the coming firefox version 30!!!

The code is in production for this and the I believe the enumeration switch can be flipped for the version 30 release?
Flags: needinfo?(cpeterson)
While the code to produce the JSON list, this bug, is in production my question is:
"Is the 'new plugincheck service' ready for release?"

I have my doubts.

Schalk Neethling [:espressive] on 2014-06-02 at 00:02:13 PDT, in bug 1011824 comment # 8, said:

> Couple of things here:
> 
> The fix mentioned earlier has not gone live yet but, will today. There is a LOT of testing
> to be done to not only ensure that the bug is fixed but, to also ensure that no regressions
> are introduced so, it took longer than expected.
> 
> (quoting from bug 1011824 comment # 7)
> > Another question is:
> > Is the new in 2014 version of plugincheck ready for Fx 30 on 2014-06-09?
> > Should it be delayed until Fx 31 - in July?
> 
> After the fix above is released, I reckon we need to run it's through it's paces again and
> then someone needs to decide whether they want to flip the bits to turn enumeration of.
> 
> I am continuing to work on this and, at the same time, I am putting together a page that
> gives us in indication of where we are in terms of stability and accuracy of the service.

I have not yet seen the 
> ... page that
> gives us in indication of where we are in terms of stability and accuracy of the service.


For the
> ... LOT of testing ...
see bug 1010132 comment # 14 has a *large* list of test results.
Indeed, most of the comments after this - in that bug - are about the Adobe Acrobat plugin.

See also
Bug 1020133 "Improve Adobe Acrobat plugin reporting"
The 'existing plugincheck' can detect Adobe Acrobat correctly.
The 'new plugincheck' is unable to do this.



Since December 2103 I have been keen to:
A. Have enumenration off.
    I discussed this with Chris Peterson
    in bug 952914 "RFE: plugins.enumerable_whitelist_URLs to allow enumeration on a few trusted sites" 

but, before that goes live to

B. Inform users of plugincheck that THEY will no longer have "Unknown" plugins.
The loss of "Unknown" is a regression.
They will have to use other ways of checking their 'Unknown to plugincheck' plugins.

See bug 965812 "RFE an "About plugincheck" page, visible from plugincheck".
I have updated bug 965812 today.


AFAIK enumeration is still disabled for Fx 30 see:
bug 952602 "Disable bug 757726 for Firefox 28 release (changes to plugin detection)".

DJ-Leith
I am actually struggling to get QA on the plugincheck bugs of which there are two currently on stage. I will ping some people again today to get some QA done so that this can be pushed to prod.
Schalk: note that plugin enumeration is currently not disabled on any Firefox channel (bug 757726 comment 137) until Click-To-Play for all plugins is enabled by default. I would like to include Click-To-Play's longer whitelist with plugin enumeration.

When QA tests the plugincheck, they will need to manually change the "plugins.enumerable_names" pref from "*" to "Java,Nexus Personal,QuickTime,Shockwave".
Flags: needinfo?(cpeterson)
(In reply to Chris Peterson (:cpeterson) from comment #139)
> Schalk: note that plugin enumeration is currently not disabled on any
> Firefox channel (bug 757726 comment 137) until Click-To-Play for all plugins
> is enabled by default. I would like to include Click-To-Play's longer
> whitelist with plugin enumeration.

Oh wow, I was not aware of this. OK, so even if I wanted to test the new code I would need to manually override plugins.enumerable_names as suggested correct?

Do we have a ballpark of when the switch will be made?
(In reply to Chris Peterson (:cpeterson) from comment #139) 
> When QA tests the plugincheck, they will need to manually change the
> "plugins.enumerable_names" pref from "*" to "Java,Nexus
> Personal,QuickTime,Shockwave".

Does this apply to Beta, Aurora, Nightly as well as Release?
(In reply to Schalk Neethling [:espressive] from comment #141)
> (In reply to Chris Peterson (:cpeterson) from comment #139) 
> > When QA tests the plugincheck, they will need to manually change the
> > "plugins.enumerable_names" pref from "*" to "Java,Nexus
> > Personal,QuickTime,Shockwave".
> 
> Does this apply to Beta, Aurora, Nightly as well as Release?

At the moment, yes. I'm discussing release plans with bsmedberg.
(In reply to Schalk Neethling [:espressive] from comment #140)
> (In reply to Chris Peterson (:cpeterson) from comment #139)
> > Schalk: note that plugin enumeration is currently not disabled on any
> > Firefox channel (bug 757726 comment 137) until Click-To-Play for all plugins
> > is enabled by default. I would like to include Click-To-Play's longer
> > whitelist with plugin enumeration.
> 
> Oh wow, I was not aware of this. OK, so even if I wanted to test the new code
> I would need to manually override plugins.enumerable_names as suggested correct?
> 
> Do we have a ballpark of when the switch will be made?

First, Chris Peterson is *of course correct* in saying
> > plugin enumeration is currently not disabled on any Firefox channel

All can have
"plugins.enumerable_names" set to "*" - i.e. 'enumerate all plugins'.
I now think this may even be the default.

This part of comment # 137 was very poor - I apologise.
> AFAIK enumeration is still disabled for Fx 30 see:
> bug 952602 "Disable bug 757726 for Firefox 28 release (changes to plugin detection)".

Bug 952602 was to make sure that the *Release* version had "plugins.enumerable_names"
set to "*" for Firefox 28 release.
In other words 'enumerate all plugins': the OPPOSITE of what I said.

I think that there was another bug, which I can't find, but IIRC was to make
'future release versions of Firefox, 29+' to have
"plugins.enumerable_names" set to "*" as the default.



***
I think, from my tests, that 'new in 2014 version of plugincheck'
does NOT use enumeration.
***

FYI,
In December 2013, once I became aware of bug 757726, I decided to do as much
of my browsing as possible using an Aurora profile with
"plugins.enumerable_names" set to "Shockwave".

This was to 'find issues'.

Apart from plugincheck, where I had 'problems that I had anticipated',
I have been able to use most sites.

I still maintained all my release Profiles (updated all Addons)
and I still update plugins (machine wide).

Each day, I have used one of my Release profiles to do the plugincheck.

I also, often, did a test with Aurora.
When "plugins.enumerable_names" was set to "Shockwave" then 'only Flash was tested'.
When "plugins.enumerable_names" set to "*" all were tested (like Release).


Once the JSON list was in production (2014-05-12 comment # 134) I changed my
Aurora profile to
"plugins.enumerable_names" set to "" (empty string)

I also started to 'test plugins at Stage'
https://www.allizom.org/en-US/plugincheck/

This was to ensure that my tests of the 'new in 2014 version of plugincheck'
did NOT use enumeration.

My limited tests at STAGE using Aurora (Fx 31.0a2) confirm that 
"plugins.enumerable_names" set to "" (empty string) or
"plugins.enumerable_names" set to "*" [all plugins emumerated]
give the same results.

So, I conclude that 'new in 2014 version of plugincheck' is NOT using enumeration.

(In reply to Chris Peterson (:cpeterson) from comment #139)
> When QA tests the plugincheck, they will need to manually change the
> "plugins.enumerable_names" pref from "*" to "Java,Nexus Personal,QuickTime,Shockwave".

I don't disagree.
You *should* test them with the 'prefs that will be used in the future'.

However, if the 'new in 2014 version of plugincheck' is NOT using enumeration
as I hope will be the case (and seems to be) then an even BETTER test would be
to have
"plugins.enumerable_names" set to "" (empty string)
for the 'test of plugincheck'.


***
I think, from my use of the new Release (Fx 30) that the 'plugincheck service'
is now the 'new in 2014 version of plugincheck'.

This is not ideal as the 'known issues' are now being experienced by a large
number of people in the Mozilla community.
***

Using Release (Fx 30) I get the SAME result on LIVE
https://www.mozilla.org/en-GB/plugincheck/ (in my GB case) with
"plugins.enumerable_names" set to "" (empty string) or
"plugins.enumerable_names" set to "*" [all plugins enumerated]

This is *very* similar to what you can see here:
https://bug1010132.bugzilla.mozilla.org/attachment.cgi?id=8433727

Using Release (Fx 30) today I also have

1. Have 'no "Unknown" plugins reported on' - see bug 965812

2. "Adobe Acrobat NPAPI Plug-in" is Reported as "vulnerable" - WRONG.
    This is being discussed in bug 1020133.
    Now we are seeing new bugs e.g. bug 1023718.

3. Flash 13.0.0.214 as "Up to Date".
    Now WRONG, Adobe have released a new 14.0.0.125 - see bug 1023838


Some Good News:

UA spoofing helps
(see my comment in bug 1010132 comment # 19)

Using Release with

user_pref("general.useragent.override", "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0)
Gecko/20100101 Firefox/29.0.1");

combined with
"plugins.enumerable_names" set to "*"

I get a *very* similar result to this:
https://bug1010132.bugzilla.mozilla.org/attachment.cgi?id=8426517

These settings will give you the 'most accurate result'
That is
"Adobe Acrobat" 11.0.7.79 "Up to Date" - correct
and you still have the "Unknown" plugins.

The 'result for Flash' is wrong
because the Plugin database needs updating (see bug 1023838).


DJ-Leith
(In reply to DJ-Leith from comment #143)
> These settings will give you the 'most accurate result'
> That is
> "Adobe Acrobat" 11.0.7.79 "Up to Date" - correct
> and you still have the "Unknown" plugins.
> 
> The 'result for Flash' is wrong
> because the Plugin database needs updating (see bug 1023838).
> 
> 
> DJ-Leith

Thanks for the info DJ. I am going to bump the version in the new plugincheck so it no longer runs the new code in release 30. Also, the DB has been updated with the latest release info for Flash.
(In reply to Schalk Neethling [:espressive] from comment #144)
> Thanks for the info DJ. I am going to bump the version in the new plugincheck so it no longer
> runs the new code in release 30. Also, the DB has been updated with the latest release info
> for Flash.

Has all of this happened?

Flash

DJ-Leith on 2014-06-11 at 12:51:31 PDT in bug 1023838 comment # 5 said:
> Thanks Schalk,
> 
> Flash 13.0.0.214 now correctly reported as "vulnerable" on Fx 30 and Aurora, on Windows 7.
> 
> DJ-Leith
Those tests were done on LIVE on 2014-06-11 about 11:50 PDT 
I have, since then, updated Flash to 14.0.0.125

Today, on all six tests below, Flash 14.0.0.125 is reported as "Up to Date"
So, AFAIK Flash is OK.


Adobe Acrobat 11.0.7.79 - the 'correct result' should be "Up to Date"

Tests done on 2014-06-12 at both STAGE and LIVE with 3 browsers:

STAGE
https://www.allizom.org/en-US/plugincheck/

LIVE
https://www.mozilla.org/en-GB/plugincheck/ (in my GB case)

Fx 30 - with NO enumeration - "plugins.enumerable_names" set to "" (empty string)
Adobe Acrobat reported as "vulnerable" - WRONG.

Fx 30 (UA spoof to 29.0.1) - "plugins.enumerable_names" set to "*" [all plugins enumerated]
Adobe Acrobat reported as "Up to Date" - good.

Fx 31.0a2 - with NO enumeration - "plugins.enumerable_names" set to "" (empty string)
Adobe Acrobat reported as "vulnerable" - WRONG.

Bugs

Main Acrobat Bug is:
Bug 1020133 "Improve Adobe Acrobat plugin reporting"

Main Acrobat bug - since the Release of Fx 30 is:
Bug 1023718
"Plugin checker for newly installed FF 30.0 shows Adobe Acrobat plugin "vulnerable"
but update button just reloads plugin checker"

Possible Duplicates of bug 1023718 include:

Bug 1023946 "Plugincheck Redirect" 

Bug 1023653 "Adobe Acrobat plugin on Windows detected as Mac, can't update" 
Schalk, bug 1023653 comment # 4 has useful data from the JSON list.

Bug 1024323 "[plugincheck] Adobe Acrobat NPAPI Plug-in update link leads nowhere"


Bug 1023835
"Plugin Check reports Java 7 Update 55 plugin as up-to-date when
Java 7 Update 60 is the latest version"

For this Java Bug, I recommend - after your review - that the Plugin Database is updated.

DJ-Leith
(In reply to DJ-Leith from comment #145)
> (In reply to Schalk Neethling [:espressive] from comment #144)
> > Thanks for the info DJ. I am going to bump the version in the new plugincheck so it no longer
> > runs the new code in release 30. Also, the DB has been updated with the latest release info
> > for Flash.
> 
> Has all of this happened?

Nope, the pull request is still waiting to be merged:
https://github.com/mozilla/bedrock/pull/2095

It will definitely happen a little later today.
(In reply to DJ-Leith from comment #145)
> Bug 1023835
> "Plugin Check reports Java 7 Update 55 plugin as up-to-date when
> Java 7 Update 60 is the latest version"
> 
> For this Java Bug, I recommend - after your review - that the Plugin
> Database is updated.
> 
> DJ-Leith

See me comment on https://bugzilla.mozilla.org/show_bug.cgi?id=1023835#c4
Status Update on 'the plugincheck service'.

Q. "Is the new plugincheck service ready for use without enumeration?"

A. "Not quite: Schalk Neethling [:espressive] has done a lot of work and has 
produced a very impressive result but there are a few outstanding issues."

Release (Fx 30) is using enumeration for plugincheck.
Beta, Aurora and Nightly (Fx 31+) are NOT using ANY enumeration for plugincheck.
Fx 31 is due for Release on 2014-07-22.

In this comment I will reference other bugs - to help readers.
If you know all of this, skip to the "To Do" section.


***
Short History.
***

2010 May
  Scope see
  "Plugin Check for Everyone"
  by Johnathan Nightingale
  11 May 2010
  http://blog.mozilla.org/security/2010/05/11/plugin-check-for-everyone/

  The 'plugincheck service' relies on a database.

2010 August
  See bug 573553 "Display 'unknown plugin' message for plugins not in db"
  which was "Verified FIXED." on 2010-08-02.
  A very useful addition (which will be regressed when ALL users of
  plugincheck are NOT using enumeration - see bug 965812 which has text
  and pictures). 

2012 September
  Chris Peterson (:cpeterson) begins working on
  bug 757726 "disallow enumeration of navigator.plugins"
    It was documented (bug 757726 comment #3) that this would break the
    plugincheck service and it was always envisaged that the plugincheck
    service would need to NOT use enumeration before the ability of
    web sites to 'enumerate plugins was switched off'.

    Key point:
    in bug 757726 comment #105
    Chris Peterson (:cpeterson) wrote:
>   * Renamed "plugin.enumerableNames" pref to "plugins.enumerable_names"
>   * Added special pref value '*' to disable all plugin hiding

    In 28+ the default for the preference "plugins.enumerable_names"
    is "Java,Nexus Personal,QuickTime,Shockwave".
      Since bug 952602, the RELEASE version has had "plugins.enumerable_names"
      set to "*". That is 'allow a web site to do enumeration of all plugins'.

2013 November
  bug 757726 now in Nightly (Fx 28).
  bug 938885 "Fix plugincheck to not use plugin enumeration" is opened.
  Schalk starts working on this.

2013 December
  Plugincheck is now broken in Aurora.
    I see this issue for the first time.
        In bug 952914 Chris Peterson and I discuss interim measures
        including how best to communicate changes.
        
        Bug 952602, opened on 2013-12-20, is to allow 'enumeration of all plugins'
        in late beta so that
        RELEASE has the setting "plugins.enumerable_names" set to "*".

    Plan now includes using a JSON list, instead of enumeration,
    as part of the 'plugincheck service'.

2014 January
  *This* bug (bug 956905) "Publish JSON list of all plugins for use on /plugincheck" is opened. 
  There is lots of work done to get the 'plugincheck service' to work
  using the JSON list.

2014-05-12
  The JSON list is in production.
  Some of the code, for plugincheck, is automatically 'checked for updates'
  every 15 min (see bug 1000321 "Repo changes for plugindir").
  I don't know how often the JSON list is regenerated or how long
  it takes for changes to data in the 'plugin database' to appear in the
  JSON list.

2014-05-12 - the same day that the JSON list is in production ...  

See - Chris Peterson from comment #139 where he said:
> Schalk: note that plugin enumeration is currently not disabled on any
> Firefox channel (bug 757726 comment 137) until Click-To-Play for all plugins
> is enabled by default. I would like to include Click-To-Play's longer
> whitelist with plugin enumeration.

For the more recent history see comment # 143 (above in this bug).



***
Firefox 30 was RELEASED on 2014-06-10.
***

It was already known (since 2014-05-21) that the 'new plugincheck service', 
that uses the JSON list,
still had issues with the Adobe Reader / Adobe Acrobat plugin:
see bug 1020133 "Improve Adobe Acrobat plugin reporting".

When Firefox 30 was released these issues with Adobe Acrobat plugin were then
seen widely bacause Fx 30, while it was Fx beta, had been using the
'new plugincheck by JSON list' in early June.
Fx 29.0.1 (which was the RELEASE version before 2014-06-10) had been using
the 'current plugincheck (using enumeration)'

Bug 1024435 "Bump version of plugincheck.next to 30" has given us a bit of time.
Since this landed (2014-06-12)
the 'plugincheck service' is using the JSON list for Fx 31+
and enumeration for Fx 30.

IIUC, I think it will be possible to move the version 'to use enumeration'
from Fx 30 to Fx 31 - if we need to (and so Fx 32+, on plugincheck, will be
using the JSON list WITHOUT ANY enumeration).
Fx 31 is due for Release on 2014-07-22.

Main Acrobat bug - since the Release of Fx 30 is:
Bug 1023718
"Plugin checker for newly installed FF 30.0 shows Adobe Acrobat plugin "vulnerable"
but update button just reloads plugin checker"

See: bug 1023718 comment # 10 for a summary of the outcome,
links to other bugs (some are Duplicates of that bug), via them links to SUMO.
Also, links to 'newly reported plugins' (in late May 2014) for inclusion in the
plugin database (and therefore 'extraction from the database and into the JSON list').



***
To Do - before 'plugincheck for RELEASE' uses the JSON list.
***

1. Fix known issues in 'New plugincheck' (using JSON list) which are
not in 'Current plugincheck' (using enumeration).

Bug 1020133 "Improve Adobe Acrobat plugin reporting"


2. Other bugs.  It would be good to fix these so that
they work in the 'New plugincheck' (using JSON list).

First,
ESR versions of plugins e.g.

See comment # 128 (above) for Flash and also
bug 978505 "Mozilla plugincheck says latest Flash Player 11.7 (Extended Support Release) is 
vulnerable and tells me to update"

There are also ESR versions of Adobe Reader.

Treat each 'branch of Java' / 'family of Java' as if it were a separate plugin.

Examples:
Bug 985968 "Mozilla Plugin check page displays Java plugin as vulnerable even if the latest 
Java 7 version is installed".
This happened when Java 8 was released, in March 2014 (bug 985056),
and Java 7.xx was still OK.
It is now fixed but can we learn for it?


Second,
bug 965812 "RFE an "About plugincheck" page, visible from plugincheck".
As plugincheck is available in many languages any wording change will need
localisation and so it will take some time to translate and test the new wording.
This bug has 'screenshots' to illustrate you you can see compared to what you
can NOT see (when plugincheck is only using the JSON list).
This bug is in Schalk's 'To Do List'.


Third,
 Bug 1024625 "Improve plugincheck layout to include outdated and unknown plugins"

 Bug 1017483 "Always expose version number of plugin"

 Bug 968726 "Need better ways for detecting flash version on linux"

 Bug 992583 "plugin check incorrectly identifies linux vlc and gecko-mediaplayer as 
vulnerable"

 Bug 861407 "new plugin checker not working on IE"
    In particular on IE 11.

 Bug 1038685 "Some plugins don't appear in plugincheck website even though they
are installed and are seen in plugins_list.json" 


There are two 'plugin tracking bugs'.
Some of the bugs, just cited, are NOT on these trackers!

Bug 990857 "Tracker for Bugs and Feature Requests PluginCheck.current"
Bug 990856 "Tracker for The New PluginCheck for Firefox 29+"


3. Add plugins, already documented in Bugzilla, to the database
(see bug 1023718 comment # 10 - for the link).


4. Test and QA.
In bug 1010132 comment # 14 Schalk has listed some tests.

My comments on tests:

A.
As the 'new plugincheck service' does NOT use enumeration
a good test includes comparing what you see:

T1. using RELEASE with "plugins.enumerable_names" set to "*" (all plugins are
enumerated at plugincheck)

vs

T2. using Aurora with "plugins.enumerable_names" set to "" (empty string) - NO enumeration

vs

T3 and T4. "about:plugins" (lists ALL the plugins - which should be the same for
both browsers, if they are on a single computer).


B.
Does Schalk need more people and / or more plugins to QA the 'new plugincheck using JSON'?

There may well be other items for the
"To Do - before 'plugincheck for RELEASE' uses the JSON list",
the above are just some that occur to me.

Finally, very pleased to read (in bug 1038649)
where Schalk Neethling said, on 2014-07-15:
> PluginCheck has undergone many evolutions over the last couple of months
> and will be evolving even more over the coming months.  ... ...

DJ-Leith
Attachment #8403231 - Flags: review?(laura)
I am reluctant to comment in a closed bug but I think this is the best place
to make these three main points.

Convention:
I am using double quotes for Direct Quotations; often the bug summary.
I am using single quotes for slang, imprecise language, poorly defined jargon and
other text where I am conscious that there is ambiguity in the meaning of the
wording - as 'scare quotes'.

Please can Chris Peterson and Schalk Neethling comment on
Point 1: the strategic direction of the development of the 'Plugincheck Service'.


***
1. The strategic direction of the development of the 'Plugincheck Service'.
***

The most important bug to land since comment # 148 is:

Bug 793978 "Sort navigator.plugins array to avoid exposing user-identifying plugin file order"
This change is in Fx 34 (due for Release on 2014-12-02).

      This does help with browser fingerprinting.
      https://wiki.mozilla.org/Fingerprinting
      It also, unlike bug 757726 "disallow enumeration of navigator.plugins"
      (see comment # 148 for the history),
      does NOT 'break plugincheck'.
        Now, bug 938885 "Fix plugincheck to not use plugin enumeration"
        might not be needed.


We have come to a 'cross roads' and I think there are 4 possible 'routes to take'. 

1A.  Continue to develop the 'Plugincheck Service',
      by 'using enumeration at the Plugincheck Website'
      and abandoning the 'JSON List' (and any methods that rely on it).
        This was how 'plugincheck worked' until May 2014.

1B.  Continue to develop the 'Plugincheck Service',
      with Release using plugin enumeration and
      Beta, Aurora and Nightly using the 'JSON List'.
        This is how 'plugincheck is working' - since May 2014.
        Each time a 'Fx version', e.g. Fx 31, Fx 32, reaches Release the
        code at the 'Plugincheck Website' is 'bumped on'.
          See bug 1078251 as an example.
      This is a 'transitional phase'.
      The end goal is to STOP enumerating plugins at the 'Plugincheck Website'
      and rely on the 'JSON List' as the ONLY 'communication channel' between
      the 'Plugincheck Website' and the 'Plugincheck Database'.
      The final goal is either "1C" or "1D". 

1C.  The 'Plugincheck Service' does NOT use ANY 'plugin enumeration'.
      The 'JSON List' is the ONLY 'communication channel' between
      the 'Plugincheck Website' and the 'Plugincheck Database'.
        The only 'known plugins' are
        NOT the plugins in the 'Plugincheck Database'
        BUT are the sub-set of those plugins which are in the 'JSON List'.
        The 'detection and testing' of plugins at the 'Plugincheck Website'
        will work even if "plugins.enumerable_names" is set to "" (empty string).
        See comment # 143.

        *** There are NO "unknown" plugins. ***

        This is a regression from the 'Plugincheck Service we have come
        to know and love'.
        Bug 965812 "RFE an "About plugincheck" page, visible from plugincheck"
        would be a blocking bug for "1C".

1D.  Is the same as "1C" except that AFTER the 'evaluation and reporting of
      all plugins that are in the JSON List - at the Plugincheck Website'
      has been completed. Then the 'visiting browser's plugins are enumerated'
      and any that 'have not been tested / evaluated', because they are
      NOT included in the 'current JSON List', are THEN listed as "unknown".


***
Notes on 1A and 1B.
***

The 'plugincheck using enumeration' was developed using 'ideas, infrastructure and
code' from the "Plugin Finder Service" (and later PFS2).
Are there ANY dependencies on PFS or PFS2?

I ask because:

A. We saw in
bug 1084537 "Flash sometimes displayed as up to date whilst vulnerable, on Windows 7"

that the "1A" method still relies on 'dynamic URLs' that include
> https://plugins.mozilla.org/pfs/v2?appID={...  ...
that 'fetch' data from the 'Plugincheck Database',
DEPENDING on the 'detected by enumeration' plugin at the 'Plugincheck Website'.
This data can be 'out of date', i.e. it was "fetched" BEFORE the recent
update of the 'Plugincheck Database'.  There is more information in that bug.
The point is, a WRONG Report was given because 'out of date data' was used
to make the evaluation.

Does the 'creation of the dynamic URLs',
or the use of these 'dynamic URLs' depend on
ANY infrastructure or code that is 'being retired along with the PFS'?

B. see bug 1071161 "Retire PFS web service"

Also,
Justin Dolske [:Dolske] on 2014-09-18 in bug 836415 comment # 16 said:
> I've closed the remaining 62 open bugs in Toolkit :: Plugin Finder Service,
> and filed bug 1069487 to inactivate that component in bugzilla.

Justin Dolske [:Dolske] on 2014-09-26 in bug 573834 comment # 9 said: 

> Bug 836415 has now removed the Plugin Finder Service (PFS) from Firefox.
> As a result, I'm closing all the remaining PFS bugs.
> 
> If you're getting this bugmail for an ancient PFS bug, the basic summary of the
> world today is:
> 
> * NPAPI plugins are a dying technology
> * PFS was already restricted to assisting with only the 4 most common plugins
> * Sites commonly provide their own UI for install a required plugin
> * Mozilla is generally focusing on  improving the web platform so that proprietary 
>   plugins are not required.
> 
> (Note that "plugins" are a completely separate from "browser extensions", such at
> those found on addons.mozilla.org. The latter are not going anywhere, and are not
> impacted by the removal of PFS.)


***
Notes on "1C" and "1D"
***

In addition to comment # 143 - please re-read.
I have continued to test plugincheck with an Aurora profile that has
"plugins.enumerable_names" is set to "" (empty string).

Until bug 1020133 comment # 85 I could always test 'known plugins'
(i.e. those that are in the JSON List).
  The results may not have been correct and some 'plugins that are in the
  JSON List' are not detected (see bug 1038685 "Some plugins don't appear in
  plugincheck website even though they are installed and are seen in
  plugins_list.json" 
  and point 3 - another list of bugs, below).
Now, I have to 'allow enumeration' at the 'live plugincheck' to get
ANY 'report', even when using Aurora.



******

My choice would be
"1D" or "1A" (but not "1C").

FAO
Chris Peterson
Your input as to the strategic direction, in light of bug 793978, would be very helpful.
Are you aware of any dependency on PFS or PFS2?
Comments on other points would, of course, also be welcome.

Do you think that
https://wiki.mozilla.org/Fingerprinting
needs an update?


FAO
Schalk Neethling
You have done more work on plugincheck, in recent months, than anybody at Mozilla.
How do you see the way forward?



***
2.  Some readers may be thinking: 'I thought plugins were depreciated'.
Implication: 'Why bother maintaining, and putting resources into,
the Plugincheck Service'. 
***

My short response is to first ask: How many years ago was it that you FIRST
heard Microsoft say, in effect, 'Windows XP is depreciated'?

Plugins were invented to 'do things the browser can't do'.
As browsers gain some of the functions that 'were done by plugins'
the issue of 'out of date plugins' and 'vulnerabilities caused by old plugins'
does NOT disapear.

(from bug 1020133 comment # 0 - about Adobe Reader)
> Even if a user often uses "PDF.js", in Firefox, to read PDF files they might
> still have the plugins installed on their computer.

HTML5 has not 'eliminated Flash from the web'.

Telemetry will show that the 'Plugincheck Service' is still very popular.  


***
3.  Bugs
***

3.1 If "1C" is the goal then bug 965812 blocks
'the future of the Plugincheck Service' because the reports of "unknown" plugins
are so useful.  Work on bug 965812 should start now as it will take time to
translate the 'Plugincheck Website'. 
(from comment # 148)
> bug 965812 "RFE an "About plugincheck" page, visible from plugincheck".
> As plugincheck is available in many languages any wording change will need
> localisation and so it will take some time to translate and test the new wording.
> This bug has 'screenshots' to illustrate you you can see compared to what you
> can NOT see (when plugincheck is only using the JSON list).


3.2 Other bugs

Next is a list of important Plugincheck bugs,
in *addition* to those listed in comment # 148.

All of these should be assessed and prioritised in light of 
> 1. The strategic direction of the development of the 'Plugincheck Service'.
(above in this comment).

  Bug 1089012 "PlugIn Check for VideoLan correctly reports current version for the
  NPAPI browser plugin version 2.1.3, but database incorrectly reports it as outdated"

  See also, from bug 1097853 comment # 1,
>   The fact that VLC use a different 'File Version' in the metadata in their plugin
>   vs the rest of the software, has been a contributory factor in the
>   Plugincheck Database having "2.1.5" recorded in the Plugincheck Database ...

  Bug 1084537 "Flash sometimes displayed as up to date whilst vulnerable, on Windows 7"

  Bug 1105483 "Add a 'Generated' Date and Time stamp to the top of the 'Plugincheck JSON List' "

  Bug 1102198 "Always show unknown plugins"

  Bug 1060409 "Outdated plugins status shows as vulnerable"

  Bug 1060990 "Using the "Update Now" Action in Plugin Check doesn't have the desired effect"

  Bug 1054636 "Plugin Check requires JavaScript, but does not tell the visitor about that"

  Bug 1044053 ""Checking with Mozilla on the status of your plugins" missing from plugincheck.lang"

  Bug 1054280 "Ensure consistent button colors across browsers"

DJ-Leith
Flags: needinfo?(schalk.neethling.bugs)
Flags: needinfo?(cpeterson)
(In reply to DJ-Leith from comment #149)
> I am reluctant to comment in a closed bug but I think this is the best place
> to make these three main points.

Mozilla's dev-tech-plugins mailing list (or mozilla.dev.tech.plugins newsgroup) is probably the best place to discuss Mozilla's plugin plans:

https://lists.mozilla.org/listinfo/dev-tech-plugins


> My choice would be
> "1D" or "1A" (but not "1C").

1D and 1A should produce the same results. Checking both the JSON list and enumerating navigator.plugins in 1D seems redundant, though future-proof if navigator.plugins enumeration is eventually restricted.

We shouldn't treat Nightly, Aurora, or Beta channels any different than Release because we don't want to hide available information related to plugin security.


> Chris Peterson
> Your input as to the strategic direction, in light of bug 793978, would be
> very helpful.
> Are you aware of any dependency on PFS or PFS2?

I am not familiar with the current Plugin Check backend.


> 2.  Some readers may be thinking: 'I thought plugins were depreciated'.
> Implication: 'Why bother maintaining, and putting resources into,
> the Plugincheck Service'. 

Google plans to remove NPAPI plugin support from Chrome in 2015. Mozilla recognizes that plugins are part of the web ecosystem and has no stated plans to remove NPAPI support. Thus, maintaining the Plugin Check service is important to keep Firefox users secure.
Flags: needinfo?(cpeterson)
I am just giving a general status update here, and will copy this over to any other relevant bugs where a needinfo request has been logged for me.

For the past quarter i.e. 1024-Q4, plugincheck has not been on my radar in any way, shape or form as I was moved to work on another project and 100% of my time was assigned to it. I have kept my eye on bugs etc. that has come an gone and have had the service in the back of my mind though and, from what I have seen this service is still very important to users and Mozilla for a variety of reasons which I will not go into here.

With all of that said, during this time there was also some out reach done to other groups within in Mozilla to take over part, or all, responsibility for plugincheck but, as of right now, there has been no takers.

AS I mentioned though, I completely understand and appreciate the importance of this service and, I also acknowledge that in it's recent, and current state, it does not provide the 'answers' users need but, I am moving pluginchck back as a top priority for myself in Q1 of 2015 and I am currently in the progress of planning for the year in general and then for Q1 specifically.

I want to open this up to the user base to get your input on what is important and the biggest pain points but, have not decided how I will do this.

Once all of these ducks are in a row, I will post a message to either a specific bug, to yammer or both. Please except my apologies for the steady decline of this service, thanks for your patience and continued feedback and I am certain that plugincheck is going to turn the corner in a positive way in 2015.
Flags: needinfo?(schalk.neethling.bugs)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: