845638 - Simply PFS on the server-side by using a static JSON file

Status: RESOLVED INCOMPLETE

(Toolkit Graveyard :: Plugin Finder Service, defect)

Description

[Justin Dolske [:Dolske]]

We're starting the process of removing PFS from Firefox. This is generally being driven by (1) wanting to discourage plugin installs as being bad for the web and (2) the current UI is an abomination.

One piece of this (especially wrt to #2) is having the client (Firefox) do most of the work the server does:

https://github.com/mozilla/zamboni/blob/master/services/pfs.py

Ideally this would be a simple lookup table in Firefox, mapping a mimetype+platform to a download/install URL. No PFS server needed at all!

The catch, of course, is that distributing files security at scale still takes effort, so instead of a simple static SSL download URL we have to deal with http CDNs + hashes for security. And those hashes can change with every plugin release. Which means we can't hardcode everything into Firefox, because omglol we're not going ship a Firefox update everytime there's a Flash/Java security exploit.

So we still need to use something like PFS, but we can simplify it enormously.

I'd propose serving a static JSON file, say https://pfs.mozilla.org/bacon.json, with contents like: (TBD, I'm just making this up on the fly)

 { 
  flash: {
           windows_url: "http://cdn.abobe.com/blah.exe",
           windows_hash: "sha1:829e8e1f5d881996b8c3",
           default: "http://adobe.com/getflash"
         },
  java:  {
           ... etc ...
         }
 }


Firefox would have some internal table like

  ["application/x-shockwave", "flash", "https://pfs.mozilla.org/bacon.json"],
  ["applcation/java", "java", "https://pfs.mozilla.org/bacon.json"],
  ... etc ...

Eventually the JSON file might even be able to exist on the vendor's SSL site, so that we can stop having to coordinate for hash updates.

Comment 1

[Justin Dolske [:Dolske]]

tl;dr: I want to host a static JSON file on a Mozilla server, I hope that's easy?

Comment 2

[Wil Clouser [:clouserw]]

(In reply to Justin Dolske [:Dolske] from comment #1)
> tl;dr: I want to host a static JSON file on a Mozilla server, I hope that's
> easy?

Easy on our end.

Comment 3

[Benjamin Smedberg]

Hrm. I think we might need to be more expressive somewhere along the chain here. In particular, we have situations like the following:

* Normally we want to link to the Flash installers. But on Win8, we don't, because Flash is supposed to be preinstalled as part of the OS, and we should link to a support page instead.
* Weed out older versions of Windows as plugin vendors drop support.

I suspect for that reason we should consider at least passing metadata like the current OS details in the query string, so that we have the option of providing a different file (using apache rewriting, or more complicated scripts) if necessary.

Also from a client perspective, I don't think we should have a MIMEtype mapping in the client at all. Instead, we should just have a single file with MIMEtype mappings. We would just pull down this file once a day and cache it for instant lookup:

{
  "mimetypes": {
    "application/x-shockwave-flash": "flash",
    "application/x-java-.*": "java",
    "application/x-silverlight(-2)?": "silverlight"
  },

  "plugins": {
    "flash": {
      "displayName": "Adobe Flash",
      /* Link directly to Windows installer */
      "installWindows": {
        "installerURL": "http://adobe-cdn...",
        "installerHash": "sha1:..."
      },
      /* Link Mac and Linux users to Adobe install URL */
      "installMac": {
        "downloadURL": "https://get.adobe.com/flashplayer"
      },
      "installLinux": {
        "downloadURL": "https://get.adobe.com/flashplayer"
      },
      /* Link other users to Mozilla support */
      "about": "https://support.mozilla.org/FlashEntryURL?locale=%locale%etc"
    },
    /* Don't ever link directly to Java installers, always go through SUMO */
    "java": {
      "displayName": "Oracle Java",
      "about": "https://support.mozilla.com/JavaEntryURL?locale=%locale%etc"
    },
    "silverlight": {
      /* Link Windows and mac users to MS download page */
      "installWindows": {
        "downloadURL": "https://www.microsoft.com/getsilverlight/"
      },
      "installMac": {
        "downloadURL": "https://www.microsoft.com/getsilverlight/"
      },
      "about": "https://support.mozilla.org/SilverlightEntryURL?locale=%locale%etc"
    }
  }
}

Then if/when Adobe wants to host their own installer hashes, we can add something like this:

  "installWindows": {
    "installerPointer": "https://get.adobe.com/flashplayer/ff-win32.json",
    "downloadURL": "https://get.adobe.com/flashplayer"
  }

That way oldrev Firefox will get the FP install page, and new users will get the Adobe updates directly.

Comment 4

[Justin Dolske [:Dolske]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #3)

> * Normally we want to link to the Flash installers. But on Win8, we don't,
> because Flash is supposed to be preinstalled as part of the OS, and we
> should link to a support page instead.

Right, there are a lot of details I haven't through through yet. :)

> Also from a client perspective, I don't think we should have a MIMEtype
> mapping in the client at all. Instead, we should just have a single file
> with MIMEtype mappings. We would just pull down this file once a day and
> cache it for instant lookup:

That works too, although I'd prefer to avoid dealing with the issues preloading and caching inevitably bring. And the server-side load, since right now PFS is only ~1M reqs/day. Will think this over as we work out the details.

Comment 5

[Carsten Book [:Tomcat]]

just as idea, maybe its possible to do the json work via plugins.mozilla.org (thats the database thing that powers plugincheck) and it generates a least single json files like:

https://plugins.mozilla.org/en-us/plugins/detail/adobe-flash-player.json

Comment 6

[Benjamin Smedberg]

We're going to remove PFS from Firefox, and leave the existing PFS server alive for the remaining ESR release cycle before also killing that. I don't think this refactoring work is worth doing any more.