1052069 - Add Openh264 Video Codec provided by Cisco Systems, Inc. to Plugincheck

Status: RESOLVED WONTFIX

(Plugin Check Graveyard :: Database, defect)

Description

[DJ-Leith]

Very soon all Firefox 33 Desktop users will have this plugin.
It will be delivered as they update their Firefox.
So, very close to 100% of Desktop users will have this plugin.

See bug 1009816 "Firefox desktop: openh264 updates: check, download, install"

homepage is
http://www.openh264.org/

"Video Interoperability on the Web Gets a Boost From Cisco's H.264 Codec"
https://blog.mozilla.org/blog/2013/10/30/video-interoperability-on-the-web-gets-a-boost-from-ciscos-h-264-codec/

See also wiki for GMP
"Gecko Media Plugins (GMPs)"
https://wiki.mozilla.org/GeckoMediaPlugins


In my opinion, it would be good to have Plugincheck check most popular plugins.
about:plugins (obviously) can find it, in my opinion, Plugincheck should assess and report on it too.
This one will be very popular / very widely installed.


There are a number of atypical features of the Openh264 plugin compared to most plugins.

1. Initially (perhaps always) it will be delivered without any user intervention.
Users may not even notice its arrival.

2. Unlike most plugins, which are 'machine wide' - i.e. all Firefox profiles use the same plugin,
Openh264 is installed per profile.

  See also bug 1045209 
  "The OpenH264 path should be relative to the profile directory and include a version subdirectory" 

3. about:plugins does NOT list a MIME Type (this may affect how you 'detect the plugin'
at the 'Plugincheck web site') - see the wiki for GMP (above).

4. It is possible to switch off automatic updating of Openh264;
both in the about:addons, 'plugins Tab' and via setting in about:config
So, it might be possible for a User to have an 'out of date' or a "vulnerable" version.


Checks done before filing this bug include:

A.  I can't find a bug in bugzilla about adding this to the Plugincheck Database.

B.  Using Aurora 33.0a2 (which has the plugin installed)
    and 'doing a Plugincheck',
      via about:addons, Plugins 'Tab' - use the  link
      via about:plugincheck - use the link
        * no report is given (implies no test is done).

C.  Using Aurora 33.0a2 (which has the plugin installed) with
    user_pref("general.useragent.override", "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0)
    Gecko/20100101 Firefox/31");

    and

    user_pref("plugins.enumerable_names", "*"); all plugins can be enumerated, usually finds
    "Unknown" plugins, if they are not in the Plugin Database.

    Same tests as B. as well as testing on STAGE
    https://www.allizom.org/en-US/plugincheck/

    This does NOT 'find Openh264' and say it is "Unknown".

    So, just 'adding it to the Database' will not be enough.
    I imagine you will also need to detect the plugin
    in both
      * the 'existing Plugincheck - using enumeration'
      * the 'new Plugincheck - using the JSON list'


DJ-Leith

Comment 1

[Daniel Veditz [:dveditz]]

You've identified a real problem here, but adding it to plugincheck is not the only possible solution. Since it's not really a plugin we don't want pages to be able to enumerate it, which makes it hard to imagine what plugincheck could ever do to detect an out of date version. If we do detect an out of date version (because the user has turned off updates) where could we send users with the "Vulnerable" button? There's not really an install download page anywhere.

An alternate solution could be to switch Openh264 to click to play (can we do that?) if updating has been turned off (and/or we somehow know we're out of date), and drop an infobar telling the user it's out of date and a danger with a button to reenable updates. Or maybe the button is just a one-time manually initiated update.

Comment 2

[Daniel Veditz [:dveditz]]

My proposed alternative would take this out of the realm of a plugincheck page change (which I think isn't possible anyway) back to a client mechanism. One that unfortunately has UI localization implications so it's got a long lead time.

Comment 3

[DJ-Leith]

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.[2]


*** Plugincheck ***
(In reply to Daniel Veditz [:dveditz] from comment #1)
> we don't want pages to be able to enumerate it, which makes it hard to imagine what
> plugincheck could ever do to detect an out of date version.
Indeed, but the new 'plugincheck service' (currently used in Fx32+) uses a 'JSON list'
and does NOT use any enumeration.  IIUC it does use MIME type.[1]

> ... detect an out of date version.
There is discussion in bug 1045209 comment # 16 onwards of using a path
(and sub directories) to identify the version.  So, a possible method.
I've no idea how robust this would be.


*** Not using Plugincheck ***
> You've identified a real problem here, but adding it to plugincheck is not the
> only possible solution.
My two cents, is to indicate on Plugincheck that Openh264 is not being assessed
(if this is the case).[2]

How about using Firefox Health Report (FHR)?
Perhaps FHR could report that 'automatic updating of Openh264 had been switched off'.

  See also, bug 952914 (Dec 2013 and Jan 2014) Chris Peterson and I discuss interim
  measures (now that bug 757726 had landed) including how best to communicate changes.

    I proposed a user_pref("plugins.enumerable_whitelist_URLs"
    as a work around for sites (including Plugincheck if necessary) having more
    access than default for 'plugin enumeration'.

    (from bug 952914)
>   Two other ideas:
> 
>   B. Allow Nightly, Aurora and Beta to default to
> 
>   user_pref("plugins.enumerable_names", "Java,Nexus Personal,QuickTime,Shockwave");
> 
>   BUT change the Preference to "*" on the Release version (18 March 2014) to 
>   user_pref("plugins.enumerable_names", "*");
    This idea was taken up, Chris Peterson had of course already thought of this,
    in bug 952602 and is now the default for all releases.


[1] Bug 956905 comment # 148 has a
Status Update on 'the plugincheck service' as at 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 is much more detail, and many references, in that bug comment.

Since then, the version of Fx that uses enumeration has been bumped on.
So, FX 31 is still using enumeration and Fx32+ is using the JSON list.

This happened very close to the release of Fx31.
See bug 1020133 comment # 5 onwards.

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

DJ-Leith

Comment 4

[Georg Fritzsche [:gfritzsche]]

(In reply to Daniel Veditz [:dveditz] from comment #1)
> An alternate solution could be to switch Openh264 to click to play (can we
> do that?) if updating has been turned off (and/or we somehow know we're out
> of date), and drop an infobar telling the user it's out of date and a danger
> with a button to reenable updates.

No, there is no click-to-play for OpenH264 - it is a GMP plugin and those are implemented separately from NPAPI (and not directly instantiated from the web).

I think we need a more general bug about how to handle this issue in "WebRTC: Audio/Video".

Comment 5

[Benjamin Smedberg]

So *this* bug as filed is WONTFIX. plugincheck is about NPAPI plugins, and is not an appropriate place to deal with this part of Firefox.

That said, part of the original product spec for OpenH264 was that the Firefox blocklist could be used to mitigate risks like this. Georg do you know if that was implemented or whether it was ever tested? If not please file the appropriate bugs for it.

Comment 6

[Georg Fritzsche [:gfritzsche]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #5)
> That said, part of the original product spec for OpenH264 was that the
> Firefox blocklist could be used to mitigate risks like this. Georg do you
> know if that was implemented or whether it was ever tested? If not please
> file the appropriate bugs for it.

Ok, no, this not was implemented - filed bug 1086668.