We continue to be forced to lock down the ability to for SWF files running in the local filesystem to access external resources for security reasons. Personally, I would like us to retire this functionality altogether, and newer browsers like Edge already impose those restrictions at the browser.

The issue you're experiencing with URL resolution lies at the intersection of a valid pseudo-protocol and the ability to abuse it by taking advantage of the overly-permissive interpretations of similar URLs by some browsers. While it's unlikely but possible that we may change this behavior to fix the issue, it's probably just going to be a continued source of pain for you.

You're far, far better of either hosting the SWF on a web server (even a local one), or by packaging your content as a desktop Adobe AIR application, which exists to address the local application use-case, and is a far better choice for this kind of approach.

We continue to be forced to lock down the ability to for SWF files running in the local filesystem to access external resources for security reasons. Personally, I would like us to retire this functionality altogether, and newer browsers like Edge already impose those restrictions at the browser.

You mean that in the future, the local file will not be able to play on the flash player (activex)?

If so, this is a big problem for us.

because, we will take a lot of time and cost in order to change our application and contents.

We want to know when you intend to lock down "the ability to for SWF files running in the local filesystem".

We need to prepare for this.

The issue you're experiencing with URL resolution lies at the intersection of a valid pseudo-protocol and the ability to abuse it by taking advantage of the overly-permissive interpretations of similar URLs by some browsers. While it's unlikely but possible that we may change this behavior to fix the issue, it's probably just going to be a continued source of pain for you.

so, Is the issue bug, not specification?

We want to know specifically when the issue will be fixed. in the near or far future?

As measures of the issue, we are going to change the swf path from "file:///d:/" to "d:\" for playback.

