Closed Bug 1101613 Opened 10 years ago Closed 10 years ago

PluginCheck Database Clearance

Categories

(Plugin Check Graveyard :: Database, defect)

Product:
Plugin Check Graveyard
Component:
Database
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: espressive, Assigned: espressive)

References

Details

Attachments

(1 file)

Fx-33-1-1-Google-Earth-NOW-UNKNOWN-2014-11-25.png
147.09 KB, image/png
Details 
Having gone over the plugin check database and looked over the stack of plugins that are listed in the database, I realized that other than Flash, Reader, Java, Silverlight and Quicktime, no other plugins, except for maybe one or two, have seen an update in the last 6 months.

For that matter some of these have not been updated since 2011. With that, I went through all of the plugins and have put together a list of plugins that will be dropped from the database (see below).

If the vendors want these plugins to be included in the database again, we will be more than willing, as long as the vendors take responsibility for keeping us notified in a timely manner of updates to their plugins.

Should a plugin not be updated in a 6 month cycle, the plugin will be removed.

This does mean that unknown plugins will be listed and that list will be longer but, from user feedback, I believe even just listing these is very helpful to end users and, I believe, it is better to mark a plugin as unknown and let the user research further than marking something as up to date or vulnerable, when the database is simply outdated.

Here that follows the list:

ActiveGS
Adobe Shockwave
Aliedit
Alipay Security Control
BrowserPlus
BrowserPlus (from Yahoo)
Citrix online deployment plugin
Citrix Receiver plugin
DevalVR
DivX Web Player
Google Earth Plugin
Google Talk
Google Talk Video Accel
IcedTea Java
InstantAction.com Game Launcher
iPhotoPhotocast
MetaStream 3
Microsoft DRM
Microsoft Window Media
QuakeLive
RealJukebox
RealNetworks Chrome Background extension
Realplayer version	plugin
RealPlayer HTML5Shim
Totem
VidXWebPlayer
VLC
Wacom
Windows Media Components
Windows Media Player DLL

This will be done on stage and if there are no complaints after a 2 week period, these will be dropped from production as well.
Good to see that you are still able to work on Plugincheck.

(In reply to Schalk Neethling [:espressive] from comment #0)
> This does mean that unknown plugins will be listed and that list will be
> longer but, from user feedback, I believe even just listing these is very
> helpful to end users and, I believe, it is better to mark a plugin as unknown
> and let the user research further than marking something as up to date or
> vulnerable, when the database is simply outdated.

I agree with all of this: the "unknown" report is very useful.

> vendors take responsibility for keeping us notified in a timely manner of
> updates to their plugins.
A report based on 'out of date data', because the Plugincheck Database has
not been updated, is a 'false sense of security' and should be avoided.
I agree that vendors *should* tell Mozilla.

See also bug 850992 - detect "newer" versions of 'known plugins', as an alert,
to prompt 'those who maintain the Plugincheck Database' that a 'new version
has been seen'.

On a related topic, 
see bug 1084537 - where the Plugincheck Database WAS updated BUT,
due to - I speculate - some 'infrastructure issue', Flash was reported as
"Up to Date" for three days AFTER the Plugincheck Database had been updated!

> have seen an update in the last 6 months.
One that 'went wrong', because VLC have have different metadata in the PLUGIN file
vs the 'rest of the program files' is bug 1089012.
AFAIK this VLC bug has not been fixed.

DJ-Leith
This has now also been done on production. The one exception is that VLC is still in the database for now and has not been dropped.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
"Fx-33-1-1-Google-Earth-NOW-UNKNOWN-2014-11-25.png"

Schalk THREE points:

1. Google Earth Plugin.

Since this change I am no longer getting any report on "Google Earth Plugin".

From comment # 0
> Google Earth Plugin
My reading was that the Google Earth Plugin was
'still in the cleaned up Plugincheck Database' so I was expecting it to be
'tested and reported on' and not "unknown".


For a Recent (2014-10-21) Plugincheck showing "Google Earth Plugin"
see
https://bug1084537.bugzilla.mozilla.org/attachment.cgi?id=8509897

Minor point, compare the two screenshots and you will see that
  "Adobe Reader" has lost the 'Reader logo'.
  One way to 'guess what this is supposed to convey is':
  use the 'lego brick logo' for 'we don't have a logo for this plugin'.
  Recently there was a Reader logo.


2. Have to enumerate plugins to get ANY result.

Previously, since May 2014, I have deliberately tested
'new Plugincheck - uses the JSON List' with 
"plugins.enumerable_names" set to "" (empty string) - NO enumeration.
  ALL Plugins, in the JSON List, were reported.
  There were NO "unknown" reports.
As you know, I think the "unknown" report is very useful.

Now, since bug 1020133 comment # 85
I have had to have set
"plugins.enumerable_names" to "*" (all plugins are enumerated at Plugincheck)
to get ANY version of Firefox (I have spoofed UAs from Fx 31 through to Fx 36) to
'see a result' on LIVE.

So, to see the screenshot
"Fx-33-1-1-Google-Earth-NOW-UNKNOWN-2014-11-25.png", attached to this comment,
I had to set "plugins.enumerable_names" to "*".

If I set "plugins.enumerable_names" to "shockwave" only Flash is reported
(expected if 'enumeration is required at Plugincheck').

This was the point I was trying to make in bug 1102198 comment # 3:
the attached screenshot illustrates that comment too.


3. VLC
From comment # 1
> One that 'went wrong', because VLC have have different metadata in the PLUGIN file
> vs the 'rest of the program files' is bug 1089012.
> AFAIK this VLC bug has not been fixed.

Is VLC fixed?  There is no recent comment, from you, in bug 1089012.

DJ-Leith
Flags: needinfo?(schalk.neethling.bugs)
(In reply to DJ-Leith from comment #3)
> Created attachment 8528636 [details]
> Fx-33-1-1-Google-Earth-NOW-UNKNOWN-2014-11-25.png
> 
> "Fx-33-1-1-Google-Earth-NOW-UNKNOWN-2014-11-25.png"
> 
> Schalk THREE points:
> 
> 1. Google Earth Plugin.
> 
> Since this change I am no longer getting any report on "Google Earth Plugin".
> 
> From comment # 0
> > Google Earth Plugin
> My reading was that the Google Earth Plugin was
> 'still in the cleaned up Plugincheck Database' so I was expecting it to be
> 'tested and reported on' and not "unknown".
> 

No, the Google Earth plugin was marked for removal as it has not been updated in a long time, definitely greater than 6 months.

> 
> For a Recent (2014-10-21) Plugincheck showing "Google Earth Plugin"
> see
> https://bug1084537.bugzilla.mozilla.org/attachment.cgi?id=8509897
> 
> Minor point, compare the two screenshots and you will see that
>   "Adobe Reader" has lost the 'Reader logo'

This is a small bug that I actually have fixed but did not merge into Bedrock. Will open a PR to fix that.

> 
> 
> 2. Have to enumerate plugins to get ANY result.
> 
> Previously, since May 2014, I have deliberately tested
> 'new Plugincheck - uses the JSON List' with 
> "plugins.enumerable_names" set to "" (empty string) - NO enumeration.

This is a strange one as the 'new' plugincheck code still only uses mimes and not navigator.plugins

This code should run in Fx35+ so, I will have to look into that.

> 
> 
> 3. VLC
> From comment # 1
> > One that 'went wrong', because VLC have have different metadata in the PLUGIN file
> > vs the 'rest of the program files' is bug 1089012.
> > AFAIK this VLC bug has not been fixed.
> 
> Is VLC fixed?  There is no recent comment, from you, in bug 1089012.

I did update the database but, I am still working on this as from my last testing, VLC now seems to be shown as unknown.

Thanks again for your detailed reports.
Flags: needinfo?(schalk.neethling.bugs)
Blocks: 1105312
(In reply to DJ-Leith from comment #3)
> Minor point, compare the two screenshots and you will see that
>   "Adobe Reader" has lost the 'Reader logo'.
>   One way to 'guess what this is supposed to convey is':
>   use the 'lego brick logo' for 'we don't have a logo for this plugin'.
>   Recently there was a Reader logo.
> 

PR opened https://github.com/mozilla/bedrock/pull/2547
Schalk,

Another five points.

> Thanks again for your detailed reports.
You are welcome.

1.  I've needinfoed you and Chris Peterson on bug 956905.
Chris has made some very helpful comments there.


2.  Google Earth Plugin.

(In reply to Schalk Neethling from comment #4)
> 
> (In reply to DJ-Leith from comment #3)
> > Created attachment 8528636 [details]
> > Fx-33-1-1-Google-Earth-NOW-UNKNOWN-2014-11-25.png
> > 
> > "Fx-33-1-1-Google-Earth-NOW-UNKNOWN-2014-11-25.png"
> > 
> > Schalk THREE points:
> > 
> > 1. Google Earth Plugin.
> > 
> > Since this change I am no longer getting any report on "Google Earth Plugin".
> > 
> > From comment # 0
> > > Google Earth Plugin
> > My reading was that the Google Earth Plugin was
> > 'still in the cleaned up Plugincheck Database' so I was expecting it to be
> > 'tested and reported on' and not "unknown".
> > 
> 
> No, the Google Earth plugin was marked for removal as it has not been updated
> in a long time, definitely greater than 6 months.

Indeed, the actual Google Earth plugin has not been updated since it was released
in November 2013 but 7.1.2.2041 is still the latest version.
AFAIK it is not vulnerable.

Google are moving away from NPAPI plugins in Chrome so they may well
not have updated it since November 2013.

  So, are you having a 'new policy': if the Database has not been updated in the
  last six months (in this case because the Database has the latest version)
  the plugin will 'become unknown'?

  It is good to 'clean the data'; less good to throw away useful data.

I think "Up to Date" is the correct result for Google Earth Plugin 7.1.2.2041

3.  Using the JSON List
> > 2. Have to enumerate plugins to get ANY result.
> > 
> > Previously, since May 2014, I have deliberately tested
> > 'new Plugincheck - uses the JSON List' with 
> > "plugins.enumerable_names" set to "" (empty string) - NO enumeration.
> 
> This is a strange one as the 'new' plugincheck code still only uses mimes
> and not navigator.plugins
> 
> This code should run in Fx35+ so, I will have to look into that.

STR

1. Use Aurora

2. about:config search for plugins and change
"plugins.enumerable_names" to "" (empty string)

3. browse to "mozilla.org/plugincheck"
you should be redirected to
https://www.mozilla.org/en-GB/plugincheck/
in my GB case.

I see 'no result', i.e. no "unknown"
and no plugins that were being tested from the 'JSON List'.

Other methods:

at step 3 use "about:addons", choose the 'Plugins Tab' then the
"Check to see if your plugins are up to date" link

This should open
https://www.mozilla.org/en-GB/plugincheck/?utm_source=firefox-browser&utm_medium=firefox-browser&utm_campaign=plugincheck-update
in a 'New Tab'.

Again, 'no result'.
To prove that enumeration is being used change
"plugins.enumerable_names" to "Shockwave" [Capital S - case matters here]
and ONLY Flash is reported, <== good news here, version	"15.0.0.223" is
                                correctly reported as "vulnerable".
                                  So, bug 1105307 to update Flash is working.
                                  First saw that, using Release Fx 33.1.1,
                                  about 3 hours ago.
                                  Kept Flash "15.0.0.223" for testing (as in bug 1084537)
no "unknown" [expected],
no 'other plugins from JSON List' [unexpected - not sure what to expect if I'm honest]

4. VLC
> I did update the database but, I am still working on this as from my last
> testing, VLC now seems to be shown as unknown.
Does the Database have 2.1.3 (correct for the PLUGIN metadata - the 'main version' is 2.1.5).
See bug 1097853.

5. thanks for the PR in comment # 5.

DJ-Leith
1 of 2

Schalk, Carsten and all,

I think you need to revert this ASAP.

Please restore the LIVE Database, from backup, and then make the 'recent planned
changes to the LIVE Plugincheck Database', that you made before i.e. redo them
(see bugs in the next comment).

Schalk Neethling on 2014-11-19 08:20:43 PST  in comment # 0 said:
> Having gone over the plugin check database and looked over the stack of
> plugins that are listed in the database, I realized that other than Flash,
> Reader, Java, Silverlight and Quicktime, no other plugins, except for maybe
> one or two, have seen an update in the last 6 months.
<snip>
> This will be done on stage and if there are no complaints after a 2 week
> period, these will be dropped from production as well.

Yet, less than 5 hours later I was reporting changes to LIVE!

DJ-Leith on 2014-11-19 at 12:35:21 PST in comment # 1 said:
> Good to see that ...

Questions:

1.  What is the URL for "stage" website? (in this case)
In the past there has been a "stage" at allizom.
I did NOT test "stage"; I did report 'changes seen at the LIVE Plugincheck Website'.

2.  Where was the Database for the "stage"?
Was this a separate 'Stage Plugincheck Database'?
Was "stage" using the LIVE Plugincheck Database?

More evidence that the LIVE Plugincheck Database has been changed includes:

A.
Schalk Neethling on 2014-11-24 at 23:53:27 PST in comment # 2 said:
> This has now also been done on production.
So 5 days (not two weeks) after comment # 0.

B.
My comment # 6 (2014-11-26 16:46:52 PST) where I reported
> Again, 'no result'.
> To prove that enumeration is being used change
> "plugins.enumerable_names" to "Shockwave" [Capital S - case matters here]
> and ONLY Flash is reported, <== good news here, version "15.0.0.223" is
>                                 correctly reported as "vulnerable".
>                                   So, bug 1105307 to update Flash is working.
>                                   First saw that, using Release Fx 33.1.1,
>                                   about 3 hours ago.
>                                   Kept Flash "15.0.0.223" for testing (as in bug 1084537)
> no "unknown" [expected],
> no 'other plugins from JSON List' [unexpected - not sure what to expect if I'm honest] 

My point is, "bug 1105307 to update Flash is working." was done
by Carsten Book on 2014-11-26 at 07:36:12 PST, updating the LIVE 'Plugincheck Database'
(not the "stage" Database).
Both my 'Aurora test' (above) and my 'real test using Release (Fx 33.1.1)' were done
on the LIVE website and, by definition, were using the LIVE Plugincheck Database.

C. Look at the 'JSON List'; before and after.

https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8487601
In this example, from 2014-09-10, there are 5,428 lines in the 'JSON List'.

On 2014-11-14, in bug 1084537 comment # 7
> In the 'new plugincheck which uses the JSON list':
> https://plugins.mozilla.org/en-us/plugins_list.json
> which is 5,750 lines of data (including 8 lines of Scratchpad comment)
> there are no "fetched" dates.

The 'JSON List' was a little larger on 2014-11-14 than in was 2 months before.

Today, 2014-11-27, the 'JSON List' is 3,404 lines (including 8 lines of Scratchpad comment).
That is a lot of data that has been removed from the LIVE 'Plugincheck Database'.

This 'now very short JSON List' may also account for the fact that
I can no longer get 'results using the JSON List' as in comment # 6
(first reported in comment # 3).


***
How did this happen?
***

I don't know but I have two ideas.

A. the "stage" website uses the LIVE Plugincheck Database, and the changes were made
to the LIVE Database.

B. see bug 701349 "plugins.mozilla.org stage and production syncronisation"

I first saw this bug in September 2014, and I was surprised.
I read it again on 2014-11-26 as I was reviewing bugs for bug 956905 comment # 149
but I did not include it: I was surprised again.
Reading it again today I'm wondering if this might be the cause.

In bug 701349 comment # 0, Carsten Book said:
> It would be very cool to have a synchronization (or something like this) button to
> copy changes from stage to production.
> 
> This would avoid the chance of creating a copy&paste error when you copy something
> from stage to production.

NOTE: "from stage to production".

In bug 701349 comment # 1, Schalk Neethling said:
> We have weekly replication of the database from production to stage now ...
So, this is the 'opposite direction'!?

Schalk, did you mean to say "from stage to production"?

If you did, and if indeed the direction IS "from stage to production",
then this could answer the question: how did a two week trial at the
stage Database get to the LIVE Database in less than 5 hours?



More on 'where is "stage"'?

Bug 1020133 comment # 64 has a link to a bug that I can no longer read.
I speculate that it has been made Security, or Mozilla only.
IIRC it did say 'something along the lines of, where is the infrastructure,
backup Database etc' for a 'stage environment'.
If you work for Mozilla you may have access and it may illuminate this situation.

I don't know where 'stage for Plugincheck Testing' is at the moment.
I don't know who, or how many, testers you have for stage.
I would be happy to test at stage, but I only have a very small number of plugins.
It is very difficult to have 'old vulnerable plugins' for testing.

I think that 
http://ossreleasefeed.github.io/Perfidies-of-the-Web/
is "DEV" (not "stage")
See bug 1020133 comment # 65

I am assuming a three level,
DEV --> STAGE --> LIVE / PRODUCTION type of environment.

With "STAGE" being an area where MANY can test
while "DEV" is just for a very small group (could be just Schalk) have access.

DJ-Leith

continued ...
2 of 2

Schalk, Carsten and all,

I think you need to revert this ASAP.

Please restore the LIVE Database, from backup, and then make the 'recent planned
changes to the LIVE Plugincheck Database', that you made before (see bugs below).

In my opinion the 'Plugincheck Database' is a very valuable resource.
It has taken years to gather the data.


Assumption

Recent changes to the LIVE Plugincheck Database are documented in Bugzilla.


Plan

1. document, from Bugzilla, all the RECENT changes to the Plugincheck Database.
2. check other sources (e.g. Security bugs, Mozilla only bugs).

3. use a recent BACKUP (before the work in this bug was started - before 2014-11-19)
   to replace the LIVE Database.

4. redo the changes documented in 1 and 2 to get the LIVE Database back.

5. consider if ANY plugin data should be removed.

Here is my list of bugs.
Please review and add any others I have missed.

***
Flash
***
Bug 1083170 "October Flash updates" 2014-10-15 07:06:44 PDT 
Bug 1087185 "Update plugincheck for flash player 15.0.0.189" 2014-10-22
(I think the Database was updated, ONCE, on 2014-10-15 07:06:44 PDT
and the second report was because of bug 1084537)
  However, if there was a '2nd update' could this account for the issues in
  bug 1084537 "Flash sometimes displayed as up to date whilst vulnerable, on Windows 7"?

    In bug 1105307 (see below) 
    Carsten Book said:
    "plugincheck need to be updated as well. will take this bug"
      Carsten, you said "as well": do you do 'two things' when there
      is a 'new Flash Plugin'?
        Is one of them 'Update the Plugincheck Database' and
        ANOTHER something to do with the 'dynamic URLs'
>       https://plugins.mozilla.org/pfs/v2?appID={...  ...
        I referred to
        in bug 1084537 and in bug 956905 comment # 149
        and in point 5 - below?

Bug 1097659 "Adobe update for Flash Player 15.0.0.223" 2014-11-12 06:15:02 PST 

Bug 1105307
"update flash for http://helpx.adobe.com/security/products/flash-player/apsb14-26.html"
2014-11-26 07:36:12 PST 
For Flash Player 15.0.0.239


***
VLC
***
Bug 1080606 "Update VLC plugin to 2.1.5"
Schalk Neethling [:espressive] 2014-10-17 11:03:37 PDT
> Plugin updated on production database.

But, see Bug 1097853 "VLC plugin is 2.1.3, while the player is 2.1.5 one marked at vulnerable"
which links to
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".

The latter bug has all the facts.
The best thing would be to make the 'latest VLC' version "2.1.3".


***
Example
***
So, for example, if you use the BACKUP from 2014-11-01 (1st November)
you should find Flash was "15.0.0.189", you can update it to
15.0.0.223 and then
15.0.0.239

VLC should be updated or corrected to "2.1.3".


***
5. consider if ANY plugin data should be removed.
***

Carsten,
in your experience has ANY data ever been removed from the Plugincheck Database?
If "yes", why and how.


Schalk,
why do you want to remove ANY data from the Plugincheck Database?

As I see it, you might want to exclude from the 'communication channel'
to the 'Plugincheck Website' (e.g. the 'JSON List' or
e.g. the 'dynamic URLs'
> 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'.

some plugins that have doubtful data.

However, I would caution from actually removing any DATA from the
'Plugincheck Database'.

The first time I read comment # 0
I did not notice the "dropped", as in "list of plugins that will be dropped",
and I then thought the list was the opposite: "kept" (list of kept).
My poor reading.

I still agree with what I said in comment # 1:
> (In reply to Schalk Neethling [:espressive] from comment #0)
> > This does mean that unknown plugins will be listed and that list will be
> > longer but, from user feedback, I believe even just listing these is very
> > helpful to end users and, I believe, it is better to mark a plugin as unknown
> > and let the user research further than marking something as up to date or
> > vulnerable, when the database is simply outdated.
> 
> I agree with all of this: the "unknown" report is very useful.
and with the thrust of your proposal: in my words 'do not assume old data is correct'.

Consider that in bug 956905 comment # 75
you carefully had assembled 37 plugins for the 'JSON List'.
I would keep all of those.

Now, your list in comment # 0.

You may be too busy to research if the 'Plugincheck Database' has the
latest version.  I have told you about "Google Earth Plugin".

Consider asking on http://forums.mozillazine.org
for some research help.
Ask the community to confirm
A.  The 'latest version'
B.  The download URL
C.  The 'vulnerability URL'
for each of the plugins where you doubt that the Plugincheck Database has
up to date data.

You might also have other sources of help e.g. at SUMO.
You may well find that some plugins are out of date.

DJ-Leith
Blocks: 1105947
I am not going to go into to much detail right now, but will add more in future. One thing I would ask is that we not use random bugs as a catch all for everything wrong with plugin check, please break these into their own bugs.

This makes working on, discussing and finally resolving items much easier to plan and manage. In terms of the database, I will much rather work on the bugs that has arisen from this change than reverting to the old database that for the most part contains ~20 plugins that are between 3 - 4 years out of date and another ~10 that is at least 7+ months out of date.

The core 6 - 7 that remain, have all been updated in the last 6 months and we have decent communication with the plugin vendors and/or community in terms of new releases. There simply is no resources to continually track and research the status of plugins.

This is not ideal, I agree but, it is the reality that we need to work with until things change.

With that, I would like to thank everyone for their input and feedback. I really *do* appreciate it. At this, I believe we need to gather the list of topics in a meta bug [https://bugzilla.mozilla.org/show_bug.cgi?id=1105947], prioritise them and then move forward from there.
Please reopen this bug so that users can find it.

1. We are now getting reports of users noticing this.

See bug 1106166.

Like the case of "Google Earth Plugin" (comment # 3),
the data for "Adobe Shockwave for Director" was good data:
evidence in bug 1106166.

2. Reviewing all of this bug, I now wish to correct comment # 7.

See where I said:

Schalk Neethling on 2014-11-19 08:20:43 PST in comment # 0 said:
> Having gone over the plugin check database and looked over the stack of
> plugins that are listed in the database, I realized that other than Flash,
> Reader, Java, Silverlight and Quicktime, no other plugins, except for maybe
> one or two, have seen an update in the last 6 months.
<snip>
> This will be done on stage and if there are no complaints after a 2 week
> period, these will be dropped from production as well.

I think the first evidence of the changes being on LIVE is comment # 2;
which was made 2014-11-24 23:53:27 PST.

So, on LIVE in 5 days (not two weeks).
The changes might have been on LIVE sooner but I can't prove that.


3. meta bug
(In reply to Schalk Neethling [:espressive] from comment #9)
> I believe we need to gather the list of topics in a meta bug
> [https://bugzilla.mozilla.org/show_bug.cgi?id=1105947],
> prioritise them and then move forward from there.

I think it best if you, Schalk, review the bugs I have put forward for
your attention rather than I add them to the meta bug.

In bug 956905 comment # 148, see the To Do section:
> ***
> To Do - before 'plugincheck for RELEASE' uses the JSON list.
> ***

Where I have listed 12 bugs (two of the 12 are meta bugs).

In bug 956905 comment # 149, see
> 3.2 Other bugs
> 
> Next is a list of important Plugincheck bugs,
> in *addition* to those listed in bug 956905 comment # 148.

there are 9 more bugs listed.

DJ-Leith
(In reply to Schalk Neethling [:espressive] from comment # 5)
> (In reply to DJ-Leith from comment #3)
> > Minor point, compare the two screenshots and you will see that
> >   "Adobe Reader" has lost the 'Reader logo'.
> >   One way to 'guess what this is supposed to convey is':
> >   use the 'lego brick logo' for 'we don't have a logo for this plugin'.
> >   Recently there was a Reader logo.
> > 
> 
> PR opened https://github.com/mozilla/bedrock/pull/2547


The Bedrock bug 1105312 "Fix Adobe Reader Icon" has now completed.

This has NOT done 'what Schalk Neethling and I were expecting':
the icon has NOT changed.
The 'wrong icon' is a 'trivial symptom' of a more important issue.

(In reply to DJ-Leith from bug 1105312 comment # 3)
> A. See
>     https://bug1084537.bugzilla.mozilla.org/attachment.cgi?id=8509897
>     Screenshot taken on 2014-10-21 showing "Adobe Acrobat"
>       (which is in the "Product name" field in plugin metadata, from
>       the file "nppdf32.dll", - THE plugin).
>     Note also the "... Netscape 11.0.9", in the second line describing
>     the "Adobe Acrobat".  This is also, I speculate, from the metadata.
> 
> B. See
>     https://bug1101613.bugzilla.mozilla.org/attachment.cgi?id=8528636
>     Screenshot taken on 2014-11-25 showing "Adobe Reader",
>        which is from the 'JSON List' data.
>        The obvious thing you will see is the logo is generic
>        (not Adobe's logo).
>     The more subtle point is that there is there is NO 'version'
>     in the in the second line describing the "Adobe Reader".
>     Instead, there is JUST "Adobe PDF Plug-In For Firefox and Netscape".
>     Both "Adobe Reader" and "Adobe PDF Plug-In For Firefox and Netscape"
>     come from the 'JSON List' (not the metadata).
>        
>     See
>     https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8487601
>     In this example, from 2014-09-10, there are 5,428 lines in the 'JSON List'.
> 
> > 1618      'adobe-reader': {
> > 1619        'display_name': 'Adobe Reader',
> > 1620        'description': 'Adobe PDF Plug-In For Firefox and Netscape',
> 
> So the 'Plugincheck Website' is showing data from the 'JSON List' in this case.


Testing today, 2014-12-08, using Fx 34 (current Release) with:
* UA spoof to Fx 31, I get similar to A ("Adobe Acrobat" with 'red logo')
* UA spoof to Fx 36, I get similar to B ("Adobe Reader", no 'red logo',
    and no "... Netscape 11.0.9")

In addition,
testing with Fx 36.0a2 (2014-12-08)
I get similar to B ("Adobe Reader", no 'red logo', and no "... Netscape 11.0.9").

In order to get 'any report at all', in all 3 tests, I had to allow enumeration of plugins
("plugins.enumerable_names" set to "*").

Remember,
between May 2014 and 2014-11-24, using Aurora, I got 'a result' without ANY
plugin enumeration ("plugins.enumerable_names" set to "" empty string)
for those plugins that were 'in the JSON List'.

So, my interpretation of
Result A 'red Adobe logo'
vs
Result B 'blue generic logo' 

Is,
A shows that the data used for the evaluation of the Plugins is collected from,
or "fetechd" from, the Plugincheck Databases using the 'pre May 2014 method Plugincheck'.

B shows that data contained in the 'JSON List' has been used at the 'Plugincheck Website'.

However, unlike all tests that I have done - using Aurora - between May 2014 and 2014-11-24,
where both bug 1020133 comment # 85 and  bug 1101613 comment # 2, said that
changes had arrived at production, I have had to enable enumeration of ALL plugins
("plugins.enumerable_names" set to "*").


Schalk,
I think that 'changes on 2014-11-24' were not limited to 'loss of the red logo'
and bug 1105312 "Fix Adobe Reader Icon" does not seem to have improved things.

I have asked you, on 2014-11-26 in bug 956905 comment # 149, for your plans for
> The strategic direction of the development of the 'Plugincheck Service'.

I have already said (in bug 956905 comment # 149)
> My choice would be
> "1D" or "1A" (but not "1C").

Chris Peterson has made some very helpful points in bug 956905 comment # 150:
we have yet to read your thoughts.

I imagine that you may well have many calls on you time but I hope that
you can continue to work on the Plugincheck Service. 

At the moment I think that:

A. the Plugincheck Service is still a priority for Mozilla.

Quoting Chris Peterson (:cpeterson) 2014-11-26 in bug 956905 comment # 150:
> 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. 

B. On 2014-02-23, in bug 956905 comment # 75, you listed 37 plugins that
you were planning to put into the 'JSON List'.
This bug, "PluginCheck Database Clearance", has reduced the 'breadth of coverage
of the Plugincheck Service' by removing data for 30 plugins (about 80%).

You have filed two bugs, on 2014-11-29, to add some data back into the 'Plugincheck Database':
bug 1106310 "Add Google Earth Plugin" 
bug 1106311 "Add Shockwave Plugin"

but, as I write, these are still "Status: NEW".

DJ-Leith
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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: