Pepper Flash Player Mac



In the Flash section there should be 2 or 3 different versions of Flash listed. If the Flash section only has one Flash file listed, Click Here to go to the Adobe website and download and install the Adobe Flash Plugin for Non-Internet Explorer browsers. The first Plugin listed in the Flash. Jan 13, 2021 After installing Chrome, “ Pepper Data Shockwave Flash System” did not exist under Default, so I manually created those sub-folders under Default, created the mms.cfg file, launched Chrome, steps 1-5 worked ok, but I did not get a popup saying Flash is out of date and my application (vSphere Web Client trying to login to vCenter v6.0) fails. Ruffle is a Flash Player emulator built in the Rust programming language. View 6 alternatives.

  1. Google Chrome has Adobe Flash Player installed by default in its browser software and Pepper Flash Player is an extension for Mac OS X computers that manages flash contents. There are multiple versions of flash extensions running to manage the flash contents you view on the web.
  2. Aug 06, 2015 'Pepper Flash Player is maintained by Google, and is newer than Adobe Flash Player. Adobe currently still provides security fixes for Adobe Flash Player. Google provides newer features in Pepper Flash Player. Pepper Flash Player can currently only be used with Chromium(and with Chrome).
If you're adding a new API, see Pepper API Best Practices for helpful guidelines and our process is documented in Pepper API Proposals.

Quick reference to important code locations

  • ppapi — Root PPAPI code.
    • api IDL versions of the interfaces.
    • c — Public C binary interface (generated by the IDL, checked into the tree)
    • cpp — Convenience C++ wrapper around the C interface.
    • generators — the IDL-to-C compiler
    • host — code used in content and chrome to implement the backends for the various resources.
    • native_client — The NaCl trusted plugin
    • proxy — Chrome IPC-based proxy
    • tests — Source code for the unit tests.
    • shared_impl — Contains implementations for Pepper objects that we want to share between the proxied (ppapi/proxy) and the in-process version (content/renderer/pepper).
    • thunk — Converts the C PPAPI calls from the plugin into C++ for the browser implementation.
  • chrome/browser/renderer_host/pepper/pepper_*_host.* — Backend ('host') implementations of new-style resources in the Chrome browser process.
  • chrome/renderer/pepper/pepper_*_host.* — Backend ('host') implementations of new-style resources in the Chrome renderer process.
  • content/renderer/pepper/ppb_*_impl.* — Implementation of the old-style in-process resources and their connection to WebKit.
  • content/browser/renderer_host/pepper/pepper_*_host.* — Backend ('host') implementations of new-style resources in the Content browser process.
  • content/renderer/pepper/pepper_*_host.* — Backend ('host') implementations of new-style resources in Content renderer process
  • content/renderer/pepper/pepper_plugin_delegate_impl.* — Delegate interface used to talk to the browser from the WebKit code.
  • content/renderer/render_view.cc — Allocates the plugins (see createPlugin).
  • chrome/test/ppapi/ — Code to run the tests as part of the Chrome browser tests.

Issue tracking

We're tracking PPAPI bugs in the Chromium issue tracker to keep things simpler. To file a pepper-related bug, use all of the following labels:
  • Area-Internals
  • Cr-Internals-Plugins-Pepper
If the bug relates to a Native Client specific part, additionally use the label:
  • NaCl
See the current open bugs under the 'Cr-Internals-Plugins-Pepper' label.

Running a plugin in Chrome

There are two modes of operation, 'trusted' and 'untrusted' plugins. Untrusted plugins use the Native Client to safely run code from the web and is cross-platform. Trusted plugins are loaded directly in either the renderer process or a separate plugin process as platform-specific libraries.
You run a plugin in trusted mode by building a platform-specific library implementing the API. For random manual testing, you can use one of the examples, the graphics 2D 'paint manager' example is a good one for general hacking (see ppapi/examples/2d/). A trusted plugin is instantiated by registering it to handle a MIME type on the command line. Provide the full plugin name (which varies by platform), followed by a semicolon, followed by the MIME type. The MIME type should match the 'type' attribute of the object tag specified on your page. For the paint manager example plugin on Linux, you would run:
chrome --register-pepper-plugins='/local/src/out/Debug/lib/libppapi_example_paint_manager.so;application/x-ppapi-example-2d' file:///local/src/ppapi/examples/2d/2d.html
In this case, application/x-ppapi-example-2d is what is specified in the example.html page. This can be anything you want, as long as the two types match. Note also that we specify --ppapi-out-of-process. In-process mode is being deprecated so it's a good idea to use this in general.
On Linux, you can automatically launch this process in a new GDB instance in a new xterm, which will help you in debugging startup problems. Use this command line switch:
--ppapi-plugin-launcher='xterm -title plugin -e gdb --eval-command=run --args'

'Old' resource and proxy design

Most resources are currently implemented using the old proxy design. There are several layers, and each resource is implemented once for in-process and once for out-of-process.
The in-process implementations are in content/renderer/pepper/ppb_*_impl.* These integrate with the rest of Chrome by using blink or other parts of content/renderer.
The proxy implements interfaces for the out-of-process case. They are implemented in ppapi/proxy/ppb_*_proxy.* The proxy has a ppapi/proxy/dispatcher.h on each end of the IPC channel. The specialization PluginDispatcher is on the plugin side, and the specialization HostDispatcher is on the renderer side. Each interface has a Proxy object for which there is one per dispatcher, and a resource object that corresponds to the PP_Resource object.
Some proxy objects and implementations share some or all of their code. Shared code can be put into ppapi/shared_impl/ppb_*_shared.* to avoid duplication.
Life cycle of a plugin -> renderer call:
  1. Plugin calls PPAPI function.
  2. Thunk layer converts this to a C++ call on a resource object.
  3. Resource object sends IPC message to renderer via the PluginDispatcher.
  4. The HostDispatcher receives message and forwards it to the appropriate interface proxy object in the renderer.
  5. Interface proxy converts IPC message back to a PPAPI call and issues it to the in-process implementation.
  6. Resource 'impl' gets call and performs action.
Unlike the 'new' design there is no standard way of communicating with the browser. Some components (TCP/UDP sockets) do this with hand-rolled tracking.

'New' resource and proxy design

All additions should use the new proxy design. It is higher performance and involves writing much less code. The new and old designs exist in parallel and we're moving resources over one-by-one.
The resource object is implemented once (in ppapi/proxy/*_resource.cc). This resource sends IPC to a 'host' object in the browser and/or renderer process to do its work. The host object does not speak the Pepper API, it just uses Chrome IPC types. It can be in the renderer process, the browser process, or potentially both or neither (if all functionality is contained in the plugin process). It can also be implemented in the chrome or the content modules.

Where does your host object live?
  • content/renderer/pepper/ — Probably the most common location. Most resources that interact with blink or other renderer functionality will go here.
  • chrome/renderer/pepper/ — Use for Chrome-only interfaces (Flash, PDF, other custom stuff for custom Google plugins).
  • content/browser/renderer_host/pepper/ — Use instead of or in addition to content/renderer/pepper when your resource needs to talk to the browser process for some reason.
  • chrome/browser/renderer_host/pepper/ — Use instead of or in addition to chrome/renderer/pepper when your resource needs to talk to the browser process for some reason.
Each of the above directories has a 'host factory' file in it for creating the hosts for your resource. You'll also have access to the BrowserPpapiHost / RendererPpapiHost which will allow you to make calls into the system and get context for your resource.
We support in-process mode for legacy interfaces needed by certain plugins. New resources do not need to support in-process. For resources that need in-process, we have a 'fake' IPC channel that allows the 'proxy' and 'host' to be in the same process. To wire this up, first get your out-of-process implementation working, then hook up creation through content/renderer/pepper/pepper_in_process_resource_creation.cc. Note that this only works for resources implemented in content/renderer. Other types of hosts are not supported in in-process mode.
Life cycle of a plugin -> renderer call
  1. Plugin calls PPAPI function.
  2. Thunk layer converts this to a C++ call on the proxy resource object.
  3. Proxy resource does a CallRenderer with its message. This gets embedded into a 'resource call' IPC message which encodes the resource ID and instance.
  4. The ResourceHost in the renderer receives the message and finds the corresponding resource host object.
  5. The resource host decodes the message and performs the operation.
Note that creation is a separate step. The resource creates the host in the browser or renderer by calling SendCreateToBrowser or SendCreateToRenderer. This is picked up by the host factory in the directory holding the resource.

Adding a new interface

Please look at our Pepper API Process Doc before starting to implement a new API.
To make the interface definitions (this is the same between the 'new' and 'old' proxy designs):
  1. Create the IDL file.Most new interfaces will be dev so would be called ppapi/api/dev/ppb_foo_dev.idl.
  2. Generate the C interface file. Run the script ppapi/generators/generator.py. Make sure to run it from within the generators directory. This should make a corresponding ppapi/c/dev/ppb_foo_dev.h file which you should add to your CL.
  3. Write a C++ wrapper for your interface. (Some classes may not need C++ wrappers, check with Brett if you're unsure.) The corresponding location would be in ppapi/cpp/foo_dev.h. This is pretty easy and you should be able to copy the surrounding classes. Add it to the .gyp file.
  4. Add your new interface file to the C test list inppapi/tests/all_c_includes.h. This is how we make sure that everything continues to compile in C (rather than just C++ mode).
To hook up your interface (this is the same between the 'new' and 'old' proxy designs):
  1. Write a C++ 'API' for it. This is in ppapi/thunk/ppb_foo_api.h. This defines the virtual interface that Chrome will use to implement your interface. If your interface is a bunch of functions rather than a new resource, you can just add it on to ppb_instance_api.h. Check with Brett if you're unsure. Add a creation function for your resource to ResourceCreationAPI.
  2. Write a thunk for it. This converts the C PPAPI calls for your interface to C++ calls on the API you made in the previous step. Look at a similar interface to see what it does. Typically the Create function on a resource API would go through the ResourceCreationAPI object (add a function there for your new resource type) and the rest of the functions go through to your API. Add the thunk and API to ./ppapi/ppapi_shared.gypi.
  3. Register the interface with Chrome. Add it to ppapi/thunk/interfaces_ppb_public_dev.h. Follow the directions in the _stable version of that file. This tells Chrome about your interface name and connects your thunk function to it. This file is included in various places that define implementations of the macros to register the name->vtable mapping.
Implement the resource 'proxy' (this is different from the 'old' design):
  1. Create the proxy file. This is called FooResource as opposed to 'old' design resources which would be PPB_Foo_Proxy.
  2. Define the IPC messages you need. Add them to ppapi/proxy/ppapi_messages.h. You'll generally need one for creating your host resource, one for each 'call' from the proxy to the host, and one for each 'reply'.
  3. Write a unit test in the same directory. This should just emulate the IPC layer. Be sure to test different edge conditions and make sure that the proper IPC messages are sent in response to plugin calls, and that the correct plugin callbacks are called in response to IPC messages.
Implement the resource 'host' (this is different from the 'old' design):
  1. Write the resource host. Put the file in one of the four locations discussed above.
  2. Hook up the host creation. The host factory in the same directory as your resource host should have a switch in it. Be sure to check the permissions if your interface is dev/trusted/etc. to make sure the plugin is allowed to create such resources.
  3. Implement the IPC message handlers. You should be able to copy how an existing resource host works to get the calls you expect.
  4. Keep in mind that the plugin is untrusted. It could be trying to exploit you. Don't trust that it has permission to do anything, and rigorously check all parameters.

Designing your interface

Features are implemented as 'interfaces.' An interface is just a vtable identified by a string name. Most features are implemented as 'resources' which are generic refcounted project identified by an opaque handle. Your normally have an interface that exposes all the functions your resource supports.
  • The first two functions in a resource's interface should be PP_Resource Create(PP_Instance, ...) to allow creation of your resource and PP_Bool IsFoo(PP_Resource) to allow for type checking.
  • Since most stuff happens out-of-process, these functions should be asynchronous. Asynchronous functions should take a PP_CompletionCallback argument and return an int32_t (which will normally be PP_OK_COMPLETIONPENDING for asynchronous completion). It's important that your create function not be asynchronous because then the caller has no way to cancel the callback (normally you can just delete the object). If you object constuction requires asynchronous completion, have a simple synchronous Create function and then an asynchronous Open or Init function which you would call after creation.
  • Many completion callbacks want to return data. These should be of the form:
    int32_t DoFoo(PP_Resource resource, PP_Var* output_arg, PP_CompletionCallback cb);
    Your C++ wrapper can then take a CompletionCallbackWithOutput<Var> which has template magic to convert the output argument to a parameter on the callback function.
Pepper Flash Player Mac

Writing error logs

In a resource implementation, use Resource.Log() to display a message in the console (in the JS inspector) for the page. In other places, use PpapiGlobals::LogWithSource().
  • Log messages should have the name of the interface, a dot, and the function name, followed by a colon and the text of the message. The rest of the message should begin with a capital and end with a period as with Chrome comments. So: 'PPB_Foo.Frobulate: The bar is invalid.'.
  • Not all errors should have error logs. In fact, most shouldn't. Most functions should have well-defined error conditions that are described in the documentation for that function. In this case, it's unnecessary to log an error because the caller can easily see they got a NOACCESS and look up what that means in the context of your function, for example.
  • Some things may be tricky or easily called incorrectly, may have no return value, or ambiguous return values. In these cases, it can be useful to add a Log call to tell the programmer how they messed up.

Architecture of the renderer implementation

It may help to open the NPAPI plugin architecture design doc in another tab. This section will compare Pepper to the 'in process' NPAPI implementation. Most of the names are the same between Pepper and NPAPI, except we use the webkit::ppapi namespace and NPAPI uses the webkit::npapi namespace. If you haven't already, you should also understand the important concepts of PPAPI.
  • To WebKit, a Pepper plugin is the same as an NPAPI plugin. We implement the WebKit::WebPlugin interface as webkit::ppapi::WebPluginImpl in ppapi_webplugin_impl.cc. This is our analog of NPAPI's webkit::npapi::WebPluginImpl.
  • The PluginInstance object talks to the plugin's PPP_Instance interface, and receives requests through the browser's PPB_Instance interface.
  • The PluginInstance owns a reference to the PluginModule which represents the shared library loaded in the renderer. The PluginModule is shared between all instances of that plugin. It handles loading and unloading of the library, implements the PPB_Core interface, and also implements the GetInterface function that the plugin module uses to get all other browser interfaces.
  • In some cases, the plugin needs to talk 'up' the browser stack. For example, a certain operation might require that the browser process do something on behalf of the plugin. To support this, there is the webkit::ppapi::PluginDelegate virtual interface.
  • The RenderView handles creation of the Pepper plugin in RenderView::createPlugin. RenderView has as a member a helper class PepperPluginDelegateImpl which implements the webkit::ppapi::PluginDelegate interface. This implementation is supplied to a plugin when it is created.

Debugging a plugin

Trusted plugins are loaded directly into the renderer sub-process, rather than a separate plugin process. You can use the standard renderer debugging techniques, including single process mode, for debugging the plugin.
Plugins also run in the renderer sandbox. You will find your plugin code is constrained to the same requirements and limitations as other code in the renderer (can't read and write files or directly access devices).

Running the tests

The tests in ppapi/tests are run as part of the Chrome browser_tests. The source code is in chrome/test/ppapi and you can see in that file there are separate GTest tests for each PPAPI test file. To just run this test, you can use:
browser_tests --gtest_filter='PPAPITest.*'
Or to run tests out of process:

browser_tests --gtest_filter='OutOfProcessPPAPITest.*'

You can also run the tests manually in Chrome. You first need to build the test plugin, which is the ppapi_tests project, and build Chrome (PPAPI doesn't work in test shell). When running Chrome, enable the PPAPI testing interface (it's off by default to prevent production plugins from abusing this API) and register the test plugin as handling the application/x-ppapi-tests MIME type:
chrome --register-pepper-plugins='C:codesrcchromeDebugppapi_tests.dll#PPAPI Tests##1.2.3;application/x-ppapi-tests' --enable-pepper-testing
The library name is platform-specific. On Linux, use libppapi_tests.so in the output directory. On Mac, use ppapi_tests.plugin. Once Chrome is running, just load the test_case.htmlfile in the browser. Set the 'query' part of the URL to be the name of the test you want to run, for example to run the ImageData tests, load:
file:///C:/code/src/ppapi/tests/test_case.html?ImageData
You will see a log of the test cases in the gray square. If the plugin doesn't load, you will see an error message above the gray square indicating that the plugin could not be found. This means that the library name is incorrect or it failed to load for some reason.

Running HTTP tests manually

Some tests like the URLLoader test require that it be run over HTTP. The Chrome browser tests are configured to automatically do this. But for debugging purposes you may want to do this manually. From your src directory on Linux, do:
export PYTHONPATH=third_party/pyftpdlib/src:third_party/tlslite:third_party/pywebsocket/src
python net/tools/testserver/testserver.py --port=1337 --data-dir=ppapi/tests


set PYTHONPATH=third_partypyftpdlibsrc;third_partytlslite;third_partypywebsocketsrc
python nettoolstestservertestserver.py --port=1337 --data-dir=ppapi/tests
Then you should be able to load http://127.0.0.1:1337/files/test_case.html in your browser.

Running NaCl tests manually

The NaCl tests also must be run over HTTP, but they are loaded from the build output directory instead of ppapi/tests. So to start the test server for NaCl tests on Linux for a Debug build, do:

export PYTHONPATH=third_party/pyftpdlib/src:third_party/tlslite:third_party/pywebsocket/src
python net/tools/testserver/testserver.py --port=1337 --data-dir=out/Debug
and on Windows, use:

set PYTHONPATH=third_partypyftpdlibsrc;third_partytlslite;third_partypywebsocketsrc
python nettoolstestservertestserver.py --port=1337 --data-dir=out/Debug

The command-line for running NaCl tests is different; you don't need to load the test plugin, but you do need to enable NaCl:

You must append '&mode=nacl_glibc' or '&mode=nacl_newlib' to the URL. E.g.: load http://127.0.0.1:1337/files/test_case.html?testcase=URLLoader&mode=nacl_glibc in your browser.

The Internet is Serious Business!

Home > Computers, Technology, and Internet > How to Continue Using Flash Player in the Web Browser

How to Continue Using Flash Player in the Web Browser

Adobe Flash was discontinued on 31 December 2020, and Adobe has also inserted a time bomb, set for 12 January 2021, into the final versions of Flash Player; if you have installed on your computer one of the versions of Flash Player with the time bomb, you will find that, after 12 January 2021, all Flash content will refuse to play in your Web browser.

When I first learned of the presence of the time bomb, I readily admit that I was very outraged over the fact that Adobe had deliberately chosen to render unusable freeware that had been legally downloaded and installed on people's computers, rather than simply declaring the thing end-of-life (EOL), ceasing to offer further updates and support, and encouraging users to voluntarily uninstall it from their systems, which is still reasonable. Immediately I began looking for a way to avoid this absurd time bomb, and to rightfully continue using Flash Player as I always have; fortunately I happened upon the necessary information pretty soon afterwards, but it was scattered, not always well-written, sometimes ambiguous, and a few times contradictory and/or inaccurate. Nevertheless I followed the instructions and tried the methods, finding success, but only after some trial and error.

Besides this, many Web browser vendors have announced that, after the EOL date of 31 December 2020, they will drop support for the Flash Player plug-in, so that even if the time bomb (which Adobe planted in the plug-in) is circumvented, Flash content might still not play in your Web browser. Alas, it would seem that the enemies of Flash are numerous, and they have conspired to kill our beloved friend.

This how-to guide was written primarily out of a strong motivation to defy the enemies of Flash, including even (it now seems) Adobe, after I discovered that the latter had put the time bomb in Flash Player, which struck me (and many others) as incredibly unreasonable, unnecessary, authoritarian, callous, and maybe even immoral. My goal in writing it was to collect in one place as much information on the subject as possible, which I fear would otherwise have remained scattered; I have invested much time and effort into it, and have endeavored to make it as complete as time and resources will allow, while also keeping it readable. It is my hope that through the utility of this guide, more people across the world will be able to avoid the time bomb, download a Flash-supported version of their favorite browser, and thus continue to use Flash into the foreseeable future, and I will have therefore contributed my part in prolonging Flash's life.

Firstly, you should know that this guide is specifically for those who wish to continue viewing Flash content in the Web browser, which involves the use of the Flash Player plug-in for Web browsers as well as a browser that still supports Flash. Only the Flash Player plug-in for Web browsers is affected by the time bomb; the Adobe Flash Player projector, which is a standalone Flash Player (not a browser plug-in), is not subject to the time bomb in any of its versions, nor is it dependent on a Web browser. If you don't care about viewing Flash content in your Web browser after 12 January 2021 and only want a quick and easy way to continue viewing Flash content after that date, then download the Flash Player projector, which runs as a standalone executable outside the Web browser. The drawback to this method is that either all Flashes must be saved locally to your machine in order to be played, or the SWF file's URL must be entered manually, which is troublesome (it must be found in the Web page's source code) and not always a perfect replacement (e.g., some Web pages are designed to viewed with both Flash and non-Flash content at the same time, which the projector cannot do—it can only open SWF files).

If the standalone Flash Player projector is not sufficient for your needs, and you (like me and many others) still want the ability to view Flash content in your browser, then the following how-to guide will, I hope, be of some use to you. It is split into two parts, the first concerning the methods to employ to avoid the time bomb in Flash Player, and the second concerning which versions of which Web browsers still support the Flash Player plug-in, and which do not; both parts must be followed in order to ensure that Flashes can still be viewed in whatever browser you use.

Note that I am a life-long user of Microsoft Windows, and consequently the following is written with a strong emphasis on that platform. Attention has also been given to Mac and Linux, and as much information as possible has been provided, but I have not personally tested and verified any of the following procedures on those two platforms, unlike for Windows.

Part One: Avoiding the Flash Player Time Bomb

I must emphasize that you should use one and only one of the following three methods: attempting to combine them together is either impossible or a waste of time. I can also report from personal experience that combining method 3 with either of the other two actually results in all of its disadvantages overriding any benefits offered by the others. Read over all three, decide which is best for your needs, and then perform only that one.

Method 1: Using an Old Version of Flash Player

This is the most obvious and straightforward method: simply download and install an older version of the Flash Player plug-in that does not have the time bomb in the first place. I have personally verified that the last version of Flash Player without the time bomb is version 32.0.0.371; I can confirm that the time bomb first appears in the subsequent version 32.0.0.387. All versions prior to 32.0.0.371 should not have it, either, but here I assume that you want to use the most recent pre–time bomb version. Adobe has, very annoyingly, removed from their Web site all download links for older versions of Flash Player, but fortunately there is a comprehensive archive of the various Flash Player 32.0.0.371 installers. The steps are as follows:

Pepper Flash Player Plugin

  1. Download the correct installer/archive for your OS and Web browser combination. I assume you are competent enough to know which installer/archive to download; if not, see Appendix A.
  2. Check which version of the Flash Player plug-in you have installed.
    • If you have an older version, simply install version 32.0.0.371 over it.
    • If you have a newer version, first uninstall the newer version, and then install version 32.0.0.371. On Windows, in order to enable installation of older versions of the Flash Player, you will also have to delete one or two keys in the registry:
      • For 32-bit versions of Windows, the sole key to delete is HKEY_LOCAL_MACHINESOFTWAREMacromediaFlashPlayerSafeVersions.
      • For 64-bit versions of Windows, the two keys to delete are HKEY_LOCAL_MACHINESOFTWAREMacromediaFlashPlayerSafeVersions and HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMacromediaFlashPlayerSafeVersions.
      Technically, you need not delete the entire SafeVersions key, but only the 32.0 value within it (if you're installing version 32.0.0.371 of the Flash Player, that is).
  3. If you are presented at the completion of the installation with a dialog box asking you to set Flash Player's update preferences, select the option Never check for updates (not recommended); this will both prevent unwanted automatic updates to a newer version of Flash Player that has the time bomb, as well as suppress unnecessary update prompts from appearing.
  4. To be thorough, I recommend that you restart your browser after performing these steps.

This is generally the easiest and quickest of the three methods, with its only downside being that you are not using the latest version of Adobe Flash Player (namely, version 32.0.0.465), but rather an older version. The difference, however, is only a span of seven months (version 32.0.0.371 was released in May 2020, and version 32.0.0.465 in December 2020), and I highly doubt that the older one is lacking in many features which the newer one possesses. If you are willing to put up with this, then I recommend that you select this method.

Method 2: Defusing the Time Bomb

This is more involved than the previous method, and requires the use of a hex editor. It entails the modification of the Flash Player plug-in file to manually remove the time bomb therein implanted. As the time bomb exists only in version 32.0.0.387 or later of Flash Player, this technique can only be applied to those versions.

The steps for Windows are as follows:

  1. Navigate to the Flash Player plug-in install directory/directories.
    • For 32-bit versions of Windows, the directory is %windir%System32MacromedFlash, where %windir% is the Windows directory (typically C:Windows, but your particular case might be different).
    • For 64-bit versions of Windows, there are two directories: %windir%System32MacromedFlash and %windir%SysWOW64MacromedFlash. You should take care to edit the required file(s) in both directories.
    • For the Google Chrome browser specifically, the directory is %LOCALAPPDATA%GoogleChromeUser DataPepperFlash32.0.0.###, where ### is a number between 387 and 465; if it is smaller than 387, then you have installed an older version of Google Chrome that is bundled with an older version of the Flash Player without the time bomb, and must install a newer version of Chrome before proceeding. (Unconfirmed; I don't know exactly how Chrome handles the Flash Player plug-in.)
    • For the new Chromium-based Microsoft Edge specifically, the directory is %LOCALAPPDATA%MicrosoftEdgeUser DataPepperFlash32.0.0.###, where ### is a number between 387 and 465; if it is smaller than 387, then you have installed an older version of Edge that is bundled with an older version of the Flash Player without the time bomb, and must install a newer version of Edge before proceeding. (Unconfirmed.)
  2. You will have to modify between one to seven files, depending upon your system's architecture (32-bit vs. 64-bit) and which variant(s) of the Flash Player plug-in you have installed:
    • Flash32_32_0_0_###.ocx in Windows XP/Vista/7 or Flash.ocx in Windows 8/8.1/10
    • Flash64_32_0_0_###.ocx in Windows XP/Vista/7 or Flash.ocx in Windows 8/8.1/10
    • NPSWF32_32_0_0_###.dll
    • NPSWF64_32_0_0_###.dll
    • pepflashplayer32_32_0_0_###.dll
    • pepflashplayer64_32_0_0_###.dll
    • pepflashplayer.dll (Google Chrome and Chromium-based Microsoft Edge directories only)
    The ### should be a number between 387 and 465; if it is smaller than 387, then you have installed an older version of the Flash Player without the time bomb, and must install version 32.0.0.387 or later before proceeding. In Windows 8/8.1/10, Google Chrome, and Microsoft Edge, you can check which version of Flash Player you have installed by right-clicking the Flash.ocx or pepflashplayer.dll file, selecting Properties, and then opening the Details tab.
  3. The DLL files listed above can be modified if you run your hex editor (I personally use HxD) with administrator privileges. The OCX files are write-protected and hence trickier to edit; in my experience, they can be effectively changed only in a roundabout manner. The quickest method for accomplishing this of which I am aware is given here:
    1. Change the extension of the OCX file to BAK (for example, Flash32_32_0_0_###.ocx would be renamed to Flash32_32_0_0_###.bak).
    2. Start the hex editor with administrator privileges.
    3. Open the BAK file in the hex editor, then immediately save it as a copy in the same directory with the same name, but with the OCX extension.
    4. Right-click the BAK file, select Properties, open the Security tab, click the Advanced button at the bottom, click Change Permissions... in the new window that opens, select the entry which denies everyone write attributes, and then click Remove. Click Apply, then close all the windows you opened during this step.
    5. Delete the BAK file.
    The copy of the original OCX file should now exist in the directory.
  4. Open each file in the hex editor and search for the following hex sequence:
    00 00 40 46 3E 6F 77 42
    This is the hexadecimal representation of the timestamp 1610409600000.0 encoded as a double-precision floating point number.
  5. Replace the above sequence with the following:
    00 00 00 00 00 00 F8 7F
    This is NaN in double-precision floating point, represented in hex. It will, in effect, set the time bomb date to infinity.
  6. To be thorough, I recommend that you restart your browser after performing these steps.

The steps for Mac and Linux are given below. Note: This is only a provisional walkthrough for these two platforms. I am a Windows user, and you should know that the following has not been tested and verified by me; what is offered here has instead been gathered mostly from the official Adobe Flash Player 32 administration guide and condensed in the interest of clarity. The general procedure is very similar to the Windows case, though the instructions here are quite sparse, and I am unable to round it out with further details peculiar to these two platforms. If you encounter problems, you will have to do research on your own—I cannot help you here. (Any information from Mac and Linux users regarding this method as applied to those platforms would be very much appreciated.)

  1. Navigate to the Flash Player plug-in install directory/directories.
    • For Mac, the directory is /Library/Internet Plug-Ins and/or /Library/Internet Plug-Ins/PepperFlashPlayer.
    • For Linux, according to the Flash Player administration guide: The install location is dependent upon the browser, Linux distro, and distro version.
  2. You will have to modify between one to two files, depending upon which variant(s) of the Flash Player plug-in you have installed:
    • For Mac, Flash Player.plugin and/or PepperFlashPlayer.plugin.
    • For Linux, libflashplayer.so and/or libpepflashplayer.so.
  3. Proceed from step 4 of the Windows guide for this method, above.

This method is assuredly more complex and difficult to execute than the first one, but it is only a one-time operation per file, with the main benefit over the previous method being that you can use the latest version (namely, version 32.0.0.465) of Flash Player. Of the three methods, this is the one I have elected to employ for my own system, and I can personally confirm that all three Windows variants of version 32.0.0.465 of Adobe Flash Player can be modified thus to erase the time bomb. For those who are willing to devote the extra time and effort, this is the method I recommend.

Method 3: Editing the mms.cfg File

This is at once the most cumbersome and least effective of the three methods, and I generally advise against its use, especially when the others are available; it is only included here for the sake of completeness, to be used perhaps as a last resort for those who cannot avail themselves of the other two.

The mms.cfg file is a configuration file for Adobe Flash Player that allows you, among other things, to set up a whitelist of domains and URLs for Flash content. It apparently overrides the time bomb with its own behavior: Flash content hosted on any site correctly included in the whitelist will not be blocked by the time bomb from running. I have myself confirmed that this method works for both Flash Player version 32.0.0.371 (the last version without the time bomb) and version 32.0.0.465 (which is the most recent version, and has the time bomb), and it probably works for all versions of Flash Player 32, but I have not personally verified this. The steps are as follows:

  1. Navigate to the directory/directories containing the mms.cfg file.
    • For 32-bit versions of Windows, the directory is %windir%System32MacromedFlash, where %windir% is the Windows directory (typically C:Windows, but your particular case might be different).
    • For 64-bit versions of Windows, the directory is %windir%SysWOW64MacromedFlash.
    • For Mac, the directory is /Library/Application Support/Macromedia.
    • For Linux distributions, the directory is /etc/adobe/.
    • For the following Chromium-based browsers, the directory is specific to the browser, and is given below. The string <Profile> would typically be Default, but it may be different in your case if you've created more than one browser profile. (Note that I don't use any of these browsers, and hence know very little of this feature.) If the System directory does not exist, then create it yourself.
      • For Google Chrome specifically, the directory again varies by operating system:
        • For Windows, it is %LOCALAPPDATA%GoogleChromeUser Data<Profile>Pepper DataShockwave FlashSystem.
        • For Mac, it is /Users/<Username>/Library/Application Support/Google/Chrome/<Profile>/Pepper Data/Shockwave Flash/System.
        • For Linux, it is ~/.config/google-chrome/<Profile>/Pepper Data/Shockwave Flash/System.
      • For the new Chromium-based Microsoft Edge specifically, the directory is %LOCALAPPDATA%MicrosoftEdgeUser Data<Profile>Pepper DataShockwave FlashSystem.
      • For Brave specifically, the directory is %LOCALAPPDATA%BraveSoftwareBrave-BrowserUser Data<Profile>Pepper DataShockwave FlashSystem.
      • For Iridium specifically, the directory is %LOCALAPPDATA%IridiumUser Data<Profile>Pepper DataShockwave FlashSystem.
      • For ungoogled-chromium specifically, the directory is %LOCALAPPDATA%ChromiumUser Data<Profile>Pepper DataShockwave FlashSystem.
      • For Vivaldi specifically, the directory is %LOCALAPPDATA%VivaldiUser Data<Profile>Pepper DataShockwave FlashSystem.
  2. Here I strongly urge you to download the mms.cfg file which I have undertaken the trouble of modifying myself. I have already included in it a good number of well-known Web sites hosting Flash content, thereby providing you with a starting point for your own additions; you need only place it in the directory/directories to which you navigated in the previous step, overwriting the existing mms.cfg file if necessary. If you prefer, however, to do everything yourself, then I refer you to the official Adobe administration guide for Flash Player 32, in particular the Administration chapter, which concerns the editing of the mms.cfg file and contains a full list of settings; otherwise, if you have downloaded my edited mms.cfg file, then proceed now to the next step.
  3. Open the mms.cfg file in a text editor.
  4. For each site you wish to include in the whitelist, add the following two lines:
    • WhitelistUrlPattern=*://*.<SLD>.<TLD>
    • WhitelistUrlPattern=*://<SLD>.<TLD>
    where <TLD> is the top-level domain (e.g., .com, .org, .net, .edu), and <SLD> is the second-level domain (i.e., the domain that is directly below the TLD). For the domain example.com, com is the TLD, example is the SLD, and it would be included in the whitelist in the following manner:
    • WhitelistUrlPattern=*://*.example.com
    • WhitelistUrlPattern=*://example.com
    The difference between these two commands is a subtle one, and in the interest of brevity an explanation has here been omitted. For most sites, technically you need only add one or the other to mms.cfg in order to permit its Flash content to run in your browser, but putting both doesn't hurt, and, in practice, is quicker than determining which of the two is strictly necessary; for a few sites, in fact, it might be the case that both are required.
  5. To be thorough, I recommend that you restart your browser after performing these steps.

Whereas the first method avoids the time bomb, and the second directly removes it, this third technique merely suppresses its effects on a site-by-site basis. Adobe has, very annoyingly, explicitly prohibited the commands WhitelistUrlPattern=*:* (which would instantly whitelist everything), WhitelistUrlPattern=http:*, and WhitelistUrlPattern=https:* (which would whitelist every Web site) for being overly general; they have also prohibited specifying only a TLD, i.e., commands of the form WhitelistUrlPattern=*://*.<TLD>, the allowance of which would also have greatly simplified things. Each domain must therefore be individually added to the whitelist; this method is not a one-time fix like the other two, nor anywhere nearly as elegant as method 2. In some cases it can be somewhat troublesome, as some Web sites might not host their SWF files on their obvious, surface domains, but deliver them through an entirely different one: the Web pages for Newgrounds, for example, are located at the newgrounds.com domain, but the actual SWF files presented on those pages are hosted on the obscure ungrounded.net; hence the more intuitive addition of newgrounds.com to the whitelist does nothing, as it is the ungrounded.net domain on which the SWF files reside, but you would not know to do this unless, for example, you inspected the source code of the page.

There also exists a strange bug, noted by others and also personally observed by me, that any SWF file with a left or right bracket character in its name will refuse to play under this method. I know of no solution to this besides downloading the SWF file and then renaming it to remove the bracket characters, but if you have been forced in this instance to keep a local copy of the file, then why bother at all with the whitelist, when you could simply view it using the standalone Flash Player projector I mentioned at the beginning of this guide?

Thus the only real advantages of this method over the two others are that you can use the latest version of the Flash Player plug-in (namely, version 32.0.0.465—I have personally verified this), unlike in method 1, and that it is simpler to perform than method 2, but its drawbacks are numerous, and again I advise against its use when the previous two methods are readily available.

Part Two: Selecting a Web Browser That Still Supports Flash Player

Adobe Flash Player is integrated with the various Web browsers as either an ActiveX control, a Netscape Plugin API (NPAPI) plug-in, or a Pepper Plugin API (PPAPI) plug-in. The difference is an important one: each browser supports only one of the three, and installing one type of the Flash Player plug-in while using a browser that supports another will not work.

Below I have listed some Web browsers, both major and minor, noting which of the three plug-in types they support and providing any further information of interest.

Basilisk (NPAPI)

I have confirmed that version 2021.03.17 supports Flash.

Brave (PPAPI)

I have tested and confirmed that version 1.18.78 64-bit supports Flash Player, with the subsequent version 1.19.86 being the first version that does not. The various installers and archives for version 1.18.78 can be downloaded from the official release page on GitHub; Windows users should also take care to avoid any of the four files BraveBrowserSetup.exe, BraveBrowserSetup32.exe, BraveBrowserSilentSetup.exe, and BraveBrowserSilentSetup32.exe, as these are online installers that will download and install the most recent version of the browser, rather than version 1.18.78.

In addition, I can report from personal experience that version 1.18.78 will attempt to automatically update to a newer version. There does not seem to be an option to disable this feature within the browser itself, but fortunately there do exist methods to disable automatic updates in Brave, and I can confirm that at least one of them works.

Edge (Chromium-based; PPAPI)

Note that I am here referring specifically to the new version of Edge, which is based on Chromium, not Microsoft Edge Legacy, which is based on the EdgeHTML engine. I have verified that version 87.0.664.75 supports Flash; Microsoft has stated that version 88.0.705.18 will remove support for it. The offline installers for version 87.0.664.75 are available for download at the official Microsoft Web site; once installed, you will also want to disable the browser's automatic updates.

Edge users should also be aware that the browser includes an embedded Flash Player, which seems to be updated automatically as the browser is updated; the browser does not rely on the independently installed version of the Flash Player plug-in. Although I have tested and confirmed that methods 2 and 3 work in Edge, I highly doubt that method 1 will work with the browser, as its complete management of its built-in Flash Player precludes you from installing whichever version of it you please. If you wish to perform method 1 with the Chromium-based Edge, so far the only advice I can offer to you is to install an old version of the browser that includes an older version (namely, version 32.0.0.371 or earlier) of the Flash Player plug-in without the time bomb. (Unverified; there may be a way to do it without installing an old version of Edge, but currently I know not of any procedure to accomplish this. My initial investigation of version 87.0.664.75 of Edge installed from the offline installer seems to suggest that this particular version does not come with its own included Flash Player plug-in, but rather relies on the independently installed PPAPI variant of the plug-in.)

Firefox (NPAPI)

I can confirm that version 84.0.1 64-bit still supports the Flash Player plug-in. Mozilla has announced that version 84 will be the final version to support Flash, so if you wish to continue viewing Flash content in Firefox, don't upgrade to version 85 or newer. There is also a variant of Firefox, Firefox Extended Support Release (ESR), which apparently promises longer support for the Flash Player plug-in—you might want to give it a try.

If you encounter strange freezing problems while playing Flashes in Firefox, then try disabling hardware acceleration in the browser; this might fix the issue for you, as it did for me.

Google Chrome (PPAPI)

I can confirm that version 87.0.4280.88 64-bit supports Flash Player; version 88 is the first to remove support for it. Google has made it unnecessarily difficult for users to obtain older versions of Chrome; after much searching, I have managed to locate a download page on FileHippo for the 32-bit Windows offline installer and another download page on Filepuma.com for the 64-bit Windows offline installer, both of which are for version 87.0.4280.88, and both of which I have personally downloaded, tested, and verified. You need also disable the browser's forced automatic updates, which is far more laborious than it should be—for this, see the relevant walkthrough on the site AskVG, and also this helpful post on the site Super User.

Chrome users should be aware that their browser includes an embedded Flash Player, which seems to be updated automatically as the browser is updated; the browser does not rely on the independently installed version of the Flash Player plug-in. Although I have tested and confirmed that methods 2 and 3 work in Chrome, I highly doubt that method 1 will work with the browser, as Chrome's complete management of its built-in Flash Player precludes you from installing whichever version of it you please. If you wish to perform method 1 with Chrome, so far the only advice I can offer to you is to install an old version of the browser that includes an older version (namely, version 32.0.0.371 or earlier) of the Flash Player plug-in without the time bomb. (Unverified; there may be a way to do it without installing an old version of Chrome, but currently I know not of any procedure to accomplish this. My initial investigation of both the 32-bit and 64-bit variants of version 87.0.4280.88 of Google Chrome installed from the two aforementioned offline installers seems to suggest that this particular version does not come with its own included Flash Player plug-in, but rather relies on the independently installed PPAPI variant of the plug-in.)

Pepper Flash Player Windows

Internet Explorer (ActiveX)

The One True Browser should be your main Web browser anyway, the very existence of which renders every other browser unnecessary; and I wonder whether the other subsections here given for the other browsers are not also redundant, that I waste my time writing them, and, worst of all, that in so doing I have thereby placed myself contrary to divine authority: for to give any such space to the others is to imply at once that they are viable alternatives to the One, which has been hand-crafted by our Lord and Savior, blessed be His name, whose Heavenly Mandate knows no bounds; whose Wisdom is absolute; whose Spiritual Influence holds sway for ever amongst all kingdoms and peoples; and whose Rightful Dominion extends manifestly to all Computers, Operating Systems, the Internet, Software, Technology, &c., &c., &c.: it has been gifted, through His Boundless Generosity, to all Mankind, though we are but a wretched mass of sinners—lo, the Mac users and the FOSS'ers, the Chrome and Firefox heathens, with their unholy ways, do ever bring us shame and disgrace. I humbly ask forgiveness, O Lord, that I should not suffer your Divine Retribution, but receive in a small part of your Infinite Graciousness: many are the men on this Earth to-day who have strayed from the Holy Path of the One True Browser: they have rejected it wholeheartedly, and with it, all Virtue, Righteousness, and Reason; they speak ill of it, for they know not of its Everlasting Sacredness; they substitute others in its place, and suppose that they can take the ordinary for the divine; and they refuse to reform their ways in the face of innumerable exhortations. For these reasons, O Lord, I beg permission that I may for the time being offer earthly advice to them for other browsers, not because such lowly handicrafts should ever usurp the rightful place of Your Sublime Creation, but merely from my heart's wish to help my fellow men, even the poor sinners, in a time of need. Amen.

I am very glad to report that Internet Explorer 11, which is the most recent version, supports the Flash Player plug-in without any issue. As Internet Explorer 11 is the final version of the browser, and does not receive any updates other than security fixes, you need not worry about the removal of support for the plug-in.

Iridium (PPAPI)

I have verified that version 2020.11 64-bit supports Flash.

Opera (PPAPI)

I have verified that version 73.0.3856.344 64-bit still supports Flash; the following version 74.0.3911.107 is the first to remove this support. The various installers and archives for version 73.0.3856.344 have been provided for download at an official Opera directory; after installing, you will also want to disable the browser's forced automatic updates.

In versions of Opera that support Flash Player, even after enabling the plug-in, you might still encounter a screen informing you that Adobe Flash Player is out of date (which is plainly false, for Adobe Flash is timeless) covering whatever Flash you're trying to view; in this case you need only right-click the screen, and, in the menu that appears, select the command Run this plug-in.

Strangely, even though Opera relies on an independently installed Flash Player plug-in and hence its mms.cfg directory should be one of those listed in step 1 of method 3, I have observed that, at least on Windows, Opera seems to ignore the settings in the mms.cfg file in that directory. I then suspected that the browser might instead have its own directory for mms.cfg, located somewhere in %LOCALAPPDATA% (similar to the other Chromium-based browsers here listed, as Opera is also based on Chromium), but I could not find it. The reason for this behavior eludes me, and consequently I have not yet been able successfully to perform method 3 with Opera. (Assistance from an Opera expert on the matter would be much appreciated.)

Pale Moon (NPAPI)

I can confirm that version 29.1.0 64-bit supports the Flash Player. I especially commend Pale Moon's lead developer, who stated clearly in a forum post that support for the Flash Player plug-in will not be removed from the browser in the foreseeable future, in great contrast to many of the other browsers listed here; it is therefore possible to continue viewing Flashes in Pale Moon while also keeping the browser regularly updated.

Safari (NPAPI)

Safari 13 is the last version to still support the Flash Player plug-in; Safari 14 removes support for it. (Completely untested; can any Mac user confirm this?)

Slimjet

Version 29.0.2.0 64-bit of Slimjet has been verified to support version 32.0.0.371 of the Flash Player plug-in, and hence it is possible to perform method 1 with this browser. (Credit goes to Danny of ChatArcade for reporting this to me.)

ungoogled-chromium (PPAPI)

I have tested and confirmed that version 87.0.4280.141 64-bit supports the Flash Player plug-in; version 88 is the first to remove this support. This browser, apparently, is officially distributed only as source code; for those who are unwilling or unable to compile the thing from source, there also exists a repository of unofficial binaries for the browser.

Vivaldi (PPAPI)

I have verified that version 3.5.2115.87 64-bit supports Flash Player, with the subsequent version 3.6.2165.34 being the first that does not; old versions of the browser can be downloaded from the official Vivaldi Web site. In addition, you may need to click the small padlock icon (for HTTPS sites) or the Not Secure icon (for HTTP sites) immediately to the left of the address bar in order to open the menu that allows you to enable the Flash Player plug-in. If, after doing this, Flashes still do not play in the browser, then try right-clicking the Flash content and, in the menu that appears, selecting the command Run this plugin.

Waterfox (NPAPI)

There are two variants of this browser currently existing, the one being Waterfox Third Generation, and the other Waterfox Classic. For the sake of thoroughness I have tested both, and can report that version G3.0.2 64-bit of Waterfox Third Generation and version 2021.01.1 64-bit of Waterfox Classic both support the Flash Player plug-in.

Special Note for Windows 8.1 and Windows 10 Users

Users of Windows 8.1 and Windows 10 should take care to avoid the dangerous KB4577586 update, entitled Update for Removal of Adobe Flash Player, which removes the Flash Player plug-in from those systems. As of mid-January 2021, the update has not yet appeared on Windows Update nor WSUS; Microsoft has stated that it will be made optional on Windows Update and WSUS in early 2021 and will be made recommended a few months later, so be alert, and ensure that you do not install it by accident—it cannot be independently uninstalled afterwards. If you find that you have somehow installed the update and wish to remove it, your only recourse in that case, again according to Microsoft, is to roll back your machine to a system restore point saved before you applied the update, or, even more troublesome, to reinstall Windows entirely. Even worse, according to the second link, in the summer of 2021 this terrible update will be included as part of a cumulative update/monthly rollup for Windows 8.1 and Windows 10, rendering it ever the more difficult to avoid.

Note that, due to the difficulty of reversing this update, I have not yet tested it on my own machine. Fortunately, however, its effects seem rather limited: it only removes Flash support for Internet Explorer and Microsoft Edge Legacy on Windows 8.1 and Windows 10; according to reports by some who have already applied the update to their systems, it does not remove the embedded Flash Player plug-in included in the new Chromium-based Edge, nor does it delete any independently installed (i.e., installed with the official Adobe installer) versions of the plug-in which other browsers might rely on. Hence you need only worry about this update if you use Internet Explorer or Microsoft Edge Legacy on Windows 8.1 and Windows 10.

Special Note for macOS Big Sur Users

The macOS Big Sur, released 12 November 2020, removes support for Adobe Flash Player. As I don't own a Mac, I am unable to verify whether this removal is limited strictly to Safari 14 (which is included with that OS), or if Apple has somehow blocked Flash Player from running at all—that is, in any browser you use on the OS, even if the individual browser itself still supports Flash. Any information from Mac users on the matter is greatly desired.

Acknowledgments

I thank the anons of 4chan's /f/ for first exposing me to the core of the information found in this guide, which is what first energized me to write it. I also thank the fellow over at TehSausage.com, whose original and concise instructions for defusing the time bomb I have here only expanded upon in method 2 for the sake of those less computer-savvy than him, as well as for the Mac and Linux users. The official Adobe administration guide for Flash Player 32 was also a helpful reference, and I urge you to look through it if you've encountered any issues.

This guide is ever incomplete; I certainly do not claim that every possible combination of operating system and browser, which are overwhelmingly numerous, has been adequately covered. I hope that you have derived at least some use from it, but there are sure to be many special cases where it is lacking. If you have found errors in what I have here written, or have encountered issues while following the instructions in this guide, then I strongly urge you to contact me—I welcome all first-hand information, results, and reports, and am always seeking to improve the guide. I will take care properly to credit anyone who submits corrections, suggestions, and improvements that are ultimately integrated into the guide.

Appendix A: Table of Files for Flash Player 32.0.0.371

I realize that the list of files to which I linked in method 1 is perhaps confusing for some: no descriptions have been provided, nor are the filenames themselves very helpful. The following table has been included in an attempt to allay that confusion, providing a concise description and further notes for those files. There are 30 files listed in total, but here I include only the top 17, for those are the release versions for end users and are therefore likely what you're looking for; the function of the uninstall_flashplayer32_0r0_371_mac.dmg and uninstall_flashplayer32_0r0_371_win.exe files should be plainly obvious by their names, and the remaining 11 files at the bottom are debugger versions of Flash Player, which have some extra functionality that might be useful to Flash developers.

For Windows users, I recommend that, for whichever variant(s) of Flash Player you need (i.e., whether ActiveX, NPAPI, and/or PPAPI), you download the EXE rather than the MSI. There is very little effective difference between the two, and running either will install the corresponding variant of Flash Player, but a small benefit of the EXE which I have observed is that, at the end the installation, it will present you with a dialog box asking you to set Flash Player's update preferences, whereas the MSI will not.

For Mac users, apparently the PKG archive also does not present you with any dialog box asking you to set Flash Player's update preferences, whereas the non-PKG archive does.

FileDescriptionNotes
flashplayer32_0r0_371_linux.i386.tar.gz32-bit Linux archive (NPAPI)For use with Basilisk, Firefox, Pale Moon, Safari, Waterfox, and other browsers that support NPAPI.
flashplayer32_0r0_371_linux.x86_64.tar.gz64-bit Linux archive (NPAPI)For use with Basilisk, Firefox, Pale Moon, Safari, Waterfox, and other browsers that support NPAPI.
flashplayer32_0r0_371_linux_sa.x86_64.tar.gz64-bit Linux standalone Flash Player archiveThis is a standalone Flash Player projector, not the plug-in for Web browsers; there is no use in downloading it if you're trying to view Flash content in your browser.
flashplayer32_0r0_371_linuxpep.i386.tar.gz32-bit Linux archive (PPAPI)For use with Brave, Iridium, Opera, ungoogled-chromium, Vivaldi, and other browsers that support PPAPI.
flashplayer32_0r0_371_linuxpep.x86_64.tar.gz64-bit Linux archive (PPAPI)For use with Brave, Iridium, Opera, ungoogled-chromium, Vivaldi, and other browsers that support PPAPI.
flashplayer32_0r0_371_mac.dmgMac archive (NPAPI)For use with Basilisk, Firefox, Pale Moon, Safari, Waterfox, and other browsers that support NPAPI.
flashplayer32_0r0_371_mac_pkg.dmgMac PKG archive (NPAPI)For use with Basilisk, Firefox, Pale Moon, Safari, Waterfox, and other browsers that support NPAPI. (Does not present you with options to set Flash Player's update preferences.)
flashplayer32_0r0_371_mac_sa.dmgMac standalone Flash PlayerThis is a standalone Flash Player projector, not the plug-in for Web browsers; there is no use in downloading it if you're trying to view Flash content in your browser.
flashplayer32_0r0_371_macpep.dmgMac archive (PPAPI)For use with Brave, Iridium, Opera, ungoogled-chromium, Vivaldi, and other browsers that support PPAPI.
flashplayer32_0r0_371_macpep_pkg.dmgMac PKG archive (PPAPI)For use with Brave, Iridium, Opera, ungoogled-chromium, Vivaldi, and other browsers that support PPAPI. (Does not present you with options to set Flash Player's update preferences.)
flashplayer32_0r0_371_win.exeWindows EXE installer (NPAPI)For use with Basilisk, Firefox, Pale Moon, Safari, Waterfox, and other browsers that support NPAPI.
flashplayer32_0r0_371_win.msiWindows MSI installer (NPAPI)For use with Basilisk, Firefox, Pale Moon, Safari, Waterfox, and other browsers that support NPAPI. (For individual users, the corresponding EXE is generally better.)
flashplayer32_0r0_371_win_sa.exeWindows standalone Flash PlayerThis is a standalone Flash Player projector, not the plug-in for Web browsers; there is no use in downloading it if you're trying to view Flash content in your browser.
flashplayer32_0r0_371_winax.exeWindows EXE installer (ActiveX)For use with Internet Explorer.
flashplayer32_0r0_371_winax.msiWindows MSI installer (ActiveX)For use with Internet Explorer. (For individual users, the corresponding EXE is generally better.)
flashplayer32_0r0_371_winpep.exeWindows EXE installer (PPAPI)For use with Brave, Iridium, Opera, ungoogled-chromium, Vivaldi, and other browsers that support PPAPI.
flashplayer32_0r0_371_winpep.msiWindows MSI installer (PPAPI)For use with Brave, Iridium, Opera, ungoogled-chromium, Vivaldi, and other browsers that support PPAPI. (For individual users, the corresponding EXE is generally better.)

Appendix B: Revision History

  • Version 0.17 (21 March 2021)
    • Updated step 1 of method 3 to include the directory specific to ungoogled-chromium in which the mms.cfg file must be placed.
    • Added subsections in part two for Basilisk, Slimjet, and ungoogled-chromium.
    • Updated the subsection for Opera to mention the first version of the browser which no longer supports Flash; also added links to the official directory containing the various installers/archives for version 73.0.3856.344 of the browser, in addition to a guide which details the methods to disable its automatic updates.
    • Updated the subsection for Vivaldi to note the first version that lacks support for the Flash Player plug-in; also added a link to the official download page listing the various installers/archives for older versions of that browser.
    • Updated the Pale Moon version which I have personally verified for Flash Player support from 28.17.0 64-bit to 29.1.0 64-bit.
    • Removed an item from Appendix C.
  • Version 0.151 (15 February 2021)
    • Moved the mms.cfg file to which I linked in step 2 of method 3 from an external file host to this site's current Web host, and also slightly modified the corresponding paragraph to reflect this.
  • Version 0.15 (31 January 2021)
    • Added this Appendix B: Revision History; the hitherto sole appendix consequently was renamed to Appendix A: Table of Files for Flash Player 32.0.0.371.
    • Altered some items in the section Possible Future Additions, which was also moved from the end of the main body of the guide to the new Appendix C.
    • Updated step 1 of method 3 to include the directories specific to Brave, Iridium, and Vivaldi in which the mms.cfg file must be placed; also re-organized it slightly for improved clarity.
    • Added subsections in part two for Brave, Iridium, Vivaldi, and Waterfox.
    • Added to the subsection for the Chromium-based Edge links to the download page for version 87.0.664.75, as well as to a guide describing the various methods that can be employed to disable automatic updates in the browser.
    • Added to the subsection for Google Chrome links to download pages for version 87.0.4280.88 (Windows only, for now), in addition to guides providing techniques to disable the browser's automatic updating.
    • Updated the Opera version which I have personally verified for Flash Player support from 73.0.3856.329 64-bit to 73.0.3856.344 64-bit, and also added information regarding the use of the right-click menu command to enable Flash content in that browser.
    • Added in the subsection for Firefox a link to the Mozilla directory containing various installers/archives for version 84.0.1 of that browser.
    • Other minor additions and clarifications.
  • Version 0.1 (12 January 2021)
    • Initial publication.

Appendix C: Possible Future Additions

  • Subsections in part two concerning additional browsers: Microsoft Edge Legacy, Lunascape, K-Meleon, SeaMonkey, and Comodo IceDragon, if they support the Flash Player plug-in, are good candidates.
  • Small oddities were encountered during my testing of Flash Player on Microsoft Edge Legacy, as well as during my testing of both Google Chrome and the Chromium-based Edge installed from their respective offline installers. Further investigation is required; when completed, any peculiarities should be noted in the relevant sections.
  • For existing subsections concerning each browser in part two, a download link to the newest version of the browser that still supports Flash (if the current version no longer supports the plug-in, that is) might be provided for the convenience of the reader. Additionally, if the browser partakes in the absurdity that is forced automatic updates, then a link to a walkthrough detailing the steps necessary to disable this should also be provided.
  • Downloads might be provided to various versions of Flash Player newer than version 32.0.0.387, which is where the large collection on the Internet Archive to which I linked in method 1 ends; Adobe's own site has certainly been little to no help in this regard, as all old versions, very frustratingly, have been removed. Highest priority is the offline installers for the final version, 32.0.0.465, but optimally all versions after 32.0.0.387 would here be provided.
  • Patched versions of the OCX and DLL files mentioned in method 2 might be furnished for download to save readers the time and effort of performing the hex edit themselves, with highest priority belonging to the files for version 32.0.0.465 of Flash Player.
  • The special note for Windows 8.1 and Windows 10 users will have to be updated over the course of 2021 as the undesirable KB4577586 makes it appearance in Windows Update and WSUS. Specific instructions might be added for avoiding it as more information becomes available.
  • A troubleshooting section, if I am able to identify some common pitfalls.
  • In general, more information pertaining to the Mac and Linux platforms is needed throughout the walkthrough.

All written materials on this Web site are my own, and all are released under the Do What the Fuck You Want to Public License Version 2.

This page last modified on 25 March 2021.





Comments are closed.