Closed Bug 1020133 Opened 7 years ago Closed 5 years ago

Improve Adobe Acrobat plugin reporting

Categories

(Plugin Check :: UI, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: espressive, Assigned: espressive)

References

Details

Attachments

(18 files)

201.86 KB, image/png
Details
185.09 KB, image/png
Details
193.28 KB, image/png
Details
135.88 KB, image/png
Details
201.62 KB, image/png
Details
22.09 KB, text/plain
Details
207.06 KB, text/plain
Details
498.44 KB, image/jpeg
Details
198.94 KB, image/jpeg
Details
133.94 KB, image/jpeg
Details
531.01 KB, image/png
Details
630.49 KB, image/png
Details
148.10 KB, image/jpeg
Details
175.23 KB, image/jpeg
Details
228.51 KB, image/jpeg
Details
201.82 KB, image/jpeg
Details
217.59 KB, image/jpeg
Details
24.95 KB, text/plain
Details
Quoting from Bug 1010132

"So, to conclude.

First, my understanding includes the following:

If you install Adobe Reader / Adobe Acrobat, using a browser to 'collect it
from Adobe', you are also given the 'plugin for the browser used to collect
the software' as part of the 'Acrobat install'.

Even if a user often uses "PDF.js", in Firefox, to read PDF files they might
still have the plugins installed on their computer.

One of the many reasons to use plugincheck.

I speculate that the Mac
(from comment # 14)
> Safari 7.0.3
> -------------
> ... ...
> Adobe Acrobat NPAPI Plug-in, Version 11.0.07 - Research (aka Unknown)

has Adobe Acrobat and that it was installed using Safari, and there is
a plugin (from Adobe) 'working with Safari'.

In the examples I have posted in comment # 17, 18, 19 and 20.

There are 'Acrobat plugins for Firefox' (and Aurora - they are 'machine wide').
There are no Acrobat plugins for IE (because IE was not used).

I have seen the same for Flash.  In IE 9, which comes with 32bit and 64bit versions, I used to have to update the 32bit Flash separately from the 64bit Flash (both ActiveX)as well as the 'Flash for Firefox'. Recently Adobe have improved the IE Flash installer and I have found that updating the 64bit has also updated the 32bit Flash.
I still check BOTH versions of IE at http://www.adobe.com/software/flash/about/ 

Same for Java (32bit and 64bit). 


Carsten Book [:Tomcat] has updated the plugincheck database for Adobe Acrobat.
"May updates for Adobe Acrobat 11.x and 10.x"
He did say in bug 1010086 comment # 1
> plugincheck production updated, just might need QA check


Perhaps the QA check could include testing more browsers?

My comments are:

1. In
https://bug1010132.bugzilla.mozilla.org/attachment.cgi?id=8426510
from comment # 18
we see "Adobe Acrobat", 11.0.6.70 - "Up to Date".  This is wrong.
Uses the 'release plugincheck', Fx 29.0.1.


2. In
https://bug1010132.bugzilla.mozilla.org/attachment.cgi?id=8426513
from comment # 19
we see "Adobe Acrobat NPAPI Plug-in", 11.0.6.70 - "Up to Date".  This is wrong.
Uses the 'new plugincheck', Fx 31.

Both are 'a false sense of security'. 

I think it would be good to see what is in the database and how it was possible for both the 'current' and the 'new' versions of plugincheck to report "Up to Date" 11.0.6.70 and 11.0.7.79 - see next.

Now, see the attached "Fx29-0-1-plugincheck-after-update-2014-05-20.jpg".

This is the Release (Fx 29.0.1) after the '13 May 2014 Microsoft Patch Tuesday updates'
and 'plugin updates'.

This is good:

NPCIG.dll - "Unknown"  - very useful to know.
Google Update - "Unknown" - very useful to know.

Google Earth - "Up to Date" - expected and correct.
Adobe Acrobat 11.0.7.79 - "Up to Date" - expected and correct.
Shockwave Flash 13.0.0.214 - "Up to Date" - expected and correct.

I would be excellent to get the Aurora result as good as this.

DJ-Leith"
(In reply to Schalk Neethling from bug 1010132 comment #29)
> (In reply to DJ-Leith from bug 1010132 comment #28)
> 
> Hey DJ,
> 
> Thanks for testing and your feedback. So, first why the dupe on Bug 1011824, well, as
> with this bug, it relates to the incorrect categorisation of the .206 release of Flash
> as up to date. In terms of the code that is one stage now, this (and the duped) bug
> is fixed.
> 
> I acknowledge the problem(s) reported regarding Acrobat but, I do believe we need to
> track this as a separate bug and I will open one as such.

Schalk, thanks for the clarification and apologies for the posting in bug 1010132
(which was closed) and thanks for opening this bug.  I am happy to provide feedback;
as you know, I'm one of many who use plugincheck everyday.
However, I don't have too many plugins to test.

I agree, best to treat the Adobe Acrobat plugin reporting as a separate bug: *this* bug.


To help other readers, a few links back to the closed bug:

(from comment # 0 - above in this bug)
> I speculate that the Mac
> (from bug 1010132 comment # 14)
> > Safari 7.0.3
> > -------------
> > ... ...
> > Adobe Acrobat NPAPI Plug-in, Version 11.0.07 - Research (aka Unknown)
> 
> has Adobe Acrobat and that it was installed using Safari, and there is
> a plugin (from Adobe) 'working with Safari'.

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.

(from comment # 0)
> Now, see the attached "Fx29-0-1-plugincheck-after-update-2014-05-20.jpg".
The URL is
https://bug1010132.bugzilla.mozilla.org/attachment.cgi?id=8426517

> This is the Release (Fx 29.0.1) after the '13 May 2014 Microsoft Patch Tuesday updates'
> and 'plugin updates'.
> 
> This is good:
> 
> NPCIG.dll - "Unknown"  - very useful to know.
> Google Update - "Unknown" - very useful to know.
> 
> Google Earth - "Up to Date" - expected and correct.
> Adobe Acrobat 11.0.7.79 - "Up to Date" - expected and correct.
> Shockwave Flash 13.0.0.214 - "Up to Date" - expected and correct.
> 
> I would be excellent to get the Aurora result as good as this.


(Copied from bug 1010132 comment # 27)

***
Main point - Flash is better BUT Acrobat is worse!
***

Tests were done on 2014-06-03.

Method:

Used Aurora on Stage:
https://www.allizom.org/en-US/plugincheck/

See "Fx31-plugincheck-STAGE-2014-06-03.jpg".
https://bug1010132.bugzilla.mozilla.org/attachment.cgi?id=8433727

Here, "Adobe Flash Player" 13.0.0.214 is Reported as "Up to Date" - correct - good.
BUT, "Adobe Acrobat NPAPI Plug-in" is Reported as "vulnerable" - WRONG.

    It also shows the version "11.0.7.79",
    see bug 1017483 "Always expose version number of plugin",
    in my opinion, a VERY GOOD enhancement.


(Copied from bug 1010132 comment # 28)

Compared to Aurora on Live:
https://www.mozilla.org/en-GB/plugincheck/ (in my GB case).

See "Fx31-plugincheck-LIVE-2014-06-03.jpg".
https://bug1010132.bugzilla.mozilla.org/attachment.cgi?id=8433731

This screenshot shows Acrobat "11.0.7.79" as "Up to Date" - which is the
'correct result'.

  [Aurora on Live also has the 'wrong result for Flash', *known issue*.]


<snip>

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.

<snip>

(quoting Schalk)
> and that no regressions are introduced. 
I think the Acrobat result, on Stage, is a regression.

DJ-Leith
(In reply to DJ-Leith from comment #1)
> 
> DJ-Leith

This is my new P1, so a fix for this will be landing very soon. Thanks for all *your* work in keeping us on our toes and making plugincheck awesome :)
Blocks: 1023718
My Bug 1023718 reports that UPDATE button on the plugin check for Adobe Acrobat just loops and reloads the plugin checker page in the new FF 30.0 released yesterday.

I've been an observer and very minor participant in some recent plugin check issues.  The accuracy of the check itself may be in question (as per above), but the action of what to do -- I think I'm doing an update -- is wrong.  If there is no update, please say so.  Otherwise, it is natural for the user to conclude the reload is a bug instead of being a neutral ("do-nothing", "do-no-harm") action.  Hence, a separate bug to report wrong behaviour.
When Firefox 30 was released these issues with Adobe Acrobat plugin were then seen widely.

Bug 1024435 "Bump version of plugincheck.next to 30" has given us a bit of time.

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 links to duplicates - where there are many good points.

DJ-Leith
FAO Schalk Neethling [:espressive]
and *all* involved in QA of the 'plugincheck service'
(I am CCing Matt Brandt and Catalin Varga).

Have you seen bug 956905 comment # 148?

DJ-Leith said, on 2014-07-16:
> 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.

There are links to more than a dozen bugs, including this one.

In that post, in the section
> To Do - before 'plugincheck for RELEASE' uses the JSON list.
in the sub-section
> 4. Test and QA.
I give my reasons for why I do tests (what I think are good tests)
and how I interpret the results.


***
Tests in anticipation of Fx 31 becoming the RELEASE version of Firefox next week.
***

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

Tests done on 2014-07-17 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 32.0a2 - with NO enumeration - "plugins.enumerable_names" set to "" (empty string)
Adobe Acrobat reported as "vulnerable" - WRONG.
We know this, has been documented since 2014-05-21 (in bug 1010132 comment # 17).
*This* bug is about the Adobe Acrobat plugin detection.

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

Fx 30 (UA spoof to 31) - "plugins.enumerable_names" set to "*" [all plugins enumerated]

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

Adobe Acrobat reported as "vulnerable" - WRONG.
This is what I anticipate MANY will see if we don't change the 'plugincheck service'.

Using Schalk's terminology (from bug 1038649)
> Plugin Check [product]
> --> Database (plugins.mozilla.org)
> --> Client (Perfidies aka https://github.com/ossreleasefeed/Perfidies-of-the-Web)
> --> UI (mozilla.org/plugincheck)
> --> Plugins (For release notifications)

I think Schalk needs to change Perfidies.

IIUC, when a 'browser visits the plugincheck web site' it is 'detected using the UA'.
  My tests, above, seem to support this.
If the browser is Firefox 30 (or older) THEN use enumeration - the 'current plugincheck'.
If the browser is Firefox 31+ THEN use the JSON List (NO enumeration is done by
the plugincheck web site).

So, if Perfidies were changed to:
If the browser is Firefox 31 (or older) THEN use enumeration - the 'current plugincheck'.
If the browser is Firefox 32+ THEN use the JSON List (NO enumeration is done by
the plugincheck web site).

We would prevent 'false alarms' and give everybody working to improve the 'plugincheck service'
another few weeks to get it working WITHOUT ANY enumeration.

DJ-Leith
Flags: needinfo?(schalk.neethling.bugs)
I have seen the comment you refer to. I am currently working on and planning the work for this quarter and prioritising the work that is going to be done. Work towards solving these problems are actively being worked on but, if there are high priority problems not resolved by tomorrow (18 July 2014), I will bump the version so, non enumeration will not run on release until absolutely ready.
Flags: needinfo?(schalk.neethling.bugs)
(In reply to Schalk Neethling [:espressive] from comment #6)
> I have seen the comment you refer to. I am currently working on and
> planning the work for this quarter and prioritising the work that is
> going to be done. Work towards solving these problems are actively
> being worked on but, if there are high priority problems not resolved
> by tomorrow (18 July 2014), I will bump the version so, non enumeration
> will not run on release until absolutely ready.

Schalk, I was reassured when read this (on 17th July).

My understanding of your comment is, to paraphrase, that you knew all
about this and you WOULD ensure that this 'Acrobat false alarm' would
only be visible to Beta, Aurora and Nightly users, i.e. Fx 32+, because
you WOULD "bump the version" on 18 July 2014.

If you do, users of Fx 31 - which WILL BE RELEASED on 22 July - will
not see this 'false alarm'.  When Fx 30 was released four bugs were opened
and there were also threads on SUMO (see bug 1023718 comment # 10).

I've not see a bug to "bump the version" and I still see the same results
as in comment # 5, in particular:

> Fx 30 (UA spoof to 31) - "plugins.enumerable_names" set to "*" [all plugins enumerated]
> 
> user_pref("general.useragent.override", "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0)
> Gecko/20100101 Firefox/31");
> 
> Adobe Acrobat reported as "vulnerable" - WRONG.
> This is what I anticipate MANY will see if we don't change the 'plugincheck service'.

So please can you "bump the version so, non enumeration will not run on
release until absolutely ready", on Monday 21 July.

DJ-Leith
Flags: needinfo?(schalk.neethling.bugs)
Here are the pull requests, set to go live today:

https://github.com/ossreleasefeed/Perfidies-of-the-Web/pull/11
https://github.com/mozilla/bedrock/pull/2165
Flags: needinfo?(schalk.neethling.bugs)
Schalk,

It is taking many hours for the 'Bump Fx Version', bug 1041509,
to actually get into production.  

Starting about 13:30 BST on 2014-07-21 (05:30 PDT), I attempted my test
every few hours, to see how long it took.

As I write my tests are still failing.
I will not be able to do more tests in the next 12 hours.

Please can someone confirm / deny that the 'Bump Fx Version' has happened.

Bug 1041509 was opened about 06:05 PDT (on 21st July).
> Schalk Neethling [:espressive] 2014-07-21 06:05:29 PDT 

Some of my tests were before bug 1041509 comment # 1 where:
> [github robot] 2014-07-21 10:18:34 PDT
>  
> Commits pushed to master at https://github.com/mozilla/bedrock
> ...
The commits then closed the bug.

So, for example, about 21:25 BST (13:25 PDT), more than 3 hours
after bug 1041509 had closed, the tests were still failing.

Tests done: see comment # 5.

In this case, until 'Bump Fx Version' had completed,
I expected to see this (which I am calling a FAIL):
> Fx 30 (UA spoof to 31) - "plugins.enumerable_names" set to "*" [all plugins enumerated]
> 
> user_pref("general.useragent.override", "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0)
> Gecko/20100101 Firefox/31");
> 
> Adobe Acrobat reported as "vulnerable" - WRONG.
> This is what I anticipate MANY will see if we don't change the 'plugincheck service'.

Once the 'Bump Fx Version' had completed I hope to see
Adobe Acrobat reported as "Up to Date" - good.

As an additional test, once Fx 31 is a PASS, I intended to change the UA to
user_pref("general.useragent.override", "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0)
Gecko/20100101 Firefox/32");
and this, I expect, will then result in
Adobe Acrobat reported as "vulnerable" - again.

So, from my observations, it is taking more than 18 hours for the
'Bump Fx Version' to get into production.

DJ-Leith
(In reply to DJ-Leith from comment #10)
> Schalk,
> 
> It is taking many hours for the 'Bump Fx Version', bug 1041509,
> to actually get into production. 
> 
> DJ-Leith

My changes are not yet on production, but still in the queue for today:
https://github.com/mozilla/bedrock/compare/bb6bb4b6e5e2094578d0e73b2f14ba1c2fe3f7a8...master

The push will happen before the release though. Thanks for testing.
Schalk, thanks for doing this.  We have prevented a lot of 'false alarms'.

> The push will happen before the release though.
Thanks also, for confirming that the push would happen before release.

From comment # 10
> Once the 'Bump Fx Version' had completed I hope to see
> Adobe Acrobat reported as "Up to Date" - good.
> 
> As an additional test, once Fx 31 is a PASS, I intended to change the UA to
> user_pref("general.useragent.override", "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0)
> Gecko/20100101 Firefox/32");
> and this, I expect, will then result in
> Adobe Acrobat reported as "vulnerable" - again.
I did manage to confirm both points, at 17:30 BST (09:30 PDT) on 2014-07-22.

So it took between 18 hours and 27 hours for the 'Bump Fx Version' to get
into production.

I don't know if this is 'normal' / 'expected': I was surprised at the time taken.

> Thanks for testing.
You are very welcome, happy to help. 


One further point:

I did notice, while I was testing and waiting, that bug 1041509 is the first bug
in the new bugzilla category (from bug 1038649):
> Product: Plugin Check

As I write, the 'bugzilla search URL':
https://bugzilla.mozilla.org/buglist.cgi?all=&product=Plugin%20Check&query_format=advanced&order=changeddate%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&limit=0

only finds that [first] bug.

FYI, I have found the following 'bugzilla search URL' to be very useful:
https://bugzilla.mozilla.org/buglist.cgi?all=&component=plugins.mozilla.org&product=Websites&query_format=advanced&order=changeddate%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&limit=0

It finds more than 500 bugs.
Many of these could do with your review and classification.

However, as it relies on the bugs being filed against "component=plugins.mozilla.org",
it does NOT find some important 'plugincheck service' bugs.

To use a good example see bug 952602
(which is, correctly, NOT filed against "component=plugins.mozilla.org").

This is Chris Peterson's bug
      to make the RELEASE have the setting "plugins.enumerable_names"
      set to "*". That is 'allow a web site to do enumeration of all plugins'.

> Summary:      Disable bug 757726 for Firefox 28 release (changes to plugin detection)
> ...
> Product:      Core
> Component:    Plug-ins
> Version:      28 Branch
> Platform:     All All

Please keep up the good work!

DJ-Leith
@schalk + @DJ-Leith - FYI

I looked for FF31.0 a few times today -- finally got it tonight -- so new, in fact, that my Norton download scanner said it "had no reputation" yet!

Anyway, I also tested the plugin module for you, first on FF30.0 where I knew it worked OK.  I saw no errors or anything different between the two versions.  Of particular interest, it says Adobe Acrobat 11.0.7.79 and Shockwave Flash 14.0.0.145 (two recent problems) are both "up-to-date".  Also up-to-date, just so you know:  Silverlight 5.1.30214.0;  QuickTime 7.7.5.0;  Java Deployment Toolkit 10.65.2.20 and Java Platform 10.65.2.20.  (Five other assorted plugins came back "unknown" as usual.)
Thanks for testing Dan, much appreciated.
I filed bug 1053417 for
"Adobe Reader for Windows - plugins vulnerable 2014-08-12 - APSB14-19"

1 of 5

Attached is
"Plugincheck-Screenshot-Win7-Fx31-Before-Flash-update-shows-Reader-CORRECT-20140813.png"

Fx 31 - release

This shows Flash as "vulnerable" - correct
and Reader as "Up to Date" - correct

DJ-Leith
2 of 5

Attached is
"Plugincheck-Screenshot-Win7-Fx33-Before-Flash-update-shows-Reader-WRONG-20140813.png"

Fx 33 - Aurora

This shows Flash as "vulnerable" - correct
and Reader as "vulnerable" - WRONG

Note also, that Reader is in the "Outdated" section.
If it WAS "vulnerable" it should be in the same section as Flash.

DJ-Leith
3 of 5

Attached is
"Plugincheck-Screenshot-Win7-Fx33-After-Flash-update-shows-Reader-WRONG-20140813.png"

Fx 33 - Aurora

Now that Flash has been updated, it is "Up to Date", and has been moved down - correct
Reader shown as "vulnerable" - WRONG

DJ-Leith
4 of 5

Attached is
"Plugincheck-Screenshot-Win7-IE9-After-Flash-update-shows-Blue-CORRECT-20140813.png"
Flash has been updated, it is "Up to Date".

Internet Explorer 9 (32bit).
  FYI, with Internet Explorer 9 (64bit) I do NOT get any 'result',
  just a 'rotating circle' indicating
  'something downloading / updating - please wait'.

Reader has never been installed 'via IE' so there is no Reader (ActiveX) Plugin for
IE on this computer.

From comment # 0
> First, my understanding includes the following:
> 
> If you install Adobe Reader / Adobe Acrobat, using a browser to 'collect it
> from Adobe', you are also given the 'plugin for the browser used to collect
> the software' as part of the 'Acrobat install'.
> 
> Even if a user often uses "PDF.js", in Firefox, to read PDF files they might
> still have the plugins installed on their computer.

In bug 1053409 I commented on the colour of the "Up to Date" button in IE9.
Why is this blue not green? 

DJ-Leith
5 of 5

Attached is
"Plugincheck-Screenshot-Win7-Fx31-After-Flash-update-shows-Reader-CORRECT-20140813.png"

Fx 31 - release

Now that Flash has been updated, it is "Up to Date", and has been moved down - correct
All is OK.
You can also see the "Unknown" plugins.

DJ-Leith
Duplicate of this bug: 1061985
Duplicate of this bug: 1062393
Hey All,

So I have a quick question for which I cannot seem to find a simple answer so, I am opening it up here for feedback. Is there a difference between the plugin reported as Adobe Reader and the one reported as NPAPI Reader (other than the one seemingly have to do with Netscape/Firefox....)

The reason I ask is that I see we manage two separate lists in the DB for Acrobat Reader and Acrobat Reader NPAPI and the latter is out of date on the database level. Perhaps we do not even need to track these separately or, I need to make sure that updates go to both streams.
Ah right http://en.wikipedia.org/wiki/NPAPI#Browser_support

So we really should not be tracking these separately as there, from what I can see so far, is no difference in terms of version release numbers etc.
:Tomcat is there a reason why we are/were maintaining the the two Adobe Reader lists?
Flags: needinfo?(cbook)
I also see that for the NPAPI version we are using a different version number format (perhaps this is the reason we track it separately or, this is part of the problem) i.e.

Under Adobe Reader we have: 
11.0.7.0, 11.0.8.0 etc.

For Adobe Reader NPAPI we have: 
11.0.06, 11.0.07 (this matches what Adobe shows on the release notes but not what the browser reports, from what I have seen)
@Schalk (for what it's worth):
As a user I've noticed for at least the past three years that Adobe Reader often uses v.r.r and v.r.0r formats interchangeably.  I think I'm updating to one, and later it tells me it's the other.  I see it when running the Adobe Updater, the stub that downloads the update for you.

To get an an idea, in Reader go to HELP, About Reader -- then go to HELP, About PlugIns.  There's sometimes a range of version IDs for the PlugIns, the latest of which is the current version/revision of Reader.  Similarly in Acrobat (their PDF generator).
(In reply to Schalk Neethling [:espressive] from comment #24)
> :Tomcat is there a reason why we are/were maintaining the the two Adobe
> Reader lists?

i think that was due the way plugincheck detects the plugin and we needed that 2 ways to be safe
Flags: needinfo?(cbook)
(In reply to Dan Pernokis from comment #26)
> @Schalk (for what it's worth):
> As a user I've noticed for at least the past three years that Adobe Reader
> often uses v.r.r and v.r.0r formats interchangeably.  I think I'm updating
> to one, and later it tells me it's the other.  I see it when running the
> Adobe Updater, the stub that downloads the update for you.
> 
> To get an an idea, in Reader go to HELP, About Reader -- then go to HELP,
> About PlugIns.  There's sometimes a range of version IDs for the PlugIns,
> the latest of which is the current version/revision of Reader.  Similarly in
> Acrobat (their PDF generator).

Thanks for the info. It seems though, looking at the various browser' about:plugins type pages that the bowser always reports the version in the format 1.0.7.0 so, it looks to be safe to assume this. Also, from looking in the plugins database, the versions are tracked that way there.

I am however doing further investigation to make absolutely sure before continuing based on an assumption.
(In reply to Carsten Book [:Tomcat] from comment #27)
> (In reply to Schalk Neethling [:espressive] from comment #24)
> > :Tomcat is there a reason why we are/were maintaining the the two Adobe
> > Reader lists?
> 
> i think that was due the way plugincheck detects the plugin and we needed
> that 2 ways to be safe

Thanks Carsten. It seems more and more to me that we can get rid of that duplication as Chrome is phasing out support for NPAPI plugins during the course o this year, and Fx itself has started doing that from release 30 but, as with my above comment, further testing is needed to be sure before dropping that data.
Post 1 of 4

(In reply to Schalk Neethling [:espressive]  from comment #29)
> (In reply to Carsten Book [:Tomcat] from comment #27)
> > (In reply to Schalk Neethling [:espressive] from comment #24)
> > > :Tomcat is there a reason why we are/were maintaining the the two Adobe
> > > Reader lists?
> > 
> > i think that was due the way plugincheck detects the plugin and we needed
> > that 2 ways to be safe
> 
> Thanks Carsten. It seems more and more to me that we can get rid of that
> duplication as Chrome is phasing out support for NPAPI plugins during the
> course o this year, and Fx itself has started doing that from release 30
> but, as with my above comment, further testing is needed to be sure before
> dropping that data.

All, I am using single quotes for slang / imprecise language
and I am using double quotes (") for direct quotations.

Schalk,
I agree with Carsten.
> > i think that was due the way plugincheck detects the plugin and we needed
> > that 2 ways to be safe
I speculate that detection for Mac vs Windows may have been the historic reason
for keeping separate 'families of Adobe Reader / Acrobat' plugins in the database.

I further speculate that what we are seeing here,
in the 'new plugincheck - uses the JSON List',
https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8472630
The Screenshot is showing "Adobe Acrobat NPAPI Plug-in".

This version, 11.0.8.4, in the screenshot,
is the correct 'version number' but - I think because it is from
the WRONG 'section of the JSON List' (see below) it is
reported 'in the "Outdated Plugins" section' (WRONG section)
with the WRONG "Update Now" red button.

The WRONG "Update Now" red button ALSO has the
'link back to plugincheck' (bug 1023718 - which is being blocked by this bug).


  The 'plugincheck using enumeration'
  on Release [now Fx 32]
  is using detecting in a different way and is NOT reporting
  on "Adobe Acrobat NPAPI Plug-in",
  https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8472634
  Screenshot is showing "Adobe Acrobat".
  This is the SAME plugin.
  The 'plugincheck website' is showing "Adobe Acrobat" 11.0.8.4 as "Up to Date".


I think the 'new plugincheck - uses the JSON List' uses the *Mac data* (or the
part of the JSON List that was exported FROM the part of the Database
that held the Mac data).

The screenshots (above) are all from Windows 7 PCs
(and taken in August 2014 - before Flash 15.0.0.152 was released).

Schalk, you (or anybody with a Mac) can test plugincheck
to see if "Adobe Acrobat NPAPI Plug-in" is reported.

Compare: Release (Fx 32) vs Beta+ (Fx 33+)

Is "Adobe Acrobat NPAPI Plug-in" being reported using Fx 32 on a Mac?
The plugin is reported as "Adobe Acrobat" on Windows using Fx 32.

You don't even need to have the version of Firefox; spoofing the UA
will be enough to test. I have used both Aurora (with spoofing Release)
and Release (with spoofing Beta) to see the Correct and the WRONG results.

On Windows 7, the 'UA spoof for Beta' is:
user_pref("general.useragent.override", "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0)
Gecko/20100101 Firefox/33");

So, can anybody confirm 
> Is "Adobe Acrobat NPAPI Plug-in" being reported using Fx 32 on a Mac?

DJ-Leith
Post 2 of 4

My point of view about the 'Plugincheck service' is that I don't care 'how it works'
nearly as much as 'is it accurate?', 'is it clear what the results are', 'what is it NOT testing'.

So, for example, I like the "Unknown" plugins - the onus is on the 'visitor to the
service' to use another method to assess these plugins.

However, to improve it, changes it etc one does need to know 'how it works'.

The 'Plugincheck service' does rely on the 'Plugincheck Database'.

Schalk you and Carsten can see the data *in* Database.
Dan, and others and myself can only see the 'output from the Database'.
It is the 'output from the Database' that is being used at the web site.

  See also Bug 985968 "Mozilla Plugin check page displays Java plugin
  as vulnerable even if the latest Java 7 version is installed".

  Comment # 40 of that bug has the link (to a text file with line numbers)
  https://bugzilla.mozilla.org/show_bug.cgi?id=985968#c40
  and comment # 41 of that bug has my discussion of the
  'output from the plugincheck database'.


As we have seen in this bug, and the duplicates (and bug 1062244),
if you are using Beta+ (Fx 33+) you get the 'wrong result'.


In the next two comments I will attach Text Files (TXT) that
contain 'output from the Database'.

In these I hope to illustrate WHY I think, in this bug, the
MAIN issue is not confined to the Database.

There are two 'outputs from the Database':
the 'JSON List' (see comment # 33)
and the 'section relevant to the plugins detected by enumeration'
(see comment # 32).

When we are using JUST the 'section relevant to the plugins detected
by enumeration' we get 'the correct result' which is why
I am going to comment on it first.

DJ-Leith
Post 3 of 4

Please see "Plugincheck-Fx-32-build-aa315da-with-line-numbers-2014-09-10.txt"

I hope you can follow the STR between lines 0008 and 0009:

> 0007   * 3. Display to insert the result in a comment after the selection. (Ctrl+L)
> 0008   */
>        *** Ten lines added here
>        ***  URL:  https://www.mozilla.org/en-GB/plugincheck/ LIVE (for GB)  Date: 2014-09-10
>        ***  Browser: Fx 32 Release
>        ***  with ALL plugins enumerated - "plugins.enumerable_names" set to "*"
>        ***    Tools, Web Developer, Network  - look for "v2?appID={... "
>        ***    Try the 'one above the Acrobat logo'
>        ***    then choose "Headers", "Edit and Resend", click in the URL, <Ctrl>+<a> (to select all), Copy.
>        ***    Open a new Tab, and paste the URL. 
>        ***    Select the 'result' <Ctrl>+<a> (to select all), Copy and Paste into Scratchpad, "Pretty Print".
>        ***    Add line numbers and then these ten unnumbered lines. These match the Scratchpad 
>                 line numbers (534 lines).
> 0009  C([{
> 0010    'aliases': {

I found this difficult to 'explain here in the bug'.

Remember, this is the 'output from the Database' that gives the CORRECT result.

So, we will NOT FIND any "NPAPI" or any "Adobe Acrobat NPAPI Plug-in" in
the 534 lines of 'output from the Database'
that are 'relevant to my visit to plugincheck, with Fx 32, on a Windows PC'.

Please search the TXT file, there is no "NPAPI"!
It is difficult to show 'what is NOT there'.

What *is* present is 'data relevant to a Windows PC which plugincheck has
detected has an Adobe Reader / Acrobat plugin'.

First, look at the "aliases", at the top.

> 0010    'aliases': {
> 0011      'literal': [
> 0012        'Adobe Acrobat',
> 0013        'Adobe Reader',
> 0014        'Adobe Acrobat',
> 0015        'Adobe Reader',
> 0016        'Adobe Acrobat',
> 0017        'Adobe Reader'
> 0018      ],
> 0019      'regex': [
> 0020        'Adobe Reader.*'

Here is the section about the CORRECT version:
> 0049        {
> 0050          'id': '4',
> 0051          'pfs_id': 'adobe-reader',
> 0052          'name': 'Adobe Reader',
> 0053          'description': 'Adobe PDF Plug-In For Firefox and Netscape',
> 0054          'vendor': 'Adobe',
> 0055          'url': 'http://get.adobe.com/reader/',
> 0056          'modified': '2014-08-27T17:38:46+00:00',
> 0057          'created': '2014-08-27T17:38:46+00:00',
> 0058          'plugin_id': '2',
> 0059          'os_id': '3',
> 0060          'platform_id': '4',
> 0061          'status': 'latest',
> 0062          'version': '11.0.8.0',
> 0063          'detected_version': '11.0.8.0',
> 0064          'detection_type': '*',
> 0065          'os_name': 'win',
> 0066          'app_id': '*',
> 0067          'app_release': '*',
> 0068          'app_version': '*',
> 0069          'locale': '*',
> 0070          'fetched': '2014-09-10T05:07:16-07:00',
> 0071          'relevance': 3

This data has been used in
https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8472634
the screenshot we saw above.

Note:
> 0061          'status': 'latest',
and 
> 0065          'os_name': 'win',

I speculate that
> 0070          'fetched': '2014-09-10T05:07:16-07:00',
is when the 'data was collected from the Database'.

> 0055          'url': 'http://get.adobe.com/reader/',
So, unlike bug 1023718, you can 'click the link to collect
a new Adobe Reader'.

> 0056          'modified': '2014-08-27T17:38:46+00:00',
> 0057          'created': '2014-08-27T17:38:46+00:00',

See bug 1053417.
Schalk did update the Database on 27th August 2014.
THIS record, about 
> 0062          'version': '11.0.8.0',
was "created" then.


Other records, e.g. 11.0.7.0
are 
> 0259          'status': 'vulnerable',

> 0254          'modified': '2014-08-27T17:38:46+00:00',
> 0255          'created': '2014-05-14T14:06:52+00:00',
were created before they became vulnerable and were
modified when 'declared vulnerable' (in this case "2014-08-27T17:38:46+00:00").

The whole section about 11.0.7.0:
> 0247        {
> 0248          'id': '4',
> 0249          'pfs_id': 'adobe-reader',
> 0250          'name': 'Adobe Reader',
> 0251          'description': 'Adobe PDF Plug-In For Firefox and Netscape',
> 0252          'vendor': 'Adobe',
> 0253          'url': 'http://get.adobe.com/reader/',
> 0254          'modified': '2014-08-27T17:38:46+00:00',
> 0255          'created': '2014-05-14T14:06:52+00:00',
> 0256          'plugin_id': '2',
> 0257          'os_id': '3',
> 0258          'platform_id': '4',
> 0259          'status': 'vulnerable',
> 0260          'vulnerability_description': 'These updates address a vulnerability that 
 could allow an attacker to circumvent sandbox protection on the Windows platform.',
> 0261          'vulnerability_url': 'http://helpx.adobe.com/security/products/reader/apsb14-19.html',
> 0262          'version': '11.0.7.0',
> 0263          'detected_version': '11.0.7.0',
> 0264          'detection_type': '*',
> 0265          'os_name': 'win',
> 0266          'app_id': '*',
> 0267          'app_release': '*',
> 0268          'app_version': '*',
> 0269          'locale': '*',
> 0270          'fetched': '2014-09-10T05:07:16-07:00',
> 0271          'relevance': 3
> 0272        },

In the next comment I will show how we got 
"Adobe Acrobat NPAPI Plug-in" reported, in error,
at the web site.

DJ-Leith
Post 4 of 4

Please see "Plugincheck-Fx-34-build-aa315da-with-line-numbers-2014-09-10.txt"

I hope you can follow the STR between lines 0008 and 0009:

> 0008   */
>        *** Ten lines added here
>        ***  URL:  https://www.mozilla.org/en-GB/plugincheck/ LIVE (for GB)  Date: 2014-09-10
>        ***  Browser: Fx 34.0a2 (2014-09-10) Aurora
>        ***  with NO enumeration - "plugins.enumerable_names" set to "" (empty string)
>        ***    Tools, Web Developer, Network  - look for "plugins_list.json?callback=jQuery..."
>        ***    select this and then Response.
>        ***    Copy this and paste into Scratchpad, then "Pretty Print".
>        ***    I have added line numbers to the TXT file
>        ***    These match the Scratchpad line numbers (5428 lines).
>        *** End of ten added lines.
> 0009  jQuery111004010263349691663_1410378108817({
> 0010    'plugins': {

You could also do this with Fx 32 and spoof the UA to Fx 33.

Notice, that there are 5428 lines (vs 534 lines), MUCH more data in the 'JSON List'.

See
> 0061      'adobeformacreaderfround': {
> 0062        'display_name': 'Adobe Acrobat NPAPI Plug-in',
> 0063        'description': 'Adobe Acrobat NPAPI Plug-in',
> 0064        'versions': {
> 0065          'all': {
> 0066            'latest': [
> 0067            ],
> 0068            'vulnerable': [
> 0069            ]
> 0070          },
> 0071          'win': {
> 0072            'latest': [
> 0073            ],
> 0074            'vulnerable': [
> 0075            ]
> 0076          },
> 0077          'mac': {
> 0078            'latest': [
> 0079              {
> 0080                'status': 'latest',
> 0081                'version': '11.0.07',
> 0082                'detected_version': '11.0.07',
> 0083                'detection_type': '*',
> 0084                'os_name': 'mac',
> 0085                'platform': {
> 0086                  'app_id': '*',
> 0087                  'app_release': '*',
> 0088                  'app_version': '*',
> 0089                  'locale': '*'

Note:
A.
> 0062        'display_name': 'Adobe Acrobat NPAPI Plug-in',
So THIS is where we get "Adobe Acrobat NPAPI Plug-in" from
as seen in
https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8472630
The Screenshot is showing "Adobe Acrobat NPAPI Plug-in".

B.
Harder to see is the fact that
> 0071          'win': {
> 0072            'latest': [
> 0073            ],
> 0074            'vulnerable': [
> 0075            ]
> 0076          },
is 'empty'.

This part of the Database is for "adobeformacreaderfround"
> 0061      'adobeformacreaderfround': {

There ARE Mac versions listed here.
> 0084                'os_name': 'mac',

Also, below
> 0107            'vulnerable': [
> 0108              {
> 0109                'status': 'vulnerable',
> 0110                'vulnerability_description': 'Vendor information',
> 0111                'vulnerability_url': 'http://helpx.adobe.com/security/products/reader/apsb14-15.html',
> 0112                'version': '11.0.06',
> 0113                'detected_version': '11.0.06',
> 0114                'detection_type': '*',
> 0115                'os_name': 'mac',
> 0116                'platform': {
> 0117                  'app_id': '*',
> 0118                  'app_release': '*',
> 0119                  'app_version': '*',
> 0120                  'locale': '*'
you can see the vulnerable version "11.0.06".

This is what Schalk was referring to in comment # 25.
Also Dan's comment # 26.
and my comments, and Schalk's, in bug 1053417.

There is, of course, *also* data about "Adobe Reader"
> 1618      'adobe-reader': {
> 1619        'display_name': 'Adobe Reader',
> 1620        'description': 'Adobe PDF Plug-In For Firefox and Netscape',
> 1621        'versions': {
lots of data.

C.
Again, what you can NOT find is a "'url':" to collect a
'new Adobe reader' in this section of the 'JSON List'.
By "this section" I mean the section starting:
> 0061      'adobeformacreaderfround': {


(from comment # 32)
> 0253          'url': 'http://get.adobe.com/reader/',
where there *is* a URL.


Lower down the 'JSON List' there is:
> 1915        ],
> 1916        'url': 'http://get.adobe.com/reader/',
> 1917        'regex': [
> 1918          'Adobe Reader.*'
> 1919        ]

BUT, I think, this only applies to "Adobe Reader"
> 1917        'regex': [
> 1918          'Adobe Reader.*'
and NOT "Adobe Acrobat NPAPI Plug-in".


WHEN we are using the 'JSON List' the web site has
'no way of displaying the URL' for the 'red vulnerable' button
if it 'detects' (the Mac) "Adobe Acrobat NPAPI Plug-in".


(from comment # 30)
>   https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8472634
>   Screenshot is showing "Adobe Acrobat".

If you hover over the green "Up to Date" buttons

For Adobe Reader ("Adobe Acrobat") the URL is "http://get.adobe.com/uk/reader/"

For Flash ("Shockwave Flash") the URL is "http://get.adobe.com/flashplayer/"

Both must come from the Plugin Database.
Both must be in the 'correct section of the JSON List' for
the website (when it is using the 'JSON List') to work correctly.

You, all of you, may now find
https://bugzilla.mozilla.org/show_bug.cgi?id=1053417#c3
easier to understand once you have looked at both
TXT files attached to this bug.


Towards the end of
https://bugzilla.mozilla.org/show_bug.cgi?id=1053417#c3
I said, on 2014-08-19:
> The full JSON list is here.
> https://plugins.mozilla.org/en-us/plugins_list.json
> I use Scratchpad, Pretty Print, to look at it.
> 
> For
> >  "adobeformacreaderfround": {
> look at line 61 onwards.
> For
> >  "adobe-reader": {
> look at line 1603 onwards.

As Schalk knows this, I did not 'spell it out' - but I will now.

So, the 'JSON List' is here:
https://plugins.mozilla.org/en-us/plugins_list.json

The actual 'line numbers as seen in Scratchpad' may now
be different.

Steps to read the JSON:
1. browse to https://plugins.mozilla.org/en-us/plugins_list.json
2. click once in the JSON and then <ctrl>+<a> (to select all)
3. <ctrl>+<c> (to copy)
4. <shift>+<F4> to open Scratchpad
 (or use the mouse to Firefox, Tools, Web Developer, Scratchpad)

5. click at the 'line 9', and <ctrl>+<v> (paste).
You will have one *huge* line.

6. click "Pretty Print" button, and you will have the JSON in a much
more 'human readable' form (with line numbers).

Like the 
"Plugincheck-Fx-34-build-aa315da-with-line-numbers-2014-09-10.txt"
there are 5428 lines in the 'JSON List' (including the 8 lines of comment at the top).


Schalk, has the 'JSON List', as exported from the Database,
'got all the data you need for the web site'?

I think not.  For example the URL.

(from comment # 32)
> 0253          'url': 'http://get.adobe.com/reader/',
where there *is* a URL.


Schalk said on 2014-03-11 in
https://bugzilla.mozilla.org/show_bug.cgi?id=956905#c103
> ... the *real* testing can start now.

Some tests were reported in bug 1010132
https://bugzilla.mozilla.org/show_bug.cgi?id=1010132#c14


I also wonder if the 'detection logic'
that FOUND, and then used, the
> 0061      'adobeformacreaderfround': {
> 0062        'display_name': 'Adobe Acrobat NPAPI Plug-in',
> 0063        'description': 'Adobe Acrobat NPAPI Plug-in',
> 0064        'versions': {
section

for my Windows 7 visit
when it could have used the

> 1618      'adobe-reader': {
> 1619        'display_name': 'Adobe Reader',
> 1620        'description': 'Adobe PDF Plug-In For Firefox and Netscape',
> 1621        'versions': {
section.

(from comment # 30)
Schalk,
I agree with Carsten.
> > i think that was due the way plugincheck detects the plugin and we needed
> > that 2 ways to be safe
I speculate that detection for Mac vs Windows may have been the historic reason
for keeping seperate 'families of Adobe Reader / Acrobat' plugins in the database.

(from comment # 29 Schalk Neethling said)
> Thanks Carsten. It seems more and more to me that we can get rid of that
> duplication as Chrome is phasing out support for NPAPI plugins during the
> course o this year, and Fx itself has started doing that from release 30 but,
> as with my above comment, further testing is needed to be sure before dropping
> that data.

I also think you should not 'throw away' the data.
I'm NOT convinced it is "duplication".
You may need it for cases where the versions are different between
'Mac vs Windows'.


Finally,
I was expecting Adobe to release a new Reader on 2014-09-09
but Adobe have delayed the release: see

"Adobe Product Security Incident Response Team (PSIRT) Blog"
http://blogs.adobe.com/psirt/


DJ-Leith
Same comment applicable to a few areas of DJ-Leith's four-part posting...

Several times I saw reference to "Adobe" and "Adobe Acrobat" and "Adobe Reader", etc.  Way back in time when Adobe invented "PDF", their PDF generator program was called Adobe Acrobat -- but so was the reader!  (Today, it's just called "Reader", or formally "Adobe Reader".)  Let's make sure we're not confusing the two, or throwing out checks on one which should really apply to the other -- I don't think you can always count on their common plugins being exactly the same version or revision level.  

I'm currently running Reader 11.0.08 (from About - note: zero eight) but The Fox AddOn Manager tells me the plugin is "Adobe Acrobat 11.0.8.4" (note just eight, plus point 4), and the MORE link identifies the file as "NPPDF32.dll".  (Is this a 32-bit PDF plugin for "NPAPI"?)

I'm also using Adobe Acrobat (the PDF generator package) identified as "Adobe Acrobat 9.5.5" (from About).  FF AddOn tells me the plugin is 9.5.5.316 -- and MORE shows the file name is *also* called "NPPDF32.dll".

So two plug-ins: two different programs and two different versions yet same name ("Adobe Acrobat"), and same plugin name (NPPDF32.dll).  They are physically different files in the Adobe folders (one for the generator, one for Reader and Air).  But only one (for Reader) is inserted into my FF program's plugins folder -- and it happens to be the most recent file (probably not an accident).  But what if there are (or were) simultaneously two copies and/or two versions?  (That's what FF AddOn Mgr shows!)  You'd want to catch that and know one (or both, or neither) is OK or not OK.

To recap:
(1) Don't confuse the PDF generator and reader in references to "Adobe Acrobat" in case they're different.
(2) Don't toss out possibly valuable historical references.  (Reader is free, but the PDF generator is expensive -- as are a lot of good programs -- so some things may not be updated as frequently/ideally as we'd all like.
Thank you everyone for all of the effort you are putting into this and all of the information you are providing, I really appreciate it.

I am actively working on this now, I have all of the relevant data running locally and will be doing a ton of tests to determine how we can fix this once and for all.

I am also in contact with folks at Adobe to ensure we only cary data for versions that they still support (Reader and Flash) so we can really narrow down on where things are going awry.

I will update this bug as I progress towards a solution. Again, thank you for your time and effort, it is truly appreciated.
(In reply to Schalk Neethling from comment #35)
> Thank you everyone for all of the effort you are putting into this and
> all of the information you are providing, I really appreciate it.

You are welcome, we are all trying to improve the 'plugincheck service'.

I sometimes wonder if I am 'talking too much' / giving too much detail /
coming over as patronising.

Some of my writing is poorly written / difficult to follow.
Dan's comments are nice and clear.

I swither with providing:
'clues for Schalk to see'.
    Advantages
      - Schalk has been working on this this for many months.
      - Schalk already knows the code and the Database.
      - If 'Schalk gets it by discovery from the clue'
          he may well see how to apply the discovery elsewhere.
      - quick to write.
vs
'a long and involved explanation'.
    Advantages
      - In the long run, it should be possible for Schalk (and others)
          to follow the points made / reproduce the issue.
      - Have a better record for the future.     
    Disadvantages
      - slow for everybody to read.
      - some people will 'find it too much and switch off'.
      - some of my ideas may be 'barking up the wrong tree' and
          the good points may get 'lost in all the detail'.

I am better with pictures, which is why I have been attaching screenshots.

So, in the spirit of providing more helpful information / clarification
here are four more points.

1. An example of 'clues for Schalk to see', in this bug,

is I did NOT cite the
'JSON list' i.e.
"Plugincheck-Fx-34-build-aa315da-with-line-numbers-2014-09-10.txt"
> 0204        ],
> 0205        'url': '',
> 0206        'regex': [
> 0207        ]
> 0208      },

When I said (in comment # 33):

> C.
> Again, what you can NOT find is a "'url':" to collect a
> 'new Adobe reader' in this section of the 'JSON List'.
> By "this section" I mean the section starting:
> 0061      'adobeformacreaderfround': {

I now add:
Do you see the 'empty url' at line 0205?
Which is the end of the section that started at 0061.

What do you think the "regex" will do?

I speculate that each plugin section might need
a url and a regex and/or a literal.

Here is Silverlight:
> 4687      'microsoft-silverlight': {
> 4688        'display_name': 'Silverlight Plug-In',

> 4774        'mimes': [
> 4775          'application/x-silverlight',
> 4776          'application/x-silverlight-2'
> 4777        ],
> 4778        'url': 'http://www.microsoft.com/silverlight/get-started/install/default.aspx',
> 4779        'regex': [
> 4780          '.*Silverlight.*'

I don't know - but I think Schalk would know and understand.


2. "Adobe Acrobat" and "Adobe Reader".

(In reply to Dan Pernokis from comment #34)
I think it is very helpful to document the distinction between
"Adobe Acrobat" and "Adobe Reader":
I remember when Adobe had "Distiller" (to create PDFs from PostScript - in the early 1990s).

"Adobe Acrobat"
https://en.wikipedia.org/wiki/Adobe_Acrobat

Dan, you mentioned in comment # 34 that you had "Adobe Acrobat" as well
as "Adobe Reader".

In comment # 13 you said that you had other plugins too.

Please can you attach a screenshot, using Fx 32.0.1, showing all your plugins.
I think this will document how 'the versions numbers are detected',
and shown, on plugincheck.


I think it is excellent that Schalk has already chosen a good "display_name"
for 'Reader', i.e. "Adobe Reader" in the 'new plugincheck - uses the JSON List'.

From the 'JSON List' 
> 1618      'adobe-reader': {
> 1619        'display_name': 'Adobe Reader',
> 1620        'description': 'Adobe PDF Plug-In For Firefox and Netscape',


3. More detail on the versions.

From bug 1053417 "Adobe Reader for Windows - plugins vulnerable 2014-08-12 - APSB14-19"

******
Note: only the Windows version was released / declared vulnerable.
Plugincheck would *need* to keep track of the Mac version as a separate plugin.
******

> Security Updates available for Adobe Reader and Acrobat
> Release date: August 12, 2014
> Vulnerability identifier: APSB14-19
> http://helpx.adobe.com/security/products/reader/apsb14-19.html
> 
> > Adobe has released security updates for Adobe Reader and Acrobat XI (11.0.07)
> > and earlier versions for Windows. These  updates address a vulnerability that
> > could allow an attacker to circumvent sandbox protection on the Windows
> > platform.  Adobe Reader and Acrobat for Apple's OS X are not affected.
> ... lower down
> 
> > For users of Adobe Reader X (10.1.10) and earlier versions for Windows,
> > who cannot update to version 11.0.08, Adobe has made available version 10.1.11.
> This ESR version would be for bug 986588
> I don't think the 'detection and reporting of the ESR verson of Adobe reader'
> is working on the 'Plugincheck service' but I think is should. 
> 
> Please add the plugins to the Database.

Here is a screenshot of "Adobe Reader XI (11.0.07)", to use *Adobe's* name
in their security advisory.
https://bug1053417.bugzilla.mozilla.org/attachment.cgi?id=8475528
The vulnerable version "11.0.7.79" was STILL being detected in error
as "Up to Date", because the Database had not been updated,
until 2014-08-27.

I speculate that Adobe use "11.0.7" (or 11.0.07) - the first 3 positions - as
the 'version with feature set'.
The full version "11.0.7.79" uses 'all four positions'.

In my opinion it is good for plugincheck to show the 'most detailed version',
in this case "11.0.7.79".


Here is my "about:plugins" for 'Adobe Reader' on Windows 7, 64bit OS
(called "Adobe Acrobat").

> Adobe Acrobat
>     File: nppdf32.dll,nppdf32.dll
>     Path: C:\Program Files (x86)\Adobe\Reader 11.0\Reader\AIR\nppdf32.dll,C:\Program 
Files (x86)\Adobe\Reader 11.0\Reader\browser\nppdf32.dll
>     Version: 11.0.8.4
>     State: Enabled
>     Adobe PDF Plug-In For Firefox and Netscape 11.0.8

Note:
>     Adobe PDF Plug-In For Firefox and Netscape 11.0.8
could be the 'version with feature set' and
>     Version: 11.0.8.4
could be the 'true file version'.


As we have seen, both the 'correct detection'
https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8472634
and the 'WRONG detection'
https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8472630
can 'see and report in the "Status" column the 'true file version' - "11.0.8.4".

The 'JSON List', which has 'come from the Database', has "11.0.8.0"

> 1686          'win': {
> 1687            'latest': [
> 1688              {
> 1689                'status': 'latest',
> 1690                'version': '11.0.8.0',
> 1691                'detected_version': '11.0.8.0',
> 1692                'detection_type': '*',
> 1693                'os_name': 'win',
> 1694                'platform': {
> 1695                  'app_id': '*',
> 1696                  'app_release': '*',
> 1697                  'app_version': '*',
> 1698                  'locale': '*'

Schalk,
I speculate that the 'detection logic',
in 'plugincheck using enumeration'  might find "11.0.8.4"
as 'newer' than "11.0.8.0" and so 'report' it as "Up to Date".

So, I think the 'data in the Database' is OK on this
narrow point (about 
bug 1053417 "Adobe Reader for Windows - plugins vulnerable 2014-08-12 - APSB14-19")

Talking of 'newer', I am reminded of bug 956905 comment # 128

> *** 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.
There is more in that post.


I think Adobe also use the same concept for Flash.
I mean, this could account for 'variations in the last part of the version'.

Bug 1053409 "Adobe Flash Player - plugins vulnerable 2014-08-12 - APSB14-18"
> Security updates available for Adobe Flash Player
> Release date: August 12, 2014
> Vulnerability identifier: APSB14-18
> http://helpx.adobe.com/security/products/flash-player/apsb14-18.html
> 
> Adobe Flash Player
> http://www.adobe.com/software/flash/about/
> 
> The about page - lists current versions.
> 
> Note: the versions are different for Windows vs Mac vs Linux
> AND ALSO vs browser.
> 
> Please add the plugins to the Database.
> 
> I can't find a bugzilla bug for this but I have seen, today 2014-08-13,
> Pluging check report:
> 14.0.0.145 - on Windows 7 - on Fx 31 and Fx 33 "vulnerable" – correct.
> 14.0.0.179 - on Windows 7 - on Fx 31 and Fx 33 "Up to Date" (with green button) - correct.
> 14.0.0.176 - on Windows 7 - on Internet Explorer 9 (32bit) "Up to Date"
> (on a blue button - why blue not green?) - correct.


Here we see Adobe used 14.0.0.176 and 14.0.0.179.
I speculate Adobe may 'think of this' as 'Flash 14 ver 17' and the previous version
as 'Flash 14 ver 14'.

FYI,
The "blue not green" in IE point
https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8472632
became bug 1054280 "Ensure consistent button colors across browsers".


4. Shockwave for Director and Flash Player
Another example where there are two plugins which may
'provide a similar service to the browser'
(and may even use the same MIME type)
and which may be difficult for the 'plugincheck service'
to give accurate reports.

Java 7 vs Java 8 was similar.
(From bug 985968 comment # 40) at "E." (in the 41st comment). 
> E. 
> >  41             'status': 'latest',
> >  42             'version': '1.8.0.0',
> >  43             'detected_version': '1.8.0.0',
> This is Java 8 (1.8.0.0) AKA "11.0.2.132".
> 
> This was 'detected' (as noted in bug 985968 comment # 38) as "11.0.2.132".
> > User "dff_gv" on 2014-03-20 in the thread
> > https://support.mozilla.org/en-US/questions/990988
> > 
> > has posted this screenshot
> > https://support.cdn.mozilla.net/media/uploads/images/2014-03-20-16-21-06-8eebd3.png

This screenshot (taken in April 2014)
Shows "Shockwave for Director" and "Shockwave Flash" as well as other plugins.
This is the 'plugincheck using enumeration'.

I am posting the link to the screenshot here for two reasons:

A. Oracle has 'more than one way to name their Java files'.

In order for the 'plugincheck detection of Java' to work, Schalk has to use
the "1.8.x.x" (which is ONE way Oracle describe 'Java 8').

B. To show that Shockwave for Director and Flash Player are different.

In bug 956905 comment # 127
I attached "Adobe Flash versions in 2013.pdf"
https://bug956905.bugzilla.mozilla.org/attachment.cgi?id=8395239
and I discussed it in a very long post - bug 956905 comment # 128
There is lots of detail about Flash Player, ESR for Flash Player,
and Shockwave for Director.

See bug 1062236 for a recent example where john ruskin found
Adobe's 'file version names' confusing.

DJ-Leith
For DJ-Leith - enumeration of MY plugins
For DJ-Leith - enumeration of MY plugins (plugin list)
For DJ-Leith - enumeration of MY plugins (extensions list, if interested too)
@DJ-Leith:

See screenshots above for enumeration of my add-ons, etc.  I already knew that FLASH is legitimately out of date today, so I captured it that way for you.  (New comes back as 15.0.0.152 (15.0 r0)).

Interesting discovery: my screen annotation addon which normally works beautifully suddenly quit on the FF Addons page.  Works elsewhere, works flaky and intermittently on the FF pages for some reason.

My concern about version matching:  11.0.8 and 11.0.08 may be the same in value (08 is 8, eight is 
eight), but might not be equal in some string operations like a match (0 vs 8, or 08 vs 8 blank).

Adobe Acrobat PDF generator still uses distiller, I think.  I have that in my Adobe Suite and I see popups of distiller doing things during some PDF generations (typically large docs with graphics or pics).

And don't worry about writing too much!  Better to get it out fully than to be too vague.  I personally don't follow it in detail because, although I'm a programmer, I don't know the specific language, and I'm not well versed on the internals of FF and TB.  But those who do understand need to know that level of detail.
Dan, thanks very much for posting the screenshots (including before you updated Flash).

(In reply to Dan Pernokis from comment #40)
> My concern about version matching:  11.0.8 and 11.0.08 may be the same in
> value (08 is 8, eight is eight), but might not be equal in some string operations
> like a match (0 vs 8, or 08 vs 8 blank).
Indeed, this might well be a consideration.

The 'detection code' will have to work with 'the data as detected'.
This may well be: "11.0.8.0" or 'newer' is OK
and so
'present an "Up to Date" button' for the case of 'version "11.0.8.4" was detected'.


I am still interested to know 'what can people see on a Mac'.

(from comment # 30)
So, can anybody confirm 
> Is "Adobe Acrobat NPAPI Plug-in" being reported using Fx 32 on a Mac?

Schalk, what can you see?

FYI,
If I 'spoof a Mac Fx 31' - to test 'plugincheck using enumeration', by UA spoof.

user_pref("general.useragent.override", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:31.0)
Gecko/20100101 Firefox/31.0");

I get the same result as a Windows 7 using Fx 32
(i.e. "Adobe Acrobat", 11.0.8.4, "Up to Date",
there are "unknown" plugins and NO "Adobe Acrobat NPAPI Plug-in").
This may well NOT be a good test.
A *better* test would be to use a real Mac.


Looking at the screenshots that Dan attached is interesting.

https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8489041
Dan has 3 "Adobe ..." plugins [plus Flash, also from Adobe],
15 plugins in total.

'Adobe Reader' called "Adobe Acrobat 11.0.8.4"
'Adobe Acrobat', the real Acrobat that can write PDF files, called "Adobe Acrobat 9.5.5.316"
'AdobeAAMDetect 1.0.0.0'.  I speculate he has this as part of "Adobe Acrobat 9.5.5.316"

i.e. from "Adobe Suite".
From comment # 40
> Adobe Acrobat PDF generator still uses distiller, I think.  I have that in my Adobe Suite
> and I see popups of distiller doing things during some PDF generations (typically large
> docs with graphics or pics).

"Creative Cloud Help"
http://helpx.adobe.com/creative-suite/kb/troubleshoot-creative-cloud-installation-download.html
> ... ...
> The Adobe Application Manager installs the AdobeAAMDetect plug-in to your web browser.
> To function properly, this plug-in requires that the web browser is restarted. If the 
> web browser has not been restarted, the plug-in is not detected prompting you to
> download Adobe Application Manager again.
> 
> The plug-in allows you to select a product on the Creative Cloud website and have the
> information passed on to the Adobe Application Manager.

Dan's Fx 32.0.1 'plugincheck using enumeration' screenshot
https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8489040
only has
'Adobe Reader' called "Adobe Acrobat 11.0.8.4", which is "Up to Date" - GOOD and
"AdobeAAMDetect" 1.0.0.0 which is "unknown".
BUT
"Adobe Acrobat 9.5.5.316" was not detected at all, not even "unknown"!

There are 14 in total, so this is the only 'missing one'.
I do like the "unknown" plugins
(see bug 965812 about how to cope without the "unknown" plugins).


Dan,

have you ever done a plugincheck using the 'new plugincheck - uses the JSON List'?

It would be interesting to see how Silverlight is reported.
  See the 'JSON List' and the fragment, about Silverlight,  in comment # 36.
I anticipate that only 7 of your plugins will be reported.

Easy to do - two methods.
A. Use Beta+ (I use Aurora).
B. Spoof the UA.
If you spoof the UA you might want to do this in a separate Profile [1].

On Windows 7, the 'UA spoof for Beta' is:
user_pref("general.useragent.override", "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0)
Gecko/20100101 Firefox/33");

You have to "about:config", make a new String called "general.useragent.override"
then make this string the UA, e.g. "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0)
Gecko/20100101 Firefox/33".

Once you have the "general.useragent.override" setting you can edit the
"rv:33.0" and "/33" to any version you want to 'pretend to be'.

DJ-Leith

[1] Some References for Profiles

https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

http://kb.mozillazine.org/Profile_Manager


I frequently have more than one instance of Firefox running.

http://kb.mozillazine.org/Opening_a_new_instance_of_your_Mozilla_application_with_another_profile

All in separate Profiles.
They all use the same "plugins" - "plugins" are 'machine wide'.
However, each Profile has their own 'set of Extensions'.
I also have different "about:config" settings, per Profile.

All instances are started, using shortcuts, to their specific Profile. 
http://kb.mozillazine.org/Starting_your_Mozilla_application_with_a_specified_profile
For DJ-Leith:  FireFox plugin-checker in FF 32.0.1 BEFORE faking UA FF/33.0

Note that Shockwave Flash is still legitimately vulnerable (not yet updated).
Note that Adobe NPAPI is not shown, neither here nor in the list of plugins.
For DJ-Leith:  FireFox plugin-checker in FF 32.0.1 while faking UA FF/33.0

Note that Shockwave Flash is still legitimately vulnerable (not yet updated).
Note that Adobe NPAPI is now visible and vulnerable, and my usual "Adobe Acrobat" (presumably reader) plugin is now absent.  Versions are identical -- I would guess same file, different names/titles.
@DJ-Leith:
Thanks for the instructions on setting up the fake UA -- worked like a charm.  (I'm generally hesitant to mess with my production system, but this was safe enough.)


@everyone:

From DJ's comment describing my plugins: 
>> 'Adobe Reader' called "Adobe Acrobat 11.0.8.4"
>> 'Adobe Acrobat', the real Acrobat that can write PDF files, called "Adobe Acrobat 9.5.5.316"
>> 'AdobeAAMDetect 1.0.0.0'.  I speculate he has this as part of "Adobe Acrobat 9.5.5.316"

"Adobe Acrobat 9.5.5.316" may have been the original PDF reader plugin -- recall what I said in Comment #34 about Adobe using the same name for both programs.  It has always been there and never changed as far as I recall.  Adobe Reader 9 ("IX") was current when I got this system in 2010 and was first able to use The Fox.  Adobe Acrobat 9 (PDF generator) was the new addition to the Adobe Suites which I also installed shortly after.  So it wouldn't surprise me if subsequent Reader X and XI simply didn't overwrite it for some reason (possibly because they detected Acrobat).


Adobe Background Info (FYI)

Adobe sells several Suites based around PhotoShop, from an small expensive package ($ hundreds) to a complete deluxe tome that costs over $2500.  Most of these packages include Adobe Acrobat (PDF generator) -- but it is not fully integrated into the suites.  It comes as a separate disk, separate install, etc -- just as though purchased standalone -- because it is intended to run with everything in the world (including the suites) and it needs to be updated separately.

Reader and generator share some common stuff, and they each have an "update" function under HELP.  The rest of the suite programs are integrated -- common installation, one menu of launchers, and the Adobe Applications Manager ("AAM") which does the update function.  I'm not aware of any plugins for specific products of the suites, but AAM was revised in suites v5.5 and that's when I first saw the "AdobeAAMDetect" FF plugin.  Don't know why it's there or what it's used for -- programs each have an update choice that runs the common AAM program.  I'm still running suite version 5 (suite versions are just marketing numbers -- the individual products each have their own versions far higher than 5 or 6) but the AAM is common and backward applicable.

All to explain that I don't think AdobeAAMDetect is going to cause any immediate trouble, especially since it comes up as "unknown".

-dan-
Dan,

Thanks again, for posting more screenshots (in comment # 43 and 42).

From comment # 41
> It would be interesting to see how Silverlight is reported.
>   See the 'JSON List' and the fragment, about Silverlight,  in comment # 36.
> I anticipate that only 7 of your plugins will be reported.

First,
some good news - Silverlight
is being reported as "5.1.30514.0" and "Up to Date" on *both*

'plugincheck using enumeration' - Dan's plugins (from comment #42)
https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8489163

and the 'new plugincheck - uses the JSON List' - Dan spoofed the UA to Fx 33
https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8489164


Second,
less good news, only 6 are reported (not 7) in 'new plugincheck - uses the JSON List'.

"VLC Web Plugin" version "2.1.0.0" is NOT reported.

Why?
Look at the 'JSON List'.

https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8487601
> 4937      'videolan-vlc': {
> 4938        'display_name': 'VLC Multimedia Plug-in',
> 4939        'description': '',
> 4940        'versions': {
> 4941          'all': {
> 4942            'latest': [
> 4943              {
> 4944                'status': 'latest',
> 4945                'filename': 'npvlc.dll',
> 4946                'version': '2.1.0.0',
> 4947                'detected_version': '2.1.0.0',
> 4948                'detection_type': '*',
> 4949                'os_name': '*',
> 4950                'platform': {
> 4951                  'app_id': '*',
> 4952                  'app_release': '*',
> 4953                  'app_version': '*',
> 4954                  'locale': '*'
> 4955                }
> 4956              }
> 4957            ],
> 4958            'vulnerable': [
> 4959              {
> 4960                'status': 'vulnerable',
> 4961                'name': 'VLC Web Plugin',
> 4962                'vulnerability_description': 'Vendor information',
> 4963                'vulnerability_url': 'http://www.videolan.org/security/sa1302.html',
> 4964                'filename': 'npvlc.dll',
> 4965                'version': '2.0.2.0',
> 4966                'detected_version': '2.0.2.0',
> 4967                'detection_type': '*',
> 4968                'os_name': '*',
> 4969                'platform': {
> 4970                  'app_id': '*',
> 4971                  'app_release': '*',
> 4972                  'app_version': '*',
> 4973                  'locale': '*'
> 4974                }
> 4975              }
> 4976            ]
> 4977          },
> 4978          'win': {
> 4979            'latest': [
> 4980            ],
> 4981            'vulnerable': [
> 4982            ]
> 4983          },
> 4984          'mac': {
> 4985            'latest': [
> 4986            ],
> 4987            'vulnerable': [
> 4988            ]
> 4989          },
> 4990          'lin': {
> 4991            'latest': [
> 4992            ],
> 4993            'vulnerable': [
> 4994            ]
> 4995          }
> 4996        },

I made my 'quick prediction' of "only 7 of your plugins will be reported" based on
'I know there will be no "unknown" so I expect a MAXIMUM of 7' without checking either
the 'JSON List' or the 'list of plugins' that Schalk was going to track.

  See:
  Schalk Neethling, on 2014-02-23, in bug 956905 comment # 75
  which listed 37 plugins.  These include:
  > string(22) "VLC Multimedia Plug-in"  

So, the 'inability to detect and report on the "VLC Multimedia Plug-in"
in the 'new plugincheck - uses the JSON List'
is NOT because there is no "VLC Multimedia Plug-in" data in the JSON List.

Note:
> 4978          'win': {
to
> 4996        },
looks 'empty'.  

Schalk, I have not researched the "VLC Multimedia Plug-in".
I speculate that the web site 'detection code' might need some
data in the relevant 'OS section'.

I don't know which OSs can use the "VLC Multimedia Plug-in".

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


About the "Adobe Acrobat 9.5.5.316".

From comment # 41
> Dan's Fx 32.0.1 'plugincheck using enumeration' screenshot
> https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8489040
> only has
> 'Adobe Reader' called "Adobe Acrobat 11.0.8.4", which is "Up to Date" - GOOD and
> "AdobeAAMDetect" 1.0.0.0 which is "unknown".
> BUT
> "Adobe Acrobat 9.5.5.316" was not detected at all, not even "unknown"!
> 
> There are 14 in total, so this is the only 'missing one'.

I speculate that a possible reason why "Adobe Acrobat 9.5.5.316" is not detected by
either
'plugincheck using enumeration'
or
'new plugincheck - uses the JSON List'
is because

in 'plugincheck using enumeration' a regex and/or a literal is used to 'look for'
"Adobe Acrobat".

BOTH
'Adobe Reader' called "Adobe Acrobat 11.0.8.4"
and
"Adobe Acrobat 9.5.5.316", the paid for software that can create PDF files,
are named, by *Adobe*, "Adobe Acrobat".

I speculate that the 'Plugincheck Database' has ONLY been tracking
the 'Reader', given away at no cost, plugin.

While, I think it would be very good if the 'plugincheck service'
matched "about:plugins", in the 'actual plugins detected', (even if
plugincheck then said "unknown", meaning, 'not tracked - use another way
of checking these "unknown" plugins')
there are already some plugins,
particularly ActiveX plugins for Internet Explorer, that are
not reported at all, i.e. they are not even "unknown".

One plugin that is coming in Firefox 33 is Openh264.

See
bug 1052069 "Add Openh264 Video Codec provided by Cisco Systems, Inc. to Plugincheck"
As I write, I don't expect the 'plugincheck service' will 'test' / 'assess' this plugin.

About AdobeAAMDetect.
I mainly commented on this to note that Dan had it.
Dan said, in comment # 44:
> I don't think AdobeAAMDetect is going to cause any immediate trouble ...

Remember, the scope of plugincheck is to 'help users stay safe by not using
old, vulnerable, plugins'.  It can't test everything.

To avoid 'scope creep' it would be good to test
ALL the 37 plugins listed in bug 956905 comment # 75.

Once ALL of them are 'reported correctly' on the 'new plugincheck - uses the JSON List'
I would then advocate that ESR Versions are added, e.g. ESR Flash.

See bug 956905 comment # 148 for more 'To Do' items.
Some of these 'To Do' items could be done in parallel with this bug, possibly by 'QA folk'.

DJ-Leith
How does FF know which plugins it has?  I see Registry Entries with everything I have, one entry per plugin (plus two obsolete VLC entries), and each entry has a path to the plugin, its description, version ID, etc.  But does it maintain its own list too?  I see only a few files (far from all) in the FF plugins folder.  There are also oddities (different versions, etc) among the list of plugins and the two plugin checks (old and new).  (BTW - where can I get the notorious "JSON List"?)


Regarding VLC:

Where does the VLC "2.1.0.0" come from???  I'm actually running 2.1.2 -- and the registry has entries for 2.0.8, 2.1.1, and 2.1.2 -- no "2.1.0.0" which is what MORE calls it too (along with video type detail that it has to dig from somewhere).

BACKGROUND on VLC:  See my Bug 915323 -- there was a raging battle at the time between VLC and MOZ on how plugins were being checked back then.  In this case, the plugin 2.0.6 was safe but the VLC 2.0.6 library had issues.  Updating upgraded the library to 2.0.8, but not the plugin which remained at 2.0.6.  All safe, but FF still said "vulnerable".   Could be that MOZ people at the time just decided let FF ignore checking on it because there was no way to validate what the user really had.  (You could only look so far -- to the plugin, not to the library itself.)  So now, today, with 2.1.2, is this perhaps the same situation that the plugin version lags the library again, so the check just ignores it altogether?  It does not make logical sense to me that the two should be out-of-sync.


Regarding my Adobe Acrobat (PDF generator, paid version) plugin "9.5.5.316":

I said that it was installed by Acrobat 9 when I purchased & installed one of the Adobe Suites.  I have not *upgraded* Acrobat -- only updated a few times as Adobe issues its quarterly updates for Reader & Acrobat (Reader XI and Acrobat 9 in my case).  Adobe still supports a few versions back (9 in this case), so the plugins etc should be "current" (as in: 'latest of that vintage but not necessarily most recent', as DJ might put it).

So if someone doesn't upgrade their software but keeps it "current" (up-to-date), the FF plugin checker should still test and validate it.  If it was an unsupported product & plugin (say, version 8), then it makes sense to note it as "Unknown" (or perhaps "Obsolete" or "Unsupported") -- and to warn "Vulnerable" (or worse) if *known* to be so.

Maybe Adobe just abandoned the Acrobat 9 plugin -- erased it from FF's knowledge but didn't remove it totally.  The entry IS listed in the registry as 9.5.5.136, and that plugin does exist in Adobe Acrobat.  But the Adobe Reader XI plugin (11.0.8) is actually placed in the FF plugins folder.  I can't tell which plugin is actively being used -- or if/whether the internal FF PDF reader is being used.  It's scary to think I might in fact be running a vulnerable Version 9 common Adobe plugin while the checker blindly looks at the Version 11 (XI) plugin and says it's OK.


And one more thing...
FLASH is reported in the list of plugins as "Shockwave Flash" and the plugin check, but gets called "Adobe Flash" in the new checker.  (You probably know that Adobe purchased Shockwave 'way back -- so the original name persists.)  This probably needs to be made consistent too -- for any software in the same boat.

-dan-
Dan, you asked:
> (BTW - where can I get the notorious "JSON List"?)

I have attached it in comment # 33.
https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8487601
I called the file
"Plugincheck-Fx-34-build-aa315da-with-line-numbers-2014-09-10.txt".

Anybody can get a 'live version of the JSON List', like the one linked above,
direct from Mozilla, as I described in comment # 33:

> So, the 'JSON List' is here:
> https://plugins.mozilla.org/en-us/plugins_list.json
> 
> The actual 'line numbers as seen in Scratchpad' may now
> be different.
> 
> Steps to read the JSON:
> 1. browse to https://plugins.mozilla.org/en-us/plugins_list.json
> 2. click once in the JSON and then <ctrl>+<a> (to select all)
> 3. <ctrl>+<c> (to copy)
> 4. <shift>+<F4> to open Scratchpad
>  (or use the mouse to Firefox, Tools, Web Developer, Scratchpad)
> 
> 5. click at the 'line 9', and <ctrl>+<v> (paste).
> You will have one *huge* line.
> 
> 6. click "Pretty Print" button, and you will have the JSON in a much
> more 'human readable' form (with line numbers).
> 
> Like the 
> "Plugincheck-Fx-34-build-aa315da-with-line-numbers-2014-09-10.txt"
> there are 5428 lines in the 'JSON List' (including the 8 lines of comment at the top).


Dan asked, in comment # 46:
> How does FF know which plugins it has? 
You can get information about how *Firefox* 'knows which plugins it has'
(not the plugincheck web site)
by doing "about:plugins".

"about:plugins" should, because it is running inside your Firefox with more privileges,
potentially find MORE information about how 'Firefox sees the plugins for Firefox to use'
than a website, out on the Internet.

It will not find 'plugins for Internet Explorer', which are ActiveX files, for example.


The plugincheck web site, on the other hand, can use various methods to try and 'detect'
the plugins that the 'visiting browser' has.

See the "Short History" in bug 956905 comment # 148 for more information. 

The 'plugincheck using enumeration' method, the method used from the beginning of
the 'plugincheck service', has always been 'enumerating over the visiting browser's plugins'.

Then, for each 'plugin found' it is tested against 'known plugin data from the Plugin Database'.
The advantage of this method is that the 'plugincheck using enumeration' method can find
"unknown" plugins.

The disadvantage, from a privacy and fingerprinting point of view, is
'if plugincheck can enumerate my plugins' then so can 'other websites'.

Potentially *any* website you visit can do this: see bug 952914.

I personally have been browsing for months with
the user pref
"plugins.enumerable_names" set to "" (empty string) - so no site can enumerate ANY of my plugins.

On some web sites I set it to "Shockwave" (to allow the site to detect my Flash).
On 'plugincheck using enumeration', on a Fx 32.0.1 Profile, I set it to "*"
which means 'Yes please, I allow you to enumerate all my plugins'.

In comment # 36 I said:
> Here is my "about:plugins" for 'Adobe Reader' on Windows 7, 64bit OS
> (called "Adobe Acrobat").
> 
> > Adobe Acrobat
> >     File: nppdf32.dll,nppdf32.dll
> >     Path: C:\Program Files (x86)\Adobe\Reader 11.0\Reader\AIR\nppdf32.dll,C:\Program 
> >             Files (x86)\Adobe\Reader 11.0\Reader\browser\nppdf32.dll
> >     Version: 11.0.8.4
> >     State: Enabled
> >     Adobe PDF Plug-In For Firefox and Netscape 11.0.8 

So, this is the 'Adobe Reader' plugin
(I have never had the 'full cost Adobe Acrobat that can create PDFs' installed on this PC).

My
"C:\Program Files (x86)\Adobe\Reader 11.0\Reader\browser\nppdf32.dll"
Has, using Windows Explorer, properties, "Details" Tab,

> File description    Adobe PDF Plug-In For Firefox and Nets...
> Type                Application extension
> File version        11.0.8.4 <== both methods of 'plugincheck website detection',
                                        by enumeration and 'using the JSON List'
                                        report this as "11.0.8.4"
> Product name        Adobe Acrobat   [this choice of name is Adobe's choice]
> Product version     11.0.8.4        [same as "File version"]
> Copyright           Copyright 2000-2012 Adobe Systems Inc...
> Size                222 KB
> Date modified       05/08/2014 18:20 (UK date, i.e. 5th August 2014 6:20 pm) 
> Language            English (United States)  [common for software in UK to have US version]
> Original filename   NPPDF32.DLL 

Dan, your "FF-32-0-1_PluginChecks_14Sept2014_(before-fake-UA).png" from comment # 42
https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8489163
also shows your 'Adobe Reader' plugin, which Adobe call "Adobe Acrobat" in their File Name.
It is 11.0.8.4 too.

Dan, I don't think 'plugincheck using enumeration' has EVER 'found'
the expensive full "Adobe Acrobat" plugin.  I don't see any issue with you
having "Adobe Acrobat 9.5.5.316".  My comments have only been about,
I found it noteworthy that, 'plugincheck using enumeration' could not even
report it as "unknown".

I said, in comment # 45
> I speculate that a possible reason why "Adobe Acrobat 9.5.5.316" is not detected by
> either
> 'plugincheck using enumeration'
> or
> 'new plugincheck - uses the JSON List'
> is because
> 
> in 'plugincheck using enumeration' a regex and/or a literal is used to 'look for'
> "Adobe Acrobat".

So, the people who wrote the code for the 'plugincheck service'
have not found a way to differentiate between the two (they may never
have attempted to do this).

It might be difficult because Adobe still call the 'Reader', I quote
"Product name  Adobe Acrobat" in the actual file "NPPDF32.DLL".

> Product name        Adobe Acrobat   [this choice of name is Adobe's choice]

I would not be surprised if the actual file, that is the plugin for,
"Adobe Acrobat 9.5.5.316" had the metadata "Product name  Adobe Acrobat" too.
So I expect that both are called, by Adobe, "Adobe Acrobat" in the File Name metadata.


If, for example, you wanted to track 'Flash' and 'ESR Flash'
you might have to 'track them almost as if they were separate plugins'
BECAUSE it would be hard to tell the two versions apart
AND you would NOT want to declare "vulnerable" an 'older looking - by version number',
'ESR version of Flash'.


For differentiation between various versions of Java files
Schalk has had to use the
1.5.x.x for Java 5 family
1.6.x.x for Java 6 family
1.7.x.x for Java 7 family
1.8.x.x for Java 8 family

From the 'JSON List'
> 3150      'redhat-icetea-java': {
> 3151        'display_name': 'IcedTea Java Web Browser Plugin',
> 3152        'description': '',
> 3153        'versions': {
> 3154          'all': {
> 3155            'latest': [
> 3156              {
> 3157                'status': 'latest',
> 3158                'version': '1.6.0.0',
> 3159                'detected_version': '1.6.0.0',
> 3160                'detection_type': 'original',

I looks, to me, as if for the 'NON icetea-java' the "1", from the "1.x.x.x", has been 'stripped off'.
This might be deliberate, to tell the difference between the Oracle / Sun Java
from the Redhat Java.  I don't know.  The 'JSON List' is 'just the data we need to
do the job at plugincheck'. It is NOT 'all the data in the Database'.

> 3299      'java-runtime-environment': {
> 3300        'display_name': 'Java Runtime Environment',
> 3301        'description': '',
> 3302        'versions': {
> 3303          'all': {
> 3304            'latest': [
> 3305              {
> 3306                'status': 'latest',
> 3307                'version': '.8.0.11',
> 3308                'detected_version': '.8.0.11',
> 3309                'detection_type': '*',
> 3310                'os_name': '*',
> 3311                'platform': {
> 3312                  'app_id': '*',
> 3313                  'app_release': '*',
> 3314                  'app_version': '*',
> 3315                  'locale': '*'
> 3316                }
> 3317              },
> 3318              {
> 3319                'status': 'latest',
> 3320                'version': '.7.0.67',
> 3321                'detected_version': '.7.0.67',
> 3322                'detection_type': '*',
> 3323                'os_name': '*',
> 3324                'platform': {
> 3325                  'app_id': '*',
> 3326                  'app_release': '*',
> 3327                  'app_version': '*',
> 3328                  'locale': '*'
> 3329                }
> 3330              },
> 3331              {
> 3332                'status': 'latest',
> 3333                'version': '.6.0.81',
> 3334                'detected_version': '.6.0.81',
> 3335                'detection_type': '*',
> 3336                'os_name': '*',
> 3337                'platform': {
> 3338                  'app_id': '*',
> 3339                  'app_release': '*',
> 3340                  'app_version': '*',
> 3341                  'locale': '*'
> 3342                }
> 3343              },
> 3344              {
> 3345                'status': 'latest',
> 3346                'version': '.5.0.71',
> 3347                'detected_version': '.5.0.71',
> 3348                'detection_type': '*',
> 3349                'os_name': '*',
> 3350                'platform': {
> 3351                  'app_id': '*',
> 3352                  'app_release': '*',
> 3353                  'app_version': '*',
> 3354                  'locale': '*'
> 3355                }
> 3356              }
> 3357            ],
> 3358            'vulnerable': [
> 3359              {
> 3360                'status': 'vulnerable',
> 3361                'vulnerability_description': 'Oracle Critical Patch Update Pre-Release
Announcement - July 2014',
> 3362                'vulnerability_url': 
'http://www.oracle.com/technetwork/java/javase/8u11-relnotes-2232915.html',
> 3363                'version': '.8.0.5',
> 3364                'detected_version': '.8.0.5',
> 3365                'detection_type': '*',
> 3366                'os_name': '*',
> 3367                'platform': {
> 3368                  'app_id': '*',
> 3369                  'app_release': '*',
> 3370                  'app_version': '*',
> 3371                  'locale': '*'
> 3372                }
> 3373              },
> 3374              {
> 3375                'status': 'vulnerable',
> 3376                'vulnerability_description': 'vendor information',
> 3377                'vulnerability_url': 
'http://www.oracle.com/technetwork/topics/security/cpuapr2014-1972952.html',
> 3378                'version': '.8.0.0',
> 3379                'detected_version': '.8.0.0',
> 3380                'detection_type': '*',
> 3381                'os_name': '*',
> 3382                'platform': {
> 3383                  'app_id': '*',
> 3384                  'app_release': '*',
> 3385                  'app_version': '*',
> 3386                  'locale': '*'

Java continues down to line 3851

> 3841          'application/npruntime-scriptable-plugin',
> 3842          'application/java-deployment-toolkit'
> 3843        ],
> 3844        'url': 'http://www.java.com/en/download/manual.jsp',
> 3845        'regex': [
> 3846          'Java Embedding Plugin .*',
> 3847          'Java.* Platform SE.*',
> 3848          '.*Java Deployment Toolkit.*',
> 3849          'Java.* Plug-.*'
> 3850        ]
> 3851      },

Dan, I'll think about your other points in comment # 46 when I come back
from work on 17th September.

DJ-Leith
An oddity:  Yesterday I set up a new profile in FF that I could use to fake the UA.  Today I noticed that FF had sudden;y become the default OPEN program for extension "PDF".  This seems more than a co-incidence to me -- the PDF file type has been stable for years, and I haven't done any other internal settings changes to FF in ages.  Do you guys want this written up as a separate bug?  Or just keep it as a note for now?


@DJ-Leith:
So the JSON list is really a JS file with the various names and item-specific match mechanisms.

Also, I used about:plugins -- it shows the info that MORE shows, but I still don't know where this info comes from (where stored), and it doesn't tell me where the list of plugins is kept.  How does ABOUT know what (which plugins) to display?  Is this taken from the info I see in the registry (Mozilla Plugins)?  If so, why doesn't it include the old VLC entries and how does it find the new (2.1.2) entry?


Your latest comments on Adobe 9.5.5.136:
>> I don't think 'plugincheck using enumeration' has EVER 'found'
>> the expensive full "Adobe Acrobat" plugin.  I don't see any issue with you
>> having "Adobe Acrobat 9.5.5.316".  My comments have only been about,
>> I found it noteworthy that, 'plugincheck using enumeration' could not even
>> report it as "unknown".

My concern about Adobe 9.5.5.136 is:  Reader 9 went through its series of vulnerabilities before moving on to versions 10 (Reader X) and 11 (Reader XI) and their respective idiosyncrasies.  Acrobat 9 did as well (usually in parallel), but obviously stopped at 9.5.5.  I just hope that *that* version is current enough and not vulnerable -- which most likely is *not* the case.  That's why it would be good (for me) if this plugin is not being used -- and why I'd like to see proof positive ('FF sees the plugin and chooses to totally ignore it') rather than proof negative ('FF plugincheck doesn't see it in the list, therefore it doesn't exist, but executable FF still might see it and use it anyway').

In other words:  There may be a bug in the plugincheck that misses it -- not good, but you guys can fix this.  Or it may not be listed fully wherever it is the pluginchecks look to see -- so back to my question, how does FF KNOW where to look? -- in this case, might be unique to my installation, or just as likely, it's how Adobe updated millions of users, by doing only part of the job that time.  Also not good, but user fix is tricky and not for the faint of heart -- requires deleting file(s), perhaps removing registry entries, and updating that FF list where things are stored.

-dan-
Wanted to give a heads up that I am working on getting a development instance up and running so that we can iterate more quickly to fix bugs sooner, and get the end result into production quicker.

I believe I have made great strides in terms of improving Reader/Acrobat reporting in beta+ versions of Firefox so, as soon as I have this development instance up and running, I will post the URL here and we can work from there.

Thanks again for all of your input, much appreciated.
(in reply to Schalk Neethling [:espressive] from comment #49)
Thanks, good to hear.


All, I have taken the VLC discussion over to bug 1038685.

Dan, I have asked you some questions in the 6th comment there.

(in reply to Dan Pernokis from comment #48)
> An oddity:  Yesterday I set up a new profile in FF that I could use to fake the UA.  
> Today I noticed that FF had sudden;y become the default OPEN program for extension "PDF".  
> This seems more than a co-incidence to me -- the PDF file type has been stable for 
> years, and I haven't done any other internal settings changes to FF in ages.

Dan, in your new Profile - I think you are using "PDF.js", which is a 'Firefox default'.

I described this, in comment # 0, as:
> Even if a user often uses "PDF.js", in Firefox, to read PDF files they might
> still have the plugins installed on their computer.
> 
> One of the many reasons to use plugincheck.

Many users, over time, could forget that they had 'Adobe Reader', if they used "PDF.js"
and end up with an old "vulnerable" plugin.

See
https://support.mozilla.org/en-US/questions/950988

In my opinion the "Chosen solution" has three very useful links
that cover most of the bases.

A useful post, with pictures is:
http://dottech.org/97910/firefox-how-to-turn-off-change-built-in-pdf-reader-viewer-in-firefox-19-and-higher/

You can test this.
In your new profile, while "pdfjs.disabled" is "false" (the default)
browse to
https://bug956905.bugzilla.mozilla.org/attachment.cgi?id=8395239
will open up a 10 page PDF, in a new Tab,
which I attached to bug 956905 comment # 127
I called it "Adobe Flash versions in 2013.pdf" - I discussed this in
the 128th comment.

while "pdfjs.disabled" is "true"
browse to
https://bug956905.bugzilla.mozilla.org/attachment.cgi?id=8395239
(the same 'attachment URL') - this time it will be downloaded as
"Bug_956905_Adobe_Flash_versions_in_2013.pdf".

Note, bugzilla has added the "_" for 'space in the file name'.
You will be able to Open this in Reader, and I presume your 'full Adobe Acrobat'.


About your excellent questions and points concerning

Adobe Acrobat 9.5.5.136 in comment # 48 and 46.

I quite understand that it would be very useful to *know* if
there were 'security updates to 9.5.5.136', that Adobe had released,
that had fixed vulnerabilities.

I know that I don't know enough to give advice.

I don't even know 'which plugin' is 'actually reading PDFs' when *you*
view them on websites.
It may well be that you are actually using the 'Reader plugin' "11.0.8.4".

If this were the case then all would be well as this is a very recent version.
I have filed bug 1068357
"Adobe Reader and Acrobat for Windows and Macintosh - plugins vulnerable 2014-09-16 - APSB14-20"
on 16th September 2014.

Schalk has now updated the Plugincheck Database.
If you do a plugincheck, on Fx 32.0.1, is your 'Reader plugin' "11.0.8.4" reported
as "vulnerable".  I updated my 'Reader' before I filed bug 1068357 (and before Schalk
had updated the Database).


"Adobe Product Security Incident Response Team (PSIRT) Blog"
http://blogs.adobe.com/psirt/

You could ask Adobe, do some further research etc.
I don't know if Adobe support more than 'two versions', they have 11 and 10, do they support 9?

DJ-Leith
(in reply to Dan Pernokis from comment #48)
> @DJ-Leith:
> So the JSON list is really a JS file with the various names and item-specific
> match mechanisms.

Not quite. It is not 'active code' it is 'data about the plugins'.
The 'JSON List' is 'used by other algorithms' as part of the 'Plugincheck Service'.

https://en.wikipedia.org/wiki/JSON
> Although originally derived from the JavaScript scripting language, 
> JSON is a language-independent data format.

All the data about 'known plugins', used at the plugincheck web site,
'comes from the Plugincheck Database'.

I'll give an example below.

In the 'JSON List' this included the 'version information': including
which versions are "latest" and which are "vulnerable".

Also included in the 'JSON List' is data, per 'known in the Database plugin',
about 'how to identify THIS plugin'; 
including MIME Types, literal name match and 
for 'partial name match', use 'THIS regex'.


Using the example about Java.

  Bug 985968 "Mozilla Plugin check page displays Java plugin
  as vulnerable even if the latest Java 7 version is installed".

  Comment # 40 has the link (to a text file with line numbers)
  https://bugzilla.mozilla.org/show_bug.cgi?id=985968#c40
  and comment # 41 of that bug has my discussion of the
  'output from the plugincheck database'.

In this example the 'output from the plugincheck database'
is going to be used by the 'plugincheck website'.
There is more detail in *this* output compared to the
detail in the 'JSON List'. 

In March 2014 Oracle released Java 8 - for Developers to use.
Many people were using Java 7, some Java 6 (and some Java 5).

After the data about the Java 8 plugin was added to the 'Plugincheck Database',
on 2014-03-20, (bug 985056) an algorithm 'found' it to be the ONE "latest",
with the highest version number.

At any time there might be several "latest" versions of a plugin
in the 'Plugincheck Database'.
The 'plugincheck using enumeration' needed the ONE that was the 'MOST latest'.

This is seen, in bug 985968 comment # 41 as:
>  41             'status': 'latest',
>  42             'version': '1.8.0.0',

Below this there are many records for versions of Java plugins that are "vulnerable".

The problem was
Java 8 AND Java 7 were 'different families of Java'.
BOTH could have a "latest" version but the 'Plugincheck Service'
found the Java 8 ("1.8.0.0") to be the 'ONLY ONE / MOST Latest'
all others were 'suppressed in the output data'.

The point I was making in comment # 47
about why the 'JSON List' has the latest Java 8 (which is version "1.8.0.11")
as ".8.0.11". 

> 3306                'status': 'latest',
> 3307                'version': '.8.0.11',
 
Is to allow five versions of Java to be the latest:

"1.6.0.0" for 
> 3150      'redhat-icetea-java': {
> 3151        'display_name': 'IcedTea Java Web Browser Plugin',
Use the 'raw data', in this case:
> 3157                'status': 'latest',
> 3158                'version': '1.6.0.0',


1.5.x.x for Java 5 family, from Oracle, when output to the 'JSON List', strip the "1"
1.6.x.x for Java 6 family
1.7.x.x for Java 7 family
1.8.x.x for Java 8 family

So Java 7 u67 "1.7.0.67" is output as:
> 3319                'status': 'latest',
> 3320                'version': '.7.0.67',

So, the 'JSON List' is just a list, it is data not code or script.


However, if the 'data in the JSON list' is wrong
e.g. has 'no url'
for the button to 'get a new version' of "Adobe Acrobat NPAPI Plug-in"

> 0061      'adobeformacreaderfround': {
> 0062        'display_name': 'Adobe Acrobat NPAPI Plug-in',
> 0063        'description': 'Adobe Acrobat NPAPI Plug-in', 

> 0204        ],
> 0205        'url': '',
> 0206        'regex': [
> 0207        ]
> 0208      },
there will be issues.

Code at the 'Database end' is used to 'select the appropriate data',
and then 'make the JSON List'.
I think the section just quoted might be an example of this 'going wrong'.


More code is used at the 'plugincheck website' to use the data in the
'JSON List' to help detect, evaluate and report on the plugins.

Being anthropomorphic, the website, using enumeration is saying:
'let me list your plugins and I'll tell you what I know about them'.

    If you set "plugins.enumerable_names" to "" (empty string)
    you will 'get no answers'. 


Being anthropomorphic, the website, using the JSON List has to first ask:
'have you got a plugin that can deal with MIME type activegs?'

> 0011      'activegs': {
> 0012        'display_name': 'ActiveGS',

> 0054        'mimes': [
> 0055          'application/x-activegs'

It has to ask for each plugin in the 'JSON List'.

DJ-Leith
@DJ-Leith:  Your comment #50 in reply to my Commet #48 (oddity):
> An oddity:  Yesterday I set up a new profile in FF that I could use to fake the UA.  
> Today I noticed that FF had sudden;y become the default OPEN program for extension "PDF".  
> This seems more than a co-incidence to me -- the PDF file type has been stable for 
> years, and I haven't done any other internal settings changes to FF in ages.

> Dan, in your new Profile - I think you are using "PDF.js", which is a 'Firefox default'...

Sorry to send you down the wrong path.  I meant the WINDOWS OPEN default (click on a PDF file in Windows Explorer) got changed from the usual AcroRd32.exe to firefox.exe such that FF would now open PDFs rather than the genuine READER program.  I used "Open With..." to change it back.  It's OK now, but perhaps somebody should note that this happened while setting up a new profile.  (It's off-topic for THIS bug.)
@DJ-Leith:  Your comment #50... Java Example

>>  Bug 985968 "Mozilla Plugin check page displays Java plugin
>>  as vulnerable even if the latest Java 7 version is installed".

We had quite a back-and-forth at that time regarding how many versions should be checked.  I suggested (and you guys implemented) display of version IDs even for things that were vulnerable, and I started to see "outdated" for the old (not current) but 'not unsafe' plugins.

I still stand behind my comments that we need to recognize (i) newest (hopefully safe); and (ii) most recent SAFE version (in case current is vulnerable and there is no fix imminent.

I further said (in Bug 985968 Comment #44):
>> I think we want the best most-recent feature-filled release (presumably latest) that runs 
>> safely (likely latest, but perhaps previous or second-previous, etc).

>> It does make sense to have a list of safe options.  Users want to know that they have an 
>> "outdated" (but >> safe) version with suitable upgrade options, or a "vulnerable" version
>> with viable fixes -- and decide accordingly.  But we can't maintain a safe list back to 
>> the beginning of time.  Just as old Macs are having trouble with the new Flash 13, so 
>> an old reliable "safe" product may at a future date be vulnerable under Windows 2016, 
>> OSXV, or Firefox 50.

I know there will be difficulties with things like multiple 'families' as in the Java 5/6/7/8 case.  But that's not any different than a lot of software -- many have a latest safe release for several versions.  But some new versions admittedly were brought out to conquer demons that a maintenance release couldn't tame -- those previous versions in this case simply shouldn't be recognized as "safe".

And I also think we should keep the "unknown" plugins if they can be seen.  FF knows *something* about them -- their name!  Better to tell people they have these little extras than to let them think all is well just because the known plugins are safe.  Recall Rumsfeld wasn't worried about the 'known unknowns', he worried about the '*unknown* unknowns'.


Your Comment #50:  Adobe 9
>> I don't know if Adobe support more than 'two versions', they have 11 and 10, do they support 9?

I got the impression they would, and they continue to supply quarterly updates for it right up to now.
(And of course plugincheck doesn't tell me it's out of date. :)

-dan-
Today I installed the new FF 32.0.2 release.

Then Adobe issued an update to READER XI which I installed right away too.  Version of the program from HELP/ABOUT is "11.0.09" (zero nine).  File properties (metadata) says "11.0.9.29".  Internal plugins are "11.0.9.xx" (where xx is usually "29", sometimes "0" on a few).

I ran the plugin check for FF 32.0.2 prior to installing the new Reader.  It showed as 11.0.8 (11.0.8.4) which we know, and said "up-to-date" -- not quite correct.  There is no indication from Adobe whether the older plugin is now vulnerable -- can't find their release notes or anything useful on their supper-whizzy new website! -- so I have to trust it is still OK.  After installing new Reader, I ran plugin check again -- gave the correct info and says "up-to-date" as expected.

The browser plugin (nppdf32.dll) is now "11.0.09.29" according to metadata (and MORE).  The new plugin resides naturally within the Adobe realm in Program Files and got placed in the FF plugin folder.  Interestingly, the plugin is now also copied directly into MS Windows Explorer folder too.  

Note that on the FF MORE page, the name of the plugin appears twice ("nppdf32.dll, nppdf32.dll"), as though it were two files.  Is this a trigger that there are two current (safe) versions?  Or is it just a display bug?

As of 4:30 EDT today, there were no updates for Adobe Acrobat 9.5.5 -- but I can't say so for later versions since I can't get to Adobe's release notes page.

-dan-
I have a laptop running Window 7, updated yesterday to FF 32.0.2, but still running Adobe Reader 11.0.08 (plugin 11.0.8.4).  The old-style plugincheck correctly shows all the version info, but the button still says "up-to-date".  I would expect to see "out-of-date" in the best case, or "vulnerable" which I now understand to be the case here.  (See time-stamped screenshots to follow.)

-dan-
Adobe Version 11.0.08  (FF plugin would be 11.0.8 and 11.0.8.4)
FF 32.0.2 is running...
AddOns page shows Adobe Reader XI plugin version is 11.0.8 / 11.0.8.4...
AddOns MORE page also Adobe Reader XI plugin version is 11.0.8 / 11.0.8.4...
Plugincheck for Adobe Reader XI shows correct version (11.0.8, etc) but button says "up-to-date" - NOT CORRECT!
See "Plugincheck-Fx-32-with-line-numbers-2014-09-20.txt"
when thinking about Dan's report of:

> I ran the plugin check for FF 32.0.2 prior to installing the new Reader.
> It showed as 11.0.8 (11.0.8.4) which we know, and said "up-to-date" -- not quite correct.

He has now added to this evidence. Thank you very much, Dan.
https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8492670
clearly shows that plugincheck is saying "Up to Date", on 2014-09-20,
which is AFTER Schalk updated the Database.

This is a 'false sense of security' and needs fixing.

I will comment on this in the next comment # 62.

DJ-Leith
Flags: needinfo?(schalk.neethling.bugs)
Schalk, Carsten and Dan,

I will make three points.

A. To clarify about metadata.

B. Dan's Report of "11.0.8.4" being declared "Up to Date" when it was "vulnerable".

C. Evidence that 'plugincheck using enumeration' has data for "11.0.09" AKA "11.0.9.29".
 

A. To clarify about metadata.

(In reply to Dan Pernokis from comment #54)
> Today I installed the new FF 32.0.2 release.
> 
> Then Adobe issued an update to READER XI which I installed right away too. 
> Version of the program from HELP/ABOUT is "11.0.09" (zero nine).  File
> properties (metadata) says "11.0.9.29".  Internal plugins are "11.0.9.xx" 
> (where xx is usually "29", sometimes "0" on a few).

Dan, thanks for confirming.
I am now fairly confident, from your reporting in bug 1038685 comment # 9
and bug 1038685 comment # 10, as I noted in bug 1038685 comment # 11
(about the metadata for "VLC Web Plugin") that:

1. Adobe use "11.0.09" on their website (see an example below).
2. Adobe use "11.0.9.29", to use this example plugin, for the 'File Version'
      part of the file matadata (for the Windows "nppdf32.dll" file).
3. "about:plugins" also uses the 'File Version' part of the file matadata.
4. The plugincheck web site (both 'plugincheck using enumeration' and 
      the 'new plugincheck - uses the JSON List') also displays the
      'File Version' part of the file metadata, in the "Status" column.

Dan, the important file is "nppdf32.dll" - the actual plugin (for Windows).

I don't think, from a plugincheck perspective, the others matter.
It is "nppdf32.dll" that is detected.

"nppdf32.dll" has the File Version' metadata "11.0.9.29" (and it was previously
"11.0.8.4").  As the 'File Name', that a Plugin Author might choose to use,
might change the 'actual File Name' is less important.
It is the 'file that does the function', in this case 'deal with PDF files',
that matters.


The 'plugin file' for what we are calling 'Adobe Reader', on Windows 7, 64bit OS is:
> "C:\Program Files (x86)\Adobe\Reader 11.0\Reader\browser\nppdf32.dll"

The previous 'Adobe Reader' was File Version "11.0.8.4" in the metadata.

So, the Plugincheck Database needs to have JUST "11.0.8.0",
the 'left hand three positions' (not the ".4" at the right)
for a correct detection to work. 

(from comment # 47, discussing version "11.0.8.4")
> My
> "C:\Program Files (x86)\Adobe\Reader 11.0\Reader\browser\nppdf32.dll"
> Has, using Windows Explorer, properties, "Details" Tab,
> 
> > File description    Adobe PDF Plug-In For Firefox and Nets...
> > Type                Application extension
> > File version        11.0.8.4 <== both methods of 'plugincheck website detection',
>                                         by enumeration and 'using the JSON List'
>                                         report this as "11.0.8.4"

https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8487593
Is "Plugincheck-Fx-32-build-aa315da-with-line-numbers-2014-09-10.txt"
Attached at comment # 32 
Note: 10th September 2014 (data is now old).

> 0050          'id': '4',
> 0051          'pfs_id': 'adobe-reader',
> 0052          'name': 'Adobe Reader',
> 0053          'description': 'Adobe PDF Plug-In For Firefox and Netscape',
> 0054          'vendor': 'Adobe',
> 0055          'url': 'http://get.adobe.com/reader/',
> 0056          'modified': '2014-08-27T17:38:46+00:00',
> 0057          'created': '2014-08-27T17:38:46+00:00',
> 0058          'plugin_id': '2',
> 0059          'os_id': '3',
> 0060          'platform_id': '4',
> 0061          'status': 'latest',
> 0062          'version': '11.0.8.0',
> 0063          'detected_version': '11.0.8.0',
> 0064          'detection_type': '*',
> 0065          'os_name': 'win',

As we know, on 2014-09-10, 'plugincheck using enumeration'
which uses the data above, was working correctly.


The 'JSON List' does have the "11.0.8.0" data from the
Plugincheck Database, see just below, BUT the 'detection part'
of the 'new plugincheck - uses the JSON List' is not working
correctly.  Perhaps it is using 'the WRONG section of the list'?

https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8487601
"Plugincheck-Fx-34-build-aa315da-with-line-numbers-2014-09-10.txt"
Attached at comment # 33

The 'JSON List'

> 1686          'win': {
> 1687            'latest': [
> 1688              {
> 1689                'status': 'latest',
> 1690                'version': '11.0.8.0',
> 1691                'detected_version': '11.0.8.0',
> 1692                'detection_type': '*',
> 1693                'os_name': 'win',

I leave that for Schalk to think about and debug.


B. Dan's Report of "11.0.8.4" being declared "Up to Date" when it was "vulnerable".

(In reply to Dan Pernokis from comment #54 - 2014-09-19)
> I ran the plugin check for FF 32.0.2 prior to installing the new Reader.
> It showed as 11.0.8 (11.0.8.4) which we know, and said "up-to-date" -- not quite correct.
This should not have been seen, if all was well.

Dan has now clarified this and repeated his observations, thank you very much!
This is a 'false sense of security' and needs fixing.

As readers of this bug will recall,
"11.0.8.4" was reported correctly by 'plugincheck using enumeration'
before Adobe released '11.0.09' on 2014-09-16.

Bug 1068357 "Adobe Reader and Acrobat for Windows and Macintosh - plugins 
vulnerable 2014-09-16 - APSB14-20"

Has the details of '11.0.09' AKA "11.0.9.29" being released and
'11.0.08' AKA "11.0.8.4" was declared vulnerable by Adobe.


Schalk Neethling [:espressive] on 2014-09-17 at 06:43:33 PDT in bug 1068357 comment # 1 
> Database updated 

Schalk, why did Dan see "Up to Date" for "11.0.8.4"?
He should have seen "vulnerable" on 2014-09-19 - two days AFTER you closed bug 1068357.
Dan has added screenshots there too.


C. Evidence that 'plugincheck using enumeration' has data for "11.0.09" AKA "11.0.9.29".

See the "Plugincheck-Fx-32-with-line-numbers-2014-09-20.txt"
which I attached to comment # 61

https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8492688
I actually captured this data about 24 hours ago.
I was puzzled by Dan's report, since then he has repeated his tests and
captured evidence.  Thank you Dan.


First,
I cheated, look near the top, I went direct to the URL that I had used on Date: 2014-09-10
>        ***    Open a new Tab, and paste the URL.  In THIS case, I cheated and went direct to this URL,

This might have 'invalidated my test'
IF Schalk (or someone) has changed the website.
For speed I have just used the URL.

Second,

This 'extract from the database' does have plausible data.

I mean the data fits the facts that I would expect to see if I had not read Dan's report:

C1. Schalk updated the Database on 2014-09-17.
C2. I can see "11.0.9.0" the NEW plugin data.
C3. I can see data for the 'now vulnerable plugin' version "11.0.8.4" AKA "11.0.08".


> 0050           'id': '4',
> 0051           'pfs_id': 'adobe-reader',
> 0052           'name': 'Adobe Reader',
> 0053           'description': 'Adobe PDF Plug-In For Firefox and Netscape',
> 0054           'vendor': 'Adobe',
> 0055           'url': 'http://get.adobe.com/reader/',
> 0056           'modified': '2014-09-17T20:42:58+00:00',
> 0057           'created': '2014-09-17T20:40:17+00:00',
> 0058           'plugin_id': '2',
> 0059           'os_id': '1',
> 0060           'platform_id': '4',
> 0061           'status': 'latest',
> 0062           'version': '11.0.9.0',
> 0063           'detected_version': '11.0.9.0',
> 0064           'detection_type': '*',
> 0065           'os_name': '*',
> 0066           'app_id': '*',
> 0067           'app_release': '*',
> 0068           'app_version': '*',
> 0069           'locale': '*',
> 0070           'fetched': '2014-09-19T13:45:50-07:00',
> 0071           'relevance': 1
> 0072         },

C1. Schalk updated the Database on 2014-09-17.

Schalk Neethling [:espressive] said on 2014-09-17 at 06:43:33 PDT in bug 1068357 comment # 1 
> Database updated 
see
> 0056           'modified': '2014-09-17T20:42:58+00:00',
> 0057           'created': '2014-09-17T20:40:17+00:00',

C2. I can see "11.0.9.0" the NEW plugin data.
> 0061           'status': 'latest',
> 0062           'version': '11.0.9.0',
> 0063           'detected_version': '11.0.9.0',

C3. I can see the old data for the 'now vulnerable plugin' version "11.0.8.4" AKA "11.0.08".
> 0259           'status': 'vulnerable',
> 0260           'vulnerability_description': 'Adobe has released security updates for 
Adobe Reader and Acrobat for Windows and Macintosh.',
> 0261           'vulnerability_url': 
'http://helpx.adobe.com/security/products/reader/apsb14-20.html',
> 0262           'version': '11.0.8.0',
> 0263           'detected_version': '11.0.8.0',
> 0264           'detection_type': '*',
> 0265           'os_name': 'win',

Which has the correct information:
> 0261           'vulnerability_url':
'http://helpx.adobe.com/security/products/reader/apsb14-20.html',
is correct,

> 0265           'os_name': 'win',


Recall that,
"11.0.8.4" AKA "11.0.8.0" AKA "11.0.08" was a *Windows* Release, 
see bug 1053417 and
http://helpx.adobe.com/security/products/reader/apsb14-19.html

I don't remember if there was a Mac release of '11.0.08'.
There might not have been.


I do know that '11.0.09" (AKA "11.0.9.29" is the Windows File Version)
was released for BOTH Windows and Macintosh
see
http://helpx.adobe.com/security/products/reader/apsb14-20.html
> Affected software versions
> 
>    Adobe Reader XI (11.0.08) and earlier 11.x versions for Windows
>    Adobe Reader XI (11.0.07) and earlier 11.x versions for Macintosh

Schalk, when you Updated the Plugincheck Database did you update
all the records (e.g. Macintosh 11.0.07)?

DJ-Leith
Flags: needinfo?(cbook)
@DJ-Leith:  Comment #62

>> I don't remember if there was a Mac release of '11.0.08'.
>> There might not have been.

FYI, 11.0.08 was Windows only, according to the Adobe release notes for Reader and Acrobat.
Which is why Mac users of "11.0.07 and earlier" should update to the new 11.0.09 release.
(The security issue did not affect Macs.)

-dan-
Flags: needinfo?(cbook)
I have actually made a lot of progress in this regard but, at the moment I am blocked by getting a staging environment up and running which work is being done on at the moment [https://bugzilla.mozilla.org/show_bug.cgi?id=1069856]

As soon as this is done, I can push the latest code and DB changes there and have everyone run it through it's paces to ensure that it does in fact solve the issues (related to adobe reader/acrobat) discussed in this bug.
Flags: needinfo?(schalk.neethling.bugs)
Start pointing your browsers (let's do all version for now) here and let me know there results.

Remember, this is just a dev instance and the focus is on better Acrobat/Reader detection and reporting:

http://ossreleasefeed.github.io/Perfidies-of-the-Web/
Flags: needinfo?(dj.4bug)
@schalk:  Sorry to say I think plugin check still isn't working right.  It still calls 11.0.08 "up to date".

My laptop has since had its Adobe Reader updated, but I do have a netbook (Win 7/32, maybe not absolutely current) running FF 31.0 and Adobe 11.0.08 (help/about).

Running the current/existing plugin check for reference on FF 31.0, it shows reader as 11.0.8 and 11.0.8.4 (correct) and says "Up-to-date" (wrong, but we know that).

[[ Then I tried to update FF to 32.0.3, clicking the update button immediately pops up "Restart to Update".  Clicking goes nowhere, so I closed and re-opened FF.  Tried again, same result, so skipped for now. ]]

Running the test plugin check (your command line, cut & pasted)...
"http://ossreleasefeed.github.io/Perfidies-of-the-Web"
...also shows reader as 11.0.8 and 11.0.8.4 (correct) but also says "Up to Date" too -- WRONG!

And for reference, my live system running Reader 11.0.09 shows 11.0.9 and 11.0.9.29 (correct) and "up to date" (can't be sure now).

Sorry I don't have screen image capture capability on the netbook, but I can tell you the time was around 11:00 pm EDT Thurs Oct 9 in Canada / 5:00 am CEST Friday Oct 10, in case that matters.

(And for what it's worth, I like the richer fonting on this version...)

-dan-
(In reply to Dan Pernokis from comment #66)
> @schalk:  Sorry to say I think plugin check still isn't working right.  It
> still calls 11.0.08 "up to date".
> 
> My laptop has since had its Adobe Reader updated, but I do have a netbook
> (Win 7/32, maybe not absolutely current) running FF 31.0 and Adobe 11.0.08
> (help/about).
> 
> Running the current/existing plugin check for reference on FF 31.0, it shows
> reader as 11.0.8 and 11.0.8.4 (correct) and says "Up-to-date" (wrong, but we
> know that).
> 
> [[ Then I tried to update FF to 32.0.3, clicking the update button
> immediately pops up "Restart to Update".  Clicking goes nowhere, so I closed
> and re-opened FF.  Tried again, same result, so skipped for now. ]]
> 
> Running the test plugin check (your command line, cut & pasted)...
> "http://ossreleasefeed.github.io/Perfidies-of-the-Web"
> ...also shows reader as 11.0.8 and 11.0.8.4 (correct) but also says "Up to
> Date" too -- WRONG!
> 
> And for reference, my live system running Reader 11.0.09 shows 11.0.9 and
> 11.0.9.29 (correct) and "up to date" (can't be sure now).
> 
> Sorry I don't have screen image capture capability on the netbook, but I can
> tell you the time was around 11:00 pm EDT Thurs Oct 9 in Canada / 5:00 am
> CEST Friday Oct 10, in case that matters.
> 
> (And for what it's worth, I like the richer fonting on this version...)
> 
> -dan-

Thanks for the quick response Dan. There might be little issues like this still for one simple reason that I need to revise, that is why I wanted people to start looking and let me know. So the biggest one is, the DB it points to from the github URL, is the staging database and, this only get's refreshed from production once a month (something I am changing to weekly now that the environment is going to be utlized a lot more) so, it might very well be that the info for the 11.0.8.0 release just is not on staging.

I am going to go through this today and compare prod and staging data and manually update staging until we have the weekly production refresh. I will update the bug as soon as I feel the version data is not in sync.

Thanks again for jumping on this so quickly and your feedback.

P.S. Currently the OpenSans font is not loading correctly on this page (something I am fixing as well) so, what you are seeing is you system's fallback sans-serif so, as soon as I fix the font loading problem, the font will go back to the way it is displayed on the production site (which is unfortunate as you mention how much you like the current font style ;)).
Ok, I have updated the staging database to now contain the same version for Adobe Reader/Acrobat as production.
@schalk:  Sorry, no joy.

After updating Norton NIS, I was able to update FF to 32.0.3 with no problems.  (This machine was last booted back in August.)  So now testing on current release of FF.

I first tested the current (known faulty) plugin check again for reference.  Reader showed as 11.0.8 / 11.0.8.4 and "up to date" as usual (wrong, but known to be).

Then I tested using the same test command line as you provided previously...
"http://ossreleasefeed.github.io/Perfidies-of-the-Web"
...and got the same erroneous results (11.0.8 / 11.0.8.4 and "up to date").

BTW, I hope this is a typo HERE in your Comment #68 and not in your database:
>> "...it might very well be that the info for the 11.0.8.0 [eight point zero] 
>> release just is not on staging."
Reader Help/About says "11.0.08" [point zero eight].  Corresponding FF plugin is "11.0.8" [point eight] and "11.0.8.4" [eight point four], (versus your eight point zero).


On the other hand, this works (and I think we know that):
My Shockwave Flash correctly shows as 14.0 r0 and 14.0.0.179 "Vulnerable" -- which it is.

-dan-
(In reply to Dan Pernokis from comment #69)
> @schalk:  Sorry, no joy.
> 
> After updating Norton NIS, I was able to update FF to 32.0.3 with no
> problems.  (This machine was last booted back in August.)  So now testing on
> current release of FF.
> 
> I first tested the current (known faulty) plugin check again for reference. 
> Reader showed as 11.0.8 / 11.0.8.4 and "up to date" as usual (wrong, but
> known to be).
> 
> Then I tested using the same test command line as you provided previously...
> "http://ossreleasefeed.github.io/Perfidies-of-the-Web"
> ...and got the same erroneous results (11.0.8 / 11.0.8.4 and "up to date").
> 
> BTW, I hope this is a typo HERE in your Comment #68 and not in your database:
> >> "...it might very well be that the info for the 11.0.8.0 [eight point zero] 
> >> release just is not on staging."
> Reader Help/About says "11.0.08" [point zero eight].  Corresponding FF
> plugin is "11.0.8" [point eight] and "11.0.8.4" [eight point four], (versus
> your eight point zero).
> 
> 
> On the other hand, this works (and I think we know that):
> My Shockwave Flash correctly shows as 14.0 r0 and 14.0.0.179 "Vulnerable" --
> which it is.
> 
> -dan-

hmmmmm, very, very weird. I will look into this. I wonder if there is some crazy caching going on somewhere.
(In reply to Dan Pernokis from comment #69)
> @schalk:  Sorry, no joy.
> 

You wanna give that a go again?
@schalk: Same / same / same

I re-tested with your command line and got 11.0.8 / 11.0.8.4 "Up to date".

Then I flushed history (your comment about wild caching -- so why not?) -- still "up-to-date".

Then this time, I noticed FF prompted for permission to let your site run Java Deployment -- I said OK this time.  Display still came back 11.0.8 / 11.0.8.4 "Up to date".

(As reference, Shockwave Flash correctly shows my version as "vulnerable", which we know.  I won't tell you again unless it changes.)

BTW, in the meantime, my Windows 7/32 is now fully up-to-date.

-dan-
Additional to my Comment #72...
I flushed history "from the beginning of time" -- everything except forms (which was greyed).
-dan-
Dan,

Thanks so much for all the feedback, very strange behavior as I am getting different results. I will do some additional testing. I remember you mentioned using Fx 32.0.3, have you tested with a Beta+ release?
(In reply to Schalk Neethling from comment #68)
> Ok, I have updated the staging database to now contain the same version for
> Adobe Reader/Acrobat as production.

Yes, good to use data that is nearly current.

(In reply to Schalk Neethling from comment #65)
> Start pointing your browsers (let's do all version for now) here
> and let me know there results.
> 
> Remember, this is just a dev instance and the focus is on better
> Acrobat/Reader detection and reporting:
> 
> http://ossreleasefeed.github.io/Perfidies-of-the-Web/

In this comment I am reporting both DEV and LIVE but
concentrating on DEV.

DEV
http://ossreleasefeed.github.io/Perfidies-of-the-Web/

LIVE
https://www.mozilla.org/en-GB/plugincheck


Schalk,
the only 'Adobe Reader' plugin I have here tonight is
"11.0.9.29" which Adobe call, on their website [1], "11.0.09".

Tests at DEV
http://ossreleasefeed.github.io/Perfidies-of-the-Web/

Using Firefox 32.0.3,
  with "plugins.enumerable_names" set to "*" (all plugins are
  enumerated at plugincheck)
using UA spoofs for:
Fx 30, Fx 31 and Fx 32.

All 3 have
A. "unknown" plugins - correct.
  See bug 1078251 "Bump Firefox Version for plugincheck - Fx 33 will be released on 2014-10-14".
  At LIVE, Fx 33 *does* use enumeration (the Bump has happened at LIVE - good!).

B. 'Adobe Reader' is reported as "Adobe Acrobat"
(expected as this is Adobe's Name in the metadata [2] (NOT the 'display name')),
'version' is "11.0.9.29" (expected - "File version" metadata [2]).


Comment on DEV
The 'green button' says "Up to Date" (correct),
the 'Status column' has "up to date" (NOT capitalized - LIVE has "Up to Date" in the 'Status column'). 

Fx 33+, at DEV, uses the JSON List (no "unknown" plugins,
'Plugin Names' use the 'Display Name' e.g. "Adobe Flash Player" [not Shockwave Flash]
and "Adobe Reader" [not Adobe Acrobat]).

I like the 'Display Name', to override Adobe's metadata [2].
I would prefer "Up to Date" in the 'Status column'.

Comment on IE 9 at DEV
  I don't see my Flash reported.  NO plugins are reported.
  I do see a 'loading data'.
  I was checking to see if the colour of the "Up to Date"
  had been fixed (see comment # 18). 
  Example of 'blue button' screenshot, at LIVE on 2014-08-13 was,
  https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8472632
  (the Bug to fix this is bug 1054280).

> Remember, this is just a dev instance and the focus is on better
> Acrobat/Reader detection and reporting:
So, just noted in passing.
When you have a fuller 'staging environment' we can test more.


Still using DEV
http://ossreleasefeed.github.io/Perfidies-of-the-Web/

Still using Firefox 32.0.3,
  with "plugins.enumerable_names" set to "" (empty string - NO enumeration)
using UA spoofs for:
Fx 33, Fx 34 and Fx 35.

All 3 have
A. no "unknown" - expected - the plugins HAVE to be in the JSON List to be reported. 

B. 'Adobe Reader' is reported as the 
'display name' and is "Adobe Reader"
(expected as this is from the JSON List and is NOT Adobe's Name in the metadata [2])
The 'line below the display name' is "Adobe PDF Plug-In For Firefox and Netscape"
(and not the "File description" from the metadata [2] - note there is no "...11.0.9" at the end),
'version' is "11.0.9.29" (expected - "File version" metadata [2]).

So, this is better than LIVE which (as we know) is reporting "11.0.9.29"
as "vulnerable" (and is using the 'wrong section of the JSON List' to
name it as "Adobe Acrobat NPAPI Plug-in").


Still using DEV
http://ossreleasefeed.github.io/Perfidies-of-the-Web/

Still using Firefox 32.0.3,
  with "plugins.enumerable_names" set to "" (empty string - NO enumeration)
using UA spoofs for:
Fx 30, Fx 31 and Fx 32.

I get 'no results at all' - expected because the boundary between
'use enumeration' vs 'use the JSON List', at DEV, is 'Fx 33+ use the JSON List'.

Schalk,
a minor change you could make to DEV is to make the boundary between
'use enumeration' vs 'use JSON List' the same as LIVE
i.e. 'Fx 34+ use the JSON List'.


References:

[1] 
> Adobe Security Bulletin
> Security Updates available for Adobe Reader and Acrobat
> Release date: September 16, 2014
> Vulnerability identifier: APSB14-20
> http://helpx.adobe.com/security/products/reader/apsb14-20.html

This is also the way Adobe describe the version in the Reader's Menu,
Help, "About Adobe Reader XI...",
has
> Adobe Reader XI
> Version 11.0.09 

[2]
In Firefox, on my Windows 7 64bit OS, "about:plugins" has
> Adobe Acrobat
> 
>    File: nppdf32.dll,nppdf32.dll
>    Path: C:\Program Files (x86)\Adobe\Reader 11.0\Reader\browser\nppdf32.dll,
>             C:\Program Files (x86)\Adobe\Reader 11.0\Reader\AIR\nppdf32.dll
>    Version: 11.0.9.29
>    State: Enabled
>    Adobe PDF Plug-In For Firefox and Netscape 11.0.9

Dan,
there are two Reader DLLs (one for "AIR").
Both DLLs have the "File version" metadata' of "11.0.9.29" and
the "File description" metadata of "Adobe PDF Plug-In For Firefox and Nets...".

(In reply to Dan Pernokis from bug 1068357 comment #14)
> ... When I say "two" or "twice", I mean that the name of the plugin file is
> shown twice on the AddOns MORE page for the nppdf32.dll plugin. ...
I am convinced that the 'AddOns MORE page' and "about:plugins"
are BOTH reporting the same TWO "nppdf32.dll" files
(one for "AIR" and one for "browser").

Dan, you might also have an additional file for your 'full Adobe Acrobat 
that can write PDFs' and possibly an ActiveX file (for Internet Explorer
to read PDFs). I do NOT have either of these as I've not installed the
'IE PDF plugin' (the AciveX file) and I don't have the 'full Adobe Acrobat
that can write PDFs'.


All,
I stand by everything I said in comment # 62, in particular:
> The previous 'Adobe Reader' was File Version "11.0.8.4" in the metadata.
> 
> So, the Plugincheck Database needs to have JUST "11.0.8.0",
> the 'left hand three positions' (not the ".4" at the right)
> for a correct detection to work.

Both
"about:plugins" and

plugincheck (LIVE and also DEV http://ossreleasefeed.github.io/Perfidies-of-the-Web/)
report this version as "11.0.9.29".

and LIVE report this "File description" (from the metadata),
"Adobe PDF Plug-In For Firefox and Netscape 11.0.9"
but DEV reports
"Adobe PDF Plug-In For Firefox and Netscape" without the "...11.0.9" at the end.

DJ-Leith
Flags: needinfo?(dj.4bug)
Dan and Schalk,

I can't confirm Dan's "11.0.8.4" plugin reported as "Up to Date"
because I don't have a "11.0.8.4" plugin here.

However, it is not the first time that I have seen similar.
 

Remember that on LIVE, back on 20 September 2014,
Dan documented that LIVE was reporting "11.0.8.4" as "Up to Date" in error.

See bug 1068357 comment # 13.

Fixing the LIVE plugincheck, so that "11.0.8.4" is reported as "vulnerable",
is even more important than getting DEV working.

(I said in comment # 62 - above in this bug)
> Schalk, when you Updated the Plugincheck Database did you update
> all the records (e.g. Macintosh 11.0.07)?

I don't think there was ever a 'Macintosh 11.0.08 version of Reader'.

So, in cases like this, where Adobe released "11.0.8.4" (AKA 11.0.08)
for Windows BUT NOT Macintosh,
what do you and/or Carsten do when you update the Database
AFTER "11.0.8.4" becomes "vulnerable"?

How does the 'plugincheck service' know that
BOTH 'Macintosh Reader 11.0.07'
and 'Windows Reader 11.0.8' (deliberately vague, 'Adobe like', version names used here)
are "vulnerable"?


Dan,
my understanding of your comments, from comment # 66 onwards, is that

BOTH

  DEV
  http://ossreleasefeed.github.io/Perfidies-of-the-Web/

and 

  LIVE (in your Canadian case, the US version)
  https://www.mozilla.org/en-US/plugincheck 

continue to report "11.0.8.4" as "Up to Date" in error!

All,
I will be offline from now until 2014-10-17.

DJ-Leith
Without knowing how the internals of plugin check work, let my mind run wild and ask some really dumb programming questions -- not for answers, but to prompt some debugging -- because I've seen & done these things too often myself... :)


>> These should cause all to fail, unless READER has its own special-case functions
>> (which is what I'm driving at):

(i) Are you indexing into one or more tables?  (taking the nth entry from a list...)  Perhaps an index pointer is offset from zero when it should be from one, or from -1 when it should be from zero.  Or not being cleared when it should.

(ii) Is an initial value being set incorrectly (ditto above) as zero or one when it should be -1 or zero?  (Or perhaps NOT being set at all ??) 

(iii) Anything deceptive like:  x=1 when it should be x==1?  Function calls passing values instead of pointers (or vice versa)?  Or maybe a function call is not passing ALL of its required parameters?

(iv) Are we comparing characters ("8" & "08") -- doing a character match when it should be a value comparison?  (And the related: any Ohs for Zeros?)


>> These would be PROGRAMMING problems triggered by bad information in the data, 
>> specific to individual searches:

(v) In the data record (or programming constants) specifically for Reader in general, is there something unusual (like an "initial value" or "index pointer") that may not be set correctly?  See (i) above.

(vi) In the data record (or programming constants) specifically for Reader 11.0.08, is there something unusual...


>> These would be DATA-RELATED problems specific to individual RECORDS being searched:

(vii) In the data record specifically or logically BEFORE Reader -- when the scan is being made -- is there something... that causes the scan to terminate early with "valid" but incorrect results?  (Could be an embedded "end-of-record" or "end-of-file" mark, logical terminator, off-scale, out-of-bounds, etc.)

(viii) Same as above... that causes the 11.0.08 record to appear merged with the previous record?  This might cause the Reader 11.0.08 record to be remain unseen and be skipped over.

(ix) Same as above... that causes the 11.0.08 record to appear merged with the following record?  Same result -- the Reader 11.0.08 record is not seen.

(x)  Does the "index" of the data record file need to be regenerated?  Could be a missing key, duplicate key, or mis-directed pointer -- which could be caused by the above three (vii, viii, ix).


If I think of any more, I'll add them.

-dan-
I wrote Comment #77 just as DJ was posting his two -- they collided.

@DJ-Leith:  
End of your Comment #76:  Yes, you understand correctly -- Both LIV and DEV are reporting the previous (out-dated) Adobe Reader XI plugin 11.0.08 as "up to date".

I worry about this, though, from above:
>> I stand by everything I said in comment # 62, in particular:
>> > The previous 'Adobe Reader' was File Version "11.0.8.4" in the metadata.
>> > 
>> > So, the Plugincheck Database needs to have JUST "11.0.8.0",
>> > the 'left hand three positions' (not the ".4" at the right)
>> > for a correct detection to work.

I would agree that "11.0.8" as a substring might find all "11.0.8.x" (including "11.0.8.4").
But I think that in tacking on a trailing zero ("11.0.8.0"), the trailing zero might make a search/match too specific (point zero does not match point four).

And likewise be careful here...
>> How does the 'plugincheck service' know that
>> BOTH 'Macintosh Reader 11.0.07'
>> and 'Windows Reader 11.0.8' (deliberately vague, 'Adobe like', version names used here)
>> are "vulnerable"?
The 'Adobe like' Windows Reader version is "11.0.08" (point zero eight, not just point eight).


>> I am convinced that the 'AddOns MORE page' and "about:plugins"
>> are BOTH reporting the same TWO "nppdf32.dll" files
>> (one for "AIR" and one for "browser").
>> Dan, you might also have an additional file for your 'full Adobe Acrobat 
>> that can write PDFs' and possibly an ActiveX file (for Internet Explorer...)

Yes, there are two identical nppdf32.dll files (same size, date, metadata).
There is also one for my writing Acrobat -- but it is half the size and a different date, going back to the time of the last update (which we confirmed previously in my case of 9.5.5 was a year ago and beyond redemption).  

So, enjoy your... vacation?

-dan-
@schalk:  I updated my main machine to FF 33.0 "today" (14-Oct-2014) when it was released.

I ran PLUGIN CHECK from the FF menu and everything seemed fine - no out-of-date or vulnerable warnings.  When I went to do the same on the old Netbook, there was a popup notice that JAVA 7 Update 71 was available, so I updated Java on the netbook only -- Toolkit was 7.0.670.1 (10.67.2.1) and Platform was SE7 U67 (10.67.2.1 also, as expected) - now 7.0.710.14 (10.71.2.14) and SE7 U71 (10.71.2.14).  (Java About says "Java 7 Update 71" and "build 1.7.0_71-b14".)

So I've run PLUGIN CHECK from FF (32.0.3) menu several times (here and on the Laptop) against Java 7/67 and everything still looks fine -- no "Out-of-Date" or "Vulnerable" messages -- not good.  I also tried it with your test command line...
  http://ossreleasefeed.github.io/Perfidies-of-the-Web/
... and it too shows no problems with Java (although it recognizes FF as "older" and offers a free download :).

Plugin checks on the Netbook (now running Java 7/71 but still FF 32.0.3) legitimately show both Javas up-to-date with 7/71 versions;  Adobe 11.0.8.4 "up-to-date" (wrong! as previous);  and Shockwave Flash 14.0.0.179 "Vulnerable" (correct, as previous).

I'll hold off on updating Java on Main and Laptop for a few days in case it's just the database out of date, but it may be the same issue as Adobe.

Let me know if you need anything else.

-dan-
@schalk:  

Today on my main machine I ran PLUGIN CHECK from FF 33.0 menu and it now reports JAVA 7/67 ("10.67.2.1") as "Vulnerable".  Using your test command line, it still shows as "Up-to-Date" (likewise "10.67.2.1").

Plugin checks on the Netbook (now running Java 7/71 but still FF 32.0.3) legitimately show both Javas up-to-date with 7/71 versions;  Adobe 11.0.8.4 "up-to-date" (wrong! as previous);  and Shockwave Flash 14.0.0.179 "Vulnerable" (correct, as previous).  But interestingly, using your test command line now reports "unknown plugins" -- sorry, not sure if that happened yesterday.  (The main machine doesn't show "unknown"s with the test command line.)

-dan-
@schalk:

Today I did some regular Windows updates.  After reboot, as happens occasionally, Adobe Flash player gave notice that an update is available.  (Adobe Flash is identified as Shockwave Flash when installed.)  The version here and on the Laptop is currently 15.0.0.152, but both plugin checks (FF33 menu and your test command line) say this Flash is up-to-date.  (The Netbook truly is out of date at 14.0.0.179 as correctly reported by both plugin checks.)
I ran the Adobe Flash update on my main machine only.  Both plugin checks say "up-to-date" and correctly identify it as "15.0.0.189".

Question/thought:  The checker missed knowing about the update a few minutes ago...  So what happens now that the software is actually *ahead* of the database?  I wouldn't want to see on screen "you're living in the future", but does the checker log this?  Might be useful as an early warning for updates you might not yet know about.
Today the FF33 Plugin Check (from the TOOLS menu) shows my VLC media player Web Plugin 2.1.0 as "vulnerable" and offered an update.  Version 2.1.2 has been current for some time but hasn't shown as out-of-date or vulnerable in FF (cross-ref Bug 1038685) -- and I just haven't gotten around to updating it yet.

Now, according to the VideoLAN site, it looks like VLC 2.1.5 is the latest -- but the test command line
  http://ossreleasefeed.github.io/Perfidies-of-the-Web/
doesn't even list VLC at all (likewise cross-ref Bug 1038685).

-dan-
@schalk:

Today on my main machine I updated to FF 33.0.1.  I ran PLUGIN CHECK from the FF menu and it correctly reports my outdated JAVA 7/67 ("10.67.2.1") as "Vulnerable".  But using the test command line
  http://ossreleasefeed.github.io/Perfidies-of-the-Web/
it still shows as "Up-to-Date" (likewise "10.67.2.1").

This is the last time I can test this, as I am now about to upgrade my JAVA to 7/71.
Improvements to this has landed on production. Please give it a whirl and let me know your feedback. Just one important note, please keep feedback here related to Adobe Reader/Acrobat only.

If you run into problems with a different plugin, even if also by Adobe, please comment on the relevant bug or log a new bug [https://bugzilla.mozilla.org/enter_bug.cgi?product=Plugin%20Check&component=Client]. Thank you in advance.
>> I am also posting this to Bug 1053417.

I recently upgraded FF to 34.0 (on 01-DEC-2014, the day of release, I believe).  At that time, the plugin check (TOOLS menu) said everything was "up to date" (except VLC  which we know about).

Late evening 10-Dec-2014 (crossing midnight Eastern Standard Time here in North America), I was doing a wide range of updates on the laptop.  I had checked FF and TB earlier -- both latest versions and all plugins up to date.  I updated Windows, which rebooted and triggered version checks of Adobe AIR and FLASH PLAYER.  Both had updates available.  (AIR is not reported by plugin-checker; FLASH had shown OK.)  I updated both, and plugin check showed all up-to-date.  THEN I checked Adobe READER -- it had Update 11.0.10 available.

Next morning, I updated the Tower -- FLASH was now correctly showing "vulnerable".  But I also noticed something really odd:  the "Adobe Acrobat" (nppdf32.dll) being reported was "9.5.5.316" -- the version for the genuine Acrobat PDF Creator program (which it never reported before) -- and it DID NOT report the version of READER at all, even though the ADD-ONs MANAGER clearly showed both installed.  I confirmed this behaviour on the Laptop too.  

Recall some time ago we discussed this situation -- my Acrobat PDF Creator is old, and its plugin (a copy of the same for READER back at 9.5.5) is in a different location.  Looks like the READER location is not being looked at now by plugin-check.

To recap:  Adobe Flash was reported late, Adobe Reader isn't being checked at all (unless once it sees the Acrobat version, it skips the Reader one).

And just for the record:  The proper nppdf32.dll plugin verbally describes itself as "Adobe Acrobat 11.0.10.32" and "Adobe PDF Plug-In For Firefox and Netscape 11.0.10" -- the key word being "Acrobat", whether used for Reader or genuine Acrobat.  The same plugin is used by both Acrobat and Reader (and AIR, for that matter) -- same file, but from different locations.  My Reader is current, so plugin-check should find and report the 11.0.10 file (same as AIR).  My Acrobat is old, only 9.5.5, and that gets reported.  But the report shows only the 9.5.5 file, not both.
Blocks: 1121456
No longer blocks: 1023718
Status: NEW → ASSIGNED
Component: plugins.mozilla.org → UI
Product: Websites → Plugin Check
QA Contact: cbook
@SCHALK...
Nice job on the recent Plugin Check pages!  I've run it a few times on FF37 and 38 - looks good.

I've noticed.however, that the Adobe Acrobat version is again not being properly identified in some cases.  See the last paragraph of my Comment 86 above.


Today, I upgraded to FF 38.0.1 (using FF Help/About) and THEN updated my Adobe Reader XI (using Reader Help/Update).  Reader's new current version is 11.0.11 (or 11.0.11.18 internally), and the relevant FF plugin is "nppdf32.dll".

The ADD-ON page correctly shows the Reader plugin as 11.0.11, and my older Adobe Acrobat (the PDF creator) correctly shows up as 9.5.5 (which was current with Reader 9.5.5 when it was installed and last updated).  Keep in mind the two programs have this file in common.  When I click "More" for Acrobat 9.5.5, I see the plugin name once (typical) and a list of MIME types.  And when I click "More" for Reader, I see the name *twice* the same -- "nppdf32.dll, nppdf32.dll" -- and with a longer list of more recent MIMEs.  This is significant that it sees and reports two (same) names, I think.

But PLUGIN CHECK incorrectly sees and shows only the Adobe Acrobat 9.5.5 copy and says "outdated".  The UPDATE button takes me to update Adobe Reader -- logically correct, I suppose, but it likely will not be updating the correct copy because it takes me to the same update page as Adobe Reader does.

There are four identical copies of the current plugin -- two in Adobe Reader for Air and Browser use, and one each directly in Firefox and Internet Explorer local folders.  There are two additional copies of the 9.5.5 version (identical to each other) in Adobe Acrobat for Air and Browser use.  (These two copies, as I said, were once synchronized with Reader 9.5.5 when they were both current.  Reader has been updated all along, but Acrobat has been frozen at EOL because I never paid for a newer version.)

Troubleshooting Info (About:Plugins) shows these in separate sections, both identified as "Adobe Acrobat":
>> File: nppdf32.dll,nppdf32.dll
>> Path: C:\Program Files\Adobe\Reader 11.0\Reader\browser\nppdf32.dll,C:\Program Files\Adobe\Reader 11.0\Reader\AIR\nppdf32.dll
>> Version: 11.0.11.18
>> 
>> File: nppdf32.dll
>> Path: C:\Program Files\Adobe\Acrobat 9.0\Acrobat\Air\nppdf32.dll
>> Version: 9.5.5.316


Here is what I have installed where:
>> C:\Program Files\Adobe\Acrobat 9.0\Acrobat\Air      (08/05/2013 3:12 am)  104kb
>> C:\Program Files\Adobe\Acrobat 9.0\Acrobat\Browser  (08/05/2013 3:12 am)  104kb
>> 
>> C:\Program Files\Adobe\Reader 11.0\Acrobat\Air      (01/05/2015 2:10 pm)  225kb
>> C:\Program Files\Adobe\Reader 11.0\Acrobat\Browser  (01/05/2015 2:10 pm)  225kb
>> C:\Program Files\Internet Explorer\Plugins          (01/05/2015 2:10 pm)  225kb
>> C:\Program Files\Mozilla Firefox\plugins            (01/05/2015 2:10 pm)  225kb


I can fix my own situation myself by simply copying the new plugin to the two old locations, but that doesn't solve the problem with the checker from here on.

The question is:  Where does FF (and TB) look for its Adobe plugin?  There are three locations to choose from: Reader11\Browser, Acrobat9\Browser, or Firefox\plugins.  The ADD-ON page obviously checks Acrobat9\Browser because it gets 9.5.5 and I'm going to presume it looks at Reader11\Browser in the same sense to get 11.0.11.  But plugin checker is seeing *only* Acrobat9\Browser (9.5.5) for some reason.  It should check whatever ADD-ONs is seeing (ie- both).

And how do the plugins get there?  Does Adobe push it to the FF (and Explorer & AIR) folder when Adobe updates, or do the browsers and AIR each pull it from the Adobe location into their own area?  (If so, from which one?)  And then who is responsible for keeping whom updated?  My suspicion is that Acrobat is simply being courteous because maybe a user has Acrobat and no Reader -- but the two plugins should remain sync'd in the usual case where someone has both.  Who does this (or should do this)?

Which leads back to where does FF look for its Adobe plugin?  THAT's ultimately the copy that must be reported, updated, and kept current.
Hey Dan,

We do not check for the plugins anywhere on the file system, we use navigator.mimeTypes for that. And on that array we look for the a matching mimeType and that check the enabledPlugin property which contains information on the currently installed plugin.

As far as the version problems are concerned, it might actually be DB related. At the moment we have two latest versions in the database, which should not be that case. The one should be latest and the other outdated.

The data is currently:

Latest for Windows and Mac 11.0.11 but, there is also an entry for all platforms and operating systems with a 15.007.20033 version number. On Adobe's site it stated 2015.007.20033 so, I guess that version number is incorrect but also, I suspect that is not the version that will be exposed by the plugin so,  the database needs some updating.
Flags: needinfo?(mgrimes)
Things have changed at Adobe.  Their entire product line is now cloud-based, annually licensed, and generic for all platforms, with for example PhotoShop in the Creative Cloud ("CC") and Reader/Acrobat in the Document Cloud ("DC").  The DC versioning is what's current, and I'd agree it would be "2015...".

I recall long ago discussing multiple versions as the best option for the DB - glad you implemented it.

>> We use navigator.mimeTypes (and) we look for the a matching mimeType and that check the 
>> enabledPlugin property which contains information on the currently installed plugin.

If I understand what you said, sounds like the problem has already happened by the time plugin checker runs.  I'm guessing FF has already loaded my old/outdated version from its preferred location, you ask "who's there", and you discover Acrobat 9.5.5 active.  Whereas I was thinking it would look at what's available.

So what is the "preferred location" and who (Reader, Acrobat, or FF) is responsible for updating it?  I notice AIR (also Adobe) is equally abandoned.  I suspect that after 9.5.5, procedures changed and default locations may have changed (perhaps inconsistently or out-of-step somewhere), and likely FF goes through a prioritized sequence, finding an older (9.5.5) plugin in a higher priority location.


As an experiment, I renamed the old 9.5.5 plugins (nppdf32_955.dll) in both locations, made a reference copy of the current v11 plugin (nppdf32_11011.dll) in the Reader\Browser location, then copied both to the Acrobat\Browser and Acrobat\AIR locations.  Then I checked things.  (I did not close and reopen FF.)

The ADD-ON page still shows Adobe Acrobat (PDF creator) as "9.5.5.136" and the More link shows a single plugin (now "nppdf32_955.dll") with its mimetypes.

On the other hand, "Adobe Acrobat" Reader still shows as "11.0.11.18", but More now shows FIVE plugins -- nppdf32.dll, nppdf32_11011.dll, nppdf32.dll, nppdf32.dll, nppdf32_11011.dll -- and FIVE identical sets of mimetypes.  
These are:  
"nppdf32.dll" in Reader\Browser (original 11011 in its original location);
"nppdf32_11011.dll" in Reader\Browser (reference copy of original 11011 in its original location);
"nppdf32.dll" in Acrobat\Browser (11011 copied from Reader to replace original old 955);
"nppdf32_11011.dll" in Acrobat\Browser (11011 ref copy copied from Reader);
...and "nppdf32.dll" from one of the AIR folders!

And plugin checker now says Adobe Reader 11.0.11 is outdated, rather than 9.5.5 as it had been saying.

I did some creative renaming of files (suffix a,r,e,f,x,z) to track which files get checked.  The checker is reading Acrobat 9.5.5 from the Acrobat\AIR folder!  (When renamed, the plugin doesn't show at all.)  And when other "nppdf32" files are renamed, they fall off the list under More, leaving only the two "nppdf_11011" files showing -- so it obviously prefers to see the \Browser files.

Not sure where this leads, but somehow the More page is preferentially selecting what it sees, and plugin checker may be following the same trail.


CURRENT STATUS:
(i) The Acrobat and Reader folders all contain properly named versions of the 11.0.11 plugin.
(ii) I deleted all of the "955" and "11011" reference copies, except for one of each which I moved to a SAVE area.
(iii) The ADD-ON page recognizes and displays only the 11.0.11 version (not sure where from), and it no longer reports on the Acrobat 9.5.5 version.
(iv) The More page shows THREE same-name nnpdf32.dll (and three sets of mimetypes) -- which would be consistent with seeing the Reader, Acrobat, and AIR copies.


[[ BTW, our Laptop (updated yesterday) shows Reader 11.0.11 up-to-date.  The difference may be that Acrobat is the default handler for extension .PDF, whereas Reader is default on my Tower. ]]
>> [[ BTW, our Laptop (updated yesterday) shows Reader 11.0.11 up-to-date.  The difference may 
>> be that Acrobat is the default handler for extension .PDF, whereas Reader is default on my Tower. ]]

Sorry, not true...  The Laptop DOES say "outdated".  And in all other regards, its files and versions are the same as the Tower, with the same issues too.
Further to my Comment 89...

I checked over my Netbook tonight.  This machine is running Adobe Reader 11.0.11 (automatically updated a few days ago).  It has NEVER had Acrobat installed, and it probably has never seen Adobe Reader 9 either.  Consistent with this, I see only a Reader 11.0 folder under Adobe in Program Files -- no Reader 9.0 folder and no Acrobat of any kind.

There are exactly two copies of nppdf32.dll installed -- both in Adobe Reader, under Browsers and AIR.  The ADD-ONs page in FF shows the correct version (11.0.11.18).  The More link shows the name twice (as per above) -- in fact when I created a recognizable copy in Adobe's AIR folder, THREE names were reported!

So obviously only the Adobe location matters to FF -- consistent with my testing above -- and yet the FF and Explorer locations had been updated too on my other machines.  (I'll bet Adobe did this, because somehow I don't think FF would update Explorer.  It makes sense for Adobe to know how past versions of things worked and to graciously update as many locations as necessary.)  Unless FF keeps its own copy to guard against removal or infection of the Adobe files -- not supported by what I see on the Netbook.

We're back to: Does FF search multiple locations and does it have a preferred location?  All pieces (FF, ADD-ON page, More, and plugin check) should follow the same route for consistency -- and they don't.


I'm sure this all makes plugin checks exponentially more fun, because how do you know which plugin to report as outdated?  A first step could be to reduce the complexity.  If FF stopped using its local copy of the plugin, then in principle perhaps FF should remove it.

In my own case (Tower before manual fixing, Laptop as currently set), the plugin checker tells me my Adobe Acrobat (PDF creator) at 9.5.5 is outdated -- which I know.  But let me play dumb: I can't fix it because I don't want to update Acrobat at this time.  If I do hit the Update button, it updates or replaces my Adobe READER files, not the Acrobat (creator).  Then plugin check tells me it is still out of date, because the 9.5.5 file has NOT been touched and -- being dumb here -- I don't know where it is or how to manually replace it.  Average Joe User is in the same boat.
Thanks for all of the info Dan, I am going to run some tests and see if I can reproduce these issues.
@SCHALK...

Just to be clear, here are the EXACT folder paths in full (note trivial variations in casing):

C:\ Program Files \ Adobe \ Acrobat 9.0 \ Acrobat \ Air
C:\ Program Files \ Adobe \ Acrobat 9.0 \ Acrobat \ Browser

C:\ Program Files \ Adobe \ Reader 9.0 \ Reader

C:\ Program Files \ Adobe \ Reader 11.0 \ Reader \ AIR
C:\ Program Files \ Adobe \ Reader 11.0 \ Reader \ Browser

C:\ Program Files \ Mozilla Firefox \ plugins
C:\ Program Files \ Internet Explorer \ Plugins


The Reader 9.0 path contains only a few files and subfolders, looks like residual stuff following an update, possibly shared with Acrobat.  Note there is no Reader 10.0, which would have existed at some point, but probably was totally flushed.  No Acrobat 10 either (no need to share?), and of course no Acrobat 11 in my case.

In some of the verbal descriptions, you'll see the plugin referred to as Adobe Acrobat plugin for Netscape and Firefox.  Recall that Reader was originally called "Adobe Acrobat" back in late MSDOS and early Windows days -- maybe this persists here, because as far as I know the plugin reads PDF files but does not create them.

Best of luck with it!
Flags: needinfo?(mgrimes)
Alrighty, so I looked at this and found the following.

In the database we have the following versions:

15.007.20033 * platforms * OS - latest

11.0.11 * platforms - Mac, Windows - latest

11.0.10 * platforms - Mac, Windows - vulnerable

...... (list of older versions)

I tested on Windows, using the following versions:

10.1.4
11.0.1.36
11.0.10.32
15.007.20033

This gives the following results

10.1.4 - vulnerable
11.0.1.36 - outdated
11.0.10.32 - outdated
15.007.20033 - latest

One thing that looks confusing on first look is that it seems that 11.0.1.36 is vulnerable because outdated plugins uses the same button as vulnerable. Also, confusing is that 11.0.1.36 and 11.0.10.32 is outdated, when the second one should be latest.

This is how the code works however:

Version matching is exact, and I believe it should remain this way. Therefore, version 11.0.10.32 does not match anything in the latest nor vulnerable list, nor does 11.0.1.36 for that matter.

The next check then is to determine whether this version is greater than the 'absolutely' latest (v. 15.007.20033 in this case) or not. If it is, it is marked as newer and added to the latest list. If not, it is marked as outdated, and added to the outdated list in the UI.

This all works as expected as can be seen from the results above. The one thing I do find confusing is that the button used for outdated versions is the same color and uses the same label as vulnerable plugins and I will be logging a bug and changing this so the distinction is more obvious.
Blocks: 1168097
No longer blocks: 1168097
Re Schalk Comment 94:
>> The next check then is to determine whether this version is greater than the 'absolutely' 
>> latest (v. 15.007.20033 in this case) or not. If it is, it is marked as newer and added to 
>> the latest list. If not, it is marked as outdated, and added to the outdated list in the UI.

I know this is splitting hairs but:  What about the v11 user (such as myself) that has the latest v11 updates from Adobe but has not taken the big step of updating to the next version.  (Rationale: Reader is free, so likely people will update.  Acrobat is paid, so may not be updated.)  In fact my v11 plugin is NOT "out of date", although it is "behind the times", shall we say.

If you tell some users their file is out of date, they may panic into an update course they don't need or want yet (paid Acrobat, for example).  I would get numbed hearing my "11.0.11.18" Reader is out of date and I might then miss "11.whatever" when it comes out.  (Adobe will still be supporting v11 for several more quarters.)

Is there any way to display the "latest" available so we know two things:
   (1) What's there is "out-of-date" or "behind the times" or "vulnerable";
   (2) Why it's old (newest is such-and-such).

I will agree that users should always check the source vendor for the latest update information (in this case, Adobe for Reader), but that doesn't always work either, given the previously described scenarios where the plugin may be outdated but not the product it is supposed to be for.  I think the plugin checker should take its best stab at giving the best (& most) information possible.


And button color:
>> The one thing I do find confusing is that the button used for outdated versions is the 
>> same color and uses the same label as vulnerable plugins and I will be logging a bug and 
>> changing this so the distinction is more obvious.
>> ...I suggest changing the color to gray and the label to just 'Update' (new Bug 1168097)

Gray is good (neutral).  At first I thought yellow/gold/orange for caution, but it's probably better to reserve these for something more significant.

You might consider using gray to signal out-of-date, yellow for behind-the-times, and red for vulnerable.  I'd want to update something vulnerable regardless of its version, even if it only takes me to the most recent release of that version and not the most recent version of the product.
"I know this is splitting hairs but:  What about the v11 user (such as myself) that has the latest v11 updates from Adobe but has not taken the big step of updating to the next version.  (Rationale: Reader is free, so likely people will update.  Acrobat is paid, so may not be updated.)  In fact my v11 plugin is NOT "out of date", although it is "behind the times", shall we say.

If you tell some users their file is out of date, they may panic into an update course they don't need or want yet (paid Acrobat, for example)."

Fair points, and I agree however, I believe it might just be that the content on the page does not effectively explain the difference between vulnerable and outdated clearly.

When a plugin is outdated, it simply means there is a newer version but, there is no harm yo the user in continuing to use their current versions whereas vulnerable means, the version has a known security exploit and the user could come to harm if they do not update immediately.

So, I reckon a combination of button color and content updates can go a long to way to improve the situation.
My point is that (in my case) v11 is NOT outdated -- it is the absolute latest and up-to-date available from Adobe -- for that release.  The release is, however, behind the times in the overall scheme of things.  I'm not sure that can be said with just two choices of "outdated" and "vulnerable", unless you have two different colours or actions for "outdated".
Blocks: 1172986
No longer blocks: 1172986
FEEDBACK:  Confirming some operations
Today I ran the new Plugin Check for the first time (on two of my three PCs).

(1) Adobe Reader in both cases said "Outdated" in yellow -- both TRUE because I'm running v11 Reader and not the new DC cloud version, although as mentioned I'd prefer to see another option because I do have the most up-to-date v11.

(2) Adobe (Shockwave) Flash was out of date too.  Interestingly -- and exactly what I asked for -- the netbook had v17.0.0.134 flagged as "Outdated" in yellow.  The tower had newer v17.0.0.188 marked as "Vulnerable" in red.  I updated both OK.

Schalk, can you confirm that your database indicates the same?  In other words, 17.0.0.134 was 'old but safe', but 17.0.0.188 was 'old and dangerous'.  If so, then it works as requested -- thanks.
Flags: needinfo?(schalk.neethling.bugs)
Dan,

Thank you for the feedback. Our data does indeed match so, we can go ahead and close this bug \o/
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Flags: needinfo?(schalk.neethling.bugs)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.