Are we concerned about cases where users have installed system Flash and don't update it? Given Adobe's bundling strategies and error messages all over the Internet that say "download and install Flash by doing X", I can imagine that many people have some ancient version of system Flash resident on their system.

In other words, if System Flash is old enough that Chrome will refuse to load it, should we still not get a component Flash?

I would rather fix the issues with component Flash when possible than allow older system.

In the context of the recent issues with disappearing .dlls, we could simply verify that the DLL is present before loading the component, but perhaps this request comes in a context that I'm unaware of.

Adobe driven updates shouldn't be a problem (in terms of being out of date).  It used to be, that Adobe didn't have a reliable/ silent update mechanism (about 3-4 years ago), but they modernized to keep Firefox, Opera, etc... up to date, and the updater that's bundled with the PPAPI/Chromium Flash installer works rather well.  In parallel, Chrome's plugins.json affords protection to prevent old versions of Flash Player from lingering, so that also lessens my concern.

There are cases (e.g. where AV, Bit9-style interventions, Firewalls blocking update services, etc...) that will make it impossible for users to get viable component updates from Google.  For those corners, this approach will allow them to get (and keep) Flash Player running.

Re: missing .dlls, agreed that we should likely do some form of a component verification (before loading a component, perhaps before deleting the previous component), however, if there is no version to fall back on (because we deleted it or it doesn't exist), these users will continue to have issues w/ Flash not loading.

On the Enterprise side... there will likely be a very strong correlation between admins deploying Flash via MSI and wanting component updates being disable (i.e. I'd anticipate in practice they will be mutually exclusive).

> Chrome's plugins.json affords protection to prevent old versions of Flash Player from lingering
I think you mean "from loading", right? We won't delete an old system-level install.

IIRC while installing system Flash there is a radio button that lets you choose between silent updates / prompt-for-updates / never check for updates; given that we don't have this feature in Omaha and people still go to great lengths to disable the updater, I assume the long tail of old system Flash is worse than the long tail of old Chrome.

My primary concern is there may be a significant number of users in the system-Flash long tail who don't know they are there, and if we stop giving component updates to these users their experiences will go from "Flash is working" to "Could not load plugin - and reinstalling Chrome and cleaning my profile doesn't help". At minimum I suggest we add some UMA that allows us to estimate the general distribution of system flash versions among consumers before proceeding.

Two other points: if the component update / install itself is blocked by AV or firewall, we'll fall back to system flash, so there's no need to make a change to disable component Flash. It's only if AV blocks us from loading the DLL that we have a problem.

With regards to enterprise, I assume they will disable component Flash via the group policies we already provide, so no changes are needed to support the enterprise use case.

Anyways my main concern is that we might affect an unknown number of consumer users in a negative way.