You'll need to use the Enteprise Enablement features in Flash Player to enable the application to load whatever it needs.   You can read more about Enterprise Enablement in the Flash Player admin guide, here:  https://www.adobe.com/devnet/flashplayer/articles/flash_player_admin_guide.html   Because Flash Player is being used in the context of an application and not a browser, this is *much* easier to do on Windows 7.   I wrote this guide up for our enterprsie support folks the other day.  It covers the larger context and should give you everything you need to figure this out.  You'll need to look at the mms.cfg and enterprise enablement sections of the admin guide for specifics on where to put files and whatnot.   -----   Desktop Applications   In the early days of Flash Player, distribution of content on interactive CD-ROMs was common practice. This led to later practices of developers embedding Flash Player in desktop applications (typically by embedding an IE window) for more expressive User Interfaces. Flash remains popular for creating animated UI elements in specific scenarios, like HUD overlays in video games.   Ultimately, Adobe AIR (now EOL) became the supported platform for desktop application creation using Flash technology. In general, we’ve been actively discouraging developers from building applications that leverage the system Flash Player in embedded browser windows for the better part of a decade, but we try not to break existing applications.   In the context of Enterprise Enablement, depending on how Flash Player is leveraged, the application should be able to read and obey directives in mms.cfg. The challenge is around debugging, particularly on Windows 8 and higher, where the ActiveX installation path is controlled by Microsoft, and neither the latest builds or debugger variants of ActiveX Flash Player are available.   Where possible, the easiest way to debug applications that embed the ActiveX Flash Player is to do it on a Win 7 VM, with the debugger installed and configured for file logging (TraceFileOutputEnable=1 in mm.cfg). Here’s more detail on configuring the debugger: https://helpx.adobe.com/flash-player/kb/configure-debugger-version-flash-player.html   Once configured, you should be able to see the debugging messages when URL requests are blocked by EnableAllowList, just like you would in a browser. Depending on the bit-ness of the application and the version of IE that gets embedded, you may need to put mms.cfg in a different system folder than you would when targeting the browser itself (i.e. C:\Windows\System32 for 64-bit vs C:\Windows\SysWOW64 for 32-bit) folders.   In practice, what’s generally happening is that Flash Player requires valid URIs that conform to RFC 3986. In the context of desktop applications, those would most likely be local files, with the expected format of file:///c/users/foo/desktop/bar.jpg.   Instead, we’ve been seeing a variety of malformed values getting passed in. These are from a popular open-source project that uses Flash for graphical overlays in broadcast video (news chirons, etc):   *** AllowListPreview: AllowList blocks 'C:\Users\labuser\Desktop\CasparCG Server 2.0.7\CasparCG Server\Server\templates\\cg20.fth.pal'. *** (note both the wrong format and double backslashes)   *** AllowListPreview: AllowList blocks 'file:///C|/Users/labuser/Desktop/CasparCG%20Server%202.0.7/CasparCG%20Server/Server/templates//CASPARCG_FLASH_TEMPLATES_EXAMPLE_PACK_1/ADVANCEDTEMPLATE1.ft'. *** (note the old-school pipe notation for drive letters)   In these instances, there’s no way to target them with an AllowListUrlPattern directive, because they fail the URI validity check before we even get to the code that tries to match the pattern.   To work around this issue, we added the EnableInsecureAllowListLocalPathMatching directive, which effectively skips the validity checks, allowing AllowListUrlPattern=file:* to match on whatever you throw at it. If the operating system will resolve it, we’ll match it.   This opens a whole can of worms in terms of ambiguous URIs, which can lead to things like unexpected network store traversal via UNC path. Requiring RFC-conformant URIs is intended to solve those issues, but it became obvious as we got more input from the field that there was a class of legacy applications that were not passing in valid URIs.   Unfortunately, the addition of EnableInsecureAllowListLocalPathMatching landed in the December Flash Player release (32.0.0.465), which was after the last build that Microsoft shipped for Windows 8 and higher. Organizations that require this feature for the ActiveX Flash Player on Windows 8 and higher will need to license a maintained version of Flash Player from HARMAN in order to gain access to it. ... View more

Were you guys able to work around this?  I'm hoping the permission tip got you on the right path.  I got hung up trying to coax the ubuntu package manager into doing what I wanted and realized that I hadn't gotten back to it.   If you're still stuck, I'm happy to dig into it tomorrow. ... View more

Also, just in defense of the HARMAN guys, I saw a graph of sign-ups the other day, and the last few weeks are that exponential hockey-stick shape.  I'm sorry that they didn't follow up.  They were absolutely pummeled with late-breaking requests, and what they accomplished under the circumstances was pretty impressive.  We had a sense that they'd get overwhelmed during the last couple weeks as the folks that might not have been paying attention started seeing all of the "goodbye Flash" articles in the tech press.  We tried to get the word out in advance so that it wouldn't be a huge spike at the end, but human nature is human nature.  🙂   For what it's worth, the incoming volume seems to have normalized to something manageable at this point, and I expect that the response would be much different now.  Given your timeline, it sounds like you made the right choice under the circumstances. ... View more

If you want to debug the application and try to work around it, it would be really interesting to know what URLs are getting passed in.  I wrote this for some of our support engineers to help with troubleshooting similar issues.  If you want to dig into this more deeply, it should cover everything you need, and has a good rundown on the current operational contexts.   Desktop Applications   In the early days of Flash Player, distribution of content on interactive CD-ROMs was common practice. This led to later practices of developers embedding Flash Player in desktop applications (typically by embedding an IE window) for more expressive User Interfaces. Flash remains popular for creating animated UI elements in specific scenarios, like HUD overlays in video games.   Ultimately, Adobe AIR (now EOL) became the supported platform for desktop application creation using Flash technology. In general, we’ve been actively discouraging developers from building applications that leverage the system Flash Player in embedded browser windows for the better part of a decade, but we try not to break existing applications.   In the context of Enterprise Enablement, depending on how Flash Player is leveraged, the application should be able to read and obey directives in mms.cfg. The challenge is around debugging, particularly on Windows 8 and higher, where the ActiveX installation path is controlled by Microsoft, and neither the latest builds or debugger variants of ActiveX Flash Player are available.   Where possible, the easiest way to debug applications that embed the ActiveX Flash Player is to do it on a Win 7 VM, with the debugger installed and configured for file logging (TraceFileOutputEnable=1 in mm.cfg).   Here’s more detail on configuring the debugger: https://helpx.adobe.com/flash-player/kb/configure-debugger-version-flash-player.html   Once configured, you should be able to see the debugging messages when URL requests are blocked by EnableAllowList, just like you would in a browser. Depending on the bit-ness of the application and the version of IE that gets embedded, you may need to put mms.cfg in a different system folder than you would when targeting the browser itself (i.e. C:\Windows\System32 for 64-bit vs C:\Windows\SysWOW64 for 32-bit) folders.   In practice, what’s generally happening is that Flash Player requires valid URIs that conform to RFC 3986. In the context of desktop applications, those would most likely be local files, with the expected format of file:///c/users/foo/desktop/bar.jpg.   Instead, we’ve been seeing a variety of malformed values getting passed in. These are from a popular open-source project that uses Flash for graphical overlays in broadcast video (news chirons, etc): *** AllowListPreview: AllowList blocks 'C:\Users\labuser\Desktop\CasparCG Server 2.0.7\CasparCG Server\Server\templates\\cg20.fth.pal'. *** (note both the wrong format and double backslashes)   *** AllowListPreview: AllowList blocks 'file:///C|/Users/labuser/Desktop/CasparCG%20Server%202.0.7/CasparCG%20Server/Server/templates//CASPARCG_FLASH_TEMPLATES_EXAMPLE_PACK_1/ADVANCEDTEMPLATE1.ft'. *** (note the old-school pipe notation for drive letters)   In these instances, there’s no way to target them with an AllowListUrlPattern directive, because they fail the URI validity check before we even get to the code that tries to match the pattern.   To work around this issue, we added the EnableInsecureAllowListLocalPathMatching directive, which effectively skips the validity checks, allowing AllowListUrlPattern=file:* to match on whatever you throw at it. If the operating system will resolve it, we’ll match it.   This opens a whole can of worms in terms of ambiguous URIs, which can lead to things like unexpected network store traversal via UNC path. Requiring RFC-conformant URIs is intended to solve those issues, but it became obvious as we got more input from the field that there was a class of legacy applications that were not passing in valid URIs. Unfortunately, the addition of EnableInsecureAllowListLocalPathMatching landed in the December Flash Player release (32.0.0.465), which was after the last build that Microsoft shipped for Windows 8 and higher. Organizations that require this feature for the ActiveX Flash Player on Windows 8 and higher will need to license a maintained version of Flash Player from HARMAN in order to gain access to it. ... View more

I totally get the confusion from where you sit.  Captivate is one of hundreds of downstream products that happen to leverage some aspect of Flash technology.  There's no way that we could ever hope to track the individual implementation details for how each of those products used Flash (and multiply that over ~15 years of product versions released since the Adobe acquisition).    When we as the Flash team speak about Flash, we do so from the scope of Flash Player (and sometimes Flash Authoring/Animate) as a product.  The Captivate team would have been best position to speak about implications of Flash EOL in the context of their product, but the general strategy for those applications was to remove dependencies on Flash between 2017 and 2020 and allow people to republish old content to modern surfaces where that was feasible.  The Captivate folks might also have more informed advice about your current predicament, and I'd recommend asking over in their forum.   That the EOL behavior is affecting your Captivate .exe files says that Captivate is outputting an executable that leverages the system Flash Player. My guess is that Captivate's application wrapper does more than just render Flash.  It's probably an embedded IE window that renders both HTML and Flash.    This wasn't Flash Player or Flash Authoring generating a .exe (which is what we would be most familiar with from the purview of the Flash team), it was Captivate outputting it's own content to an exe, which also happened to include some Flash content.  Those are fundamentally different things in practice, but I totally get how that distinction is nuanced in the abstract.   Old-school versions of Flash Authoring published executables which were just a bundled copy of a SWF and a copy of the Flash Projector.  In that instance, you're not leveraging the system player -- the .exe has an independent copy of Flash baked in.    I don't know about Captivate's .exe implementation details because we're not talking about a product I work on, but my guess is that it's leveraging an embedded IE window.  On Windows 8 and higher, Microsoft will eventually publish a mandatory update that removes the ActiveX Flash Player from those systems.  This will happen around summer.  At that point, even without the Flash "timebomb", those .exe files are dead unless your customers license a copy of the ActiveX Flash Player from HARMAN (which is not cheap) to continue using after that mandatory update gets applied.   In the meantime, it's theoretically possible that you could employ an mms.cfg file that defines the required dependencies, at which point Flash should allow those assets to load.  Flash Player's "time bomb" enforces the EnableAllowList feature by default.  This minimizes the risk that users will encounter malicious content (which is a bigger issue now that those installations aren't getting regular security updates), but does make affordances for critical applications.    In your case, your options are pretty limited -- particularly on Windows 8 and higher.  Because you don't have control over the source code for the captivate output, you probably can't fix the underlying issue, and current versions of Captivate aren't going to invest in improving the ability to target a dead output format.    My educated guess is that like many applications, the code in Captivate's executable is sending over file paths to Flash that Windows will automatically resolve, but that aren't RFC 3986 compliant.  Flash requires standards-conformant URIs because more ambiguous path representations lead to all kinds of traversal attacks that are impossible to fully mitigate.  In the context of a browser plug-in, incoming paths would be automatically normalized by the browser before calling Flash.  The result is that we're getting a path that "works" until we try to match it with an AllowListUrlPattern rule, at which point it fails the validation check and is effectively untargetable.  If this was your code, I'd tell you to do that normalization before passing paths to Flash, but you're stuck.   If your Win8+ users were licensing a maintained version of Flash Player from HARMAN, they would have a version that supports the EnableInsecureAllowListLocalPathMatching flag, which allows a lot of non-conformant URIs to match the pattern AllowListUrlPattern=file:* that might otherwise be untargetable.  This might work for users on Win7 with the latest generally available Flash Player build (and the only way that you could debug it is on Win7 with the Flash Player debugger installed and configured with TraceFileOutputEnabled=1 in mm.cfg).  Working around the "time bomb" would buy you a couple months until Microsoft requires the removal of the ActiveX Flash Player on Windows 8 and higher, at which point, your executables will break unless those clients are licensing an ActiveX Flash Player from HARMAN.  (Because MSFT owned the installation path on Win8+, Adobe never published an installer for Win8+.  There's no way to reach back and get an old build.   HARMAN built an installer that will work once the Windows Update for Flash Player removal gets applied).    ... View more

For completeness, here's the consumer FAQ:  https://www.adobe.com/products/flashplayer/end-of-life.html ... View more

So just to clafiry the next steps:  Get a configuration that logs Examine the logs and take a look at what's getting sent Patch your app to send confirming URIs Recommend that your enteprise customers license the ActiveX Flash Player from HARMAN if they need the ActiveX Flash Player for more than the next couple months.   I'm super curious about the URIs that are getting sent.  There's no possibility of pushing out an update at this point that would change the behavior, but at that point, we can have an informed look at what's happening.  If there's an edge case that we didn't think of, I can at least debug it and see if there are any useful recommendations.   In terms of addressing this, you probably just want to update your application to normalize those paths to RFC 3986 compliant URIs. This is what Caspar (the software from the case study above) did. You might be able to just crib the normalization code from their Github repo. This is optimal (at least IMO), because your customers on Win8+ probably aren't on a version of Flash Player that supports EnableInsecureAllowListLocalPathMatching, and their only option to get it is to license a maintained Flash Player from HARMAN moving forward. It's much more cost-effective to just patch the application to pass in a valid URI in the first place.    At that point, you should be able to look at the logs and write matching AllowListUrlPattern directives that work. It's also worth pointing out that MSFT will be removing the ActiveX Flash Player that they distributed to Windows 8 and higher via a future mandatory Windows Update.  That package is currently optional, but the next big roll-up update (scheduled around summer) will require it.    Licensing the ActiveX Flash Player from HARMAN is ultimately going to be necessary for enterprises on Windows 8 and higher.  Adobe was never able to distribute an installer for the ActiveX Flash Player on that platform, so you can't just reach back and get and old version.  HARMAN built an installer that works on Win8+ systems, AFTER the Microsoft Update that removes their Flash distribution has been applied.   Deploying a licened version from HARMAN confers some meaningful benefits -- those builds continue to get functional and security updates.  For enterprises that need to keep Flash deployed, this is the best approach from both a security and operational perspective (they can/should still leverage the AllowList to limit their attack surface).   Without requiring users to license the HARMAN player, using confirming URIs buys you a few months to replace those Flash dependencies with something else before that mandatory MSFT patch gets deployed. ... View more

@Marcel5C83 - This thread got noisy and I'm still interested in understanding why this is failing for your application.  The thing I'm interested about in your situation is the actual log output.  Flash Player should be logging what's getting blocked.   I wrote the following guide for some of our support engineers.  Here's the section on troubleshooting desktop applications.     Desktop Applications   In the early days of Flash Player, distribution of content on interactive CD-ROMs was common practice.  This led to later practices of developers embedding Flash Player in desktop applications (typically by embedding an IE window) for more expressive User Interfaces.  Flash remains popular for creating animated UI elements in specific scenarios, like HUD overlays in video games.   Ultimately, Adobe AIR (now EOL) became the supported platform for desktop application creation using Flash technology.  In general, we’ve been actively discouraging developers from building applications that leverage the system Flash Player in embedded browser windows for the better part of a decade, but we try not to break existing applications.   In the context of Enterprise Enablement, depending on how Flash Player is leveraged, the application should be able to read and obey directives in mms.cfg.  The challenge is around debugging, particularly on Windows 8 and higher, where the ActiveX installation path is controlled by Microsoft, and neither the latest builds or debugger variants of ActiveX Flash Player are available.   Where possible, the easiest way to debug applications that embed the ActiveX Flash Player is to do it on a Win 7 VM, with the debugger installed and configured for file logging (TraceFileOutputEnable=1 in mm.cfg). Here’s more detail on configuring the debugger: https://helpx.adobe.com/flash-player/kb/configure-debugger-version-flash-player.html   Once configured, you should be able to see the debugging messages when URL requests are blocked by EnableAllowList, just like you would in a browser.  Depending on the bit-ness of the application and the version of IE that gets embedded, you may need to put mms.cfg in a different system folder than you would when targeting the browser itself (i.e. C:\Windows\System32 for 64-bit vs C:\Windows\SysWOW64 for 32-bit) folders.   In practice, what’s generally happening is that Flash Player requires valid URIs that conform to RFC 3986.  In the context of desktop applications, those would most likely be local files, with the expected format of file:///c/users/foo/desktop/bar.jpg.    Instead, we’ve been seeing a variety of malformed values getting passed in.  These are from a popular open-source project that uses Flash for graphical overlays in broadcast video (news chirons, etc): *** AllowListPreview: AllowList blocks 'C:\Users\labuser\Desktop\CasparCG Server 2.0.7\CasparCG Server\Server\templates\\cg20.fth.pal'. *** (note both the wrong format and double backslashes) *** AllowListPreview: AllowList blocks 'file:///C|/Users/labuser/Desktop/CasparCG%20Server%202.0.7/CasparCG%20Server/Server/templates//CASPARCG_FLASH_TEMPLATES_EXAMPLE_PACK_1/ADVANCEDTEMPLATE1.ft'. ***   (note the old-school pipe notation for drive letters)   In these instances, there’s no way to target them with an AllowListUrlPattern directive, because they fail the URI validity check before we even get to the code that tries to match the pattern.   To work around this issue, we added the EnableInsecureAllowListLocalPathMatching directive, which effectively skips the validity checks, allowing AllowListUrlPattern=file:* to match on whatever you throw at it.  If the operating system will resolve it, we’ll match it.  This opens a whole can of worms in terms of ambiguous URIs, which can lead to things like unexpected network store traversal via UNC path.  Requiring RFC-conformant URIs is intended to solve those issues, but it became obvious as we got more input from the field that there was a class of legacy applications that were not passing in valid URIs.    Unfortunately, the addition of EnableInsecureAllowListLocalPathMatching landed in the December Flash Player release (32.0.0.465), which was after the last build that Microsoft shipped for Windows 8 and higher.  Organizations that require this feature for the ActiveX Flash Player on Windows 8 and higher will need to license a maintained version of Flash Player from HARMAN in order to gain access to it. ... View more

Chrome 88 dropped support for the PPAPI plug-in interfaces, ending support for all browser plug-ins, including Flash.  Safari and Firefox have also dropped support for Flash Player at this point.  IE and Edge will follow suit soon.    The option you do have is to run old software.  Ideally, you'd do that safely -- build a VM that's airgapped from the Internet, etc.  Like with any technology, we're not going to stop people with sufficient skills and expertise from doing things that are dangerous.    If you want to pull all the safety features off your table saw, that's a terrible idea, but you can do it.  Your table saw manufacturer isn't going to tell you how to do that, and for the vast majority of people, it's a wildly inappropriate idea.  You know that when you disable those features, you might be walking around with a few less fingers some day, (or by removing that annoying kickback guard, you might take a 2x4 to the chest -- nobody's stopping you, but you want to have a full grasp of implications before assuming that risk).    It's pretty much the same deal here.  If you're determined and sufficiently skilled, there are workarounds, and the bar is high enough that the vast majority of people aren't going to get themselves into trouble without understanding at least at a high level that what they're doing is a bad idea.   The optimal solution here really is to find alternatives that don't require Flash Player.  The population of folks that are skilled and confident about using unstafe technology safely aren't generally asking for help, and if you're googling for a copy-and-paste guide, that's a good indication that you're probably better off with the safeties enabled.  It's a huge hassle to do this correctly, and you're almost certainly better off finding a forward-looking alternative.   ... View more

Per the HP forums, it sounds like there are a couple alternative software packages that work and don't have Flash dependencies.  I can't vouch for them, but details are here:    https://community.adobe.com/t5/flash-player/alternative-for-hp-printer-hp-solution-center/td-p/11795957?page=1 ... View more

Microsoft will eventually push an update that will remove the copy of Flash Player that they bundle with Windows 8 and higher for IE and Edge.  If you do nothing (and have Windows Updates set to automatic), this problem will take care of itself.  In the meantime, current copies of Flash Player stopped loading content from the open web on Jan 12th.  Unless it's expressly allowed via administrative config files, Flash Player isn't going to load it, which minimizes any risk in the interim. ... View more

There's a thread over here on alternate HP packages that might work and don't have Flash dependencies:    https://community.adobe.com/t5/flash-player/alternative-for-hp-printer-hp-solution-center/m-p/11800285?page=1#M211624 ... View more

Please feel free to point them to this thread.  Our partner HARMAN might be able to help them convert their training application to a standalone application.  Depending on the complexity of the application and their financial exposure, it might be a cost-effective solution.  If they have additional questions, they're welcome to post and we'll try to help. ... View more