(network path: "file://server/"->"\\server\")

You're far, far better of either hosting the SWF on a web server (even a local one), or by packaging your content as a desktop Adobe AIR application, which exists to address the local application use-case, and is a far better choice for this kind of approach.

OK.

We will consider about this, but we cannot change our application soon.

What I see in practice is that we're slowly being forced out of being able to do this by the browsers. Given the security landscape in 2015, I don't personally think this is a bad thing, or a fight that we could win. While there is no formal decision to deprecate local filesystem access at this time, I personally believe that an eventuality, and that it's much better to encourage developers to think about a migration strategy now, vs. letting people be caught off-guard later.

UNC paths in particular are problematic. Until we debug the issue, we don't know whether or not it's fixable, but network traversal is an area of particular interest to attackers, and the ambiguities at the intersection of HTTP and UNC paths in the browser create scenarios that are difficult to safely interpret. So file:/// is generally a better choice. although I'm not sure why you're running into this particular issue yet.

Using Adobe AIR instead of the browser for local applications would eliminate the risk of losing local filesystem access in the future, while allowing you to reuse much of your existing Flash-based code and content.

UNC paths in particular are problematic. Until we debug the issue, we don't know whether or not it's fixable, but network traversal is an area of particular interest to attackers, and the ambiguities at the intersection of HTTP and UNC paths in the browser create scenarios that are difficult to safely interpret. So file:/// is generally a better choice. although I'm not sure why you're running into this particular issue yet.

Because, the latest Flash Player cannot use “file:///”.

This is the issue that I have reported.

Were you able to reproduce this phenomenon?

And, I want to know whether there is the mind that the Adobe repairs.

The most troubled problem for us is it was able to do playback at the previous version, but suddenly it is that it has been not able to do playback at the latest version without prior announcement. As a result, our customer complained to us, then we had to repair our application as soon as possible.

Currently, we changed our application to a method of UNC path (“d:\” or “\\server\”) because the latest version of Flash Player cannot use “file:///”. But you said that “file:/// is generally a better choice”.

A last question is, after you fix this bug, should we change our application to the method of “file:///”("file://server/") again? Until we change our application to Adobe AIR etc.

We have not reproduced the issue yet. I've seen enough anecdotal evidence to believe that this is an issue and I've opened a bug on it, but nobody has provided a reproducible example yet.

In the absence of a reproducible scenario, I have to have a quality engineer investigate the problem, create a set of tests from scratch and hope that they find a set of conditions that reproduces the problem while working blindly, vs. just pointing someone with a C++ debugger to a set of reproducible steps that demonstrates the problem. This adds considerable time to our investigation and response. This issue has already missed the window for the January release, so we're looking at February at this point. The window there is also fairly narrow, so I'm keen to get this investigated as quickly as possible.

Posting a bug at http://bugbase.adobe.com/ with complete step-by-step instructions on how to reproduce it would certainly help speed things along. If you post the bug number here, I'll get the notification and will open it to the team directly.

I don't have a strong preference for one method of using file:/// paths vs. another. None of them are great options. It's hard for me to predict how they'll be abused in the future, and/or how we'll be forced to respond. I also don't have clear insight into specific changes in the various browser pipelines. It's just clear that there's a trend in restricting plugin access to the local filesystem, and that there's significant existential risk to this kind of use-case in general.

Is this issue fixed yet? We are facing the same issue with one of our MFC application written in VC++. The flash SWF is not loading and we see a black screen. We have tried with both SetMovie and LoadMovie on ShockWave Flash Object.

To answer your question more directly, embedding ActiveX controls into standalone applications is not guaranteed to be viable over the long term. We don't technically support the use-case now, although we're aware that there's a body of legacy applications that take advantage of this approach, and we do our best to do right by the developers that have invested in the Flash platform over the years, and that still use this approach.

That said, we don't actively test this use-case, although we do try to fix it if and when things break. If faced with a choice between security in the browser plug-in case and the application case, we'll choose the browser plug-in.

As the security landscape continues to evolve and become more challenging, we're often faced with decisions for which we cannot anticipate all of the potential side-effects, and the nature of those issues frequently does not afford us the luxury of a slow and measured response.

The current release is a response to a security exploit in the wild that we were forced to address quickly. It went out on Monday, so it should have patched the vast majority of your users already. Our priority will always be the security of the web browser, and our approach in these situations is to remediate the immediate threat while hopefully not breaking anything, and then to deal with any unanticipated/undiscovered functional fallout when it arises. The issue you're experiencing is a functional issue that was fallout from having to push that release prematurely.

We're currently aware of a cluster of bugs impacting the embedded OCX use-case, and are actively investigating. I don't make promises that I can't keep, so I'm not going to talk about dates, but we're doing our best to provide an expedient fix in the form of a production release.

Adobe's US offices are closed for the US holidays, which is slowing down the response. People and systems are unavailable due to vacation travel, scheduled maintenance, etc. Fortunately, we're all back in the office on Monday and should have critical mass. In the meantime, we're already conducting the analysis and considering the logistics of what can be fixed, when. I expect it to be a fairly quick turnaround.

We hope to push out a beta in the next couple of hours that has a fix for this issue. We'd like to get your input once it's available to verify that it resolves the problem for you. I'll post again once the beta has been released.

If you've been impacted by one of these bugs, please try the beta out and let us know if it helps or you see other issues.

We still have one critical sound bug (Bug 4103304 - “Timelines with multiple layers are unable to stop playing sound”) that we are currently working to resolve. We had hoped to get a test build out today but our internal testing found that we hadn't fully solved the problem. We're actively working on a new fix and I'm hopeful I'll have something to try in a few days.

Bug 4103304 - “Timelines with multiple layers are unable to stop playing sound”

If you've been impacted by one of these bugs, please try the this build out and let us know if it helps or if you see other issues. The link below contains installers for both Mac and Windows, ActiveX, NPAPI, and PPAPI.

Adobe is planning to push an update (20.0.0.286) through the Adobe servers on Tuesday, January 19th. This update will apply to OSX NPAPI and Windows XP - Windows 7 NPAPI, ActiveX and PPAPI. We are also coordinating with Google to push out a component update for Chrome at or around the same time. Updates for Microsoft IE on Windows 8.1 and Microsoft IE and Edge on Windows 10 should occur on the scheduled February 9th update via Windows Update.