In this instance, we aligned Flash Player's behavior with what would happen in JavaScript for an equivalent request. Flash Player pre-dates HTML5 and modern JavaScript. As good citizens in the ecosystem, we occasionally find ourselves in a position where we need to align to particulars in JavaScript's security strategy for the health of the larger ecosystem. This is one of those cases.
The most likely reason that this broke your content is because the URL in the call to NavigateToURL is no longer considered as coming from the same origin as the page hosting the SWF.
The right solution is to modify your content to handle the fact that the communication is no longer automatically permitted as a same-origin request. Depending on what you're doing and what your preferences are, your approach to that would vary (e.g. if you're navigating to a file over UNC paths to the same host that's serving the parent page over HTTPS, then you might want to load that file over HTTPS to keep it same-origin).
Because pre-announcing these kinds of changes is effectively just declaring "use it, or lose it" to attackers, we don't. The next best approach is to gate the legacy behavior behind a flag, so that for the tiny subset of users that are affected by this kind of change, they can buy some time while they sort the issue out in their application. The goal with these kinds of things should always be to wean yourself off as soon as possible (that's why we chose the EnableInsecure* naming), but they exist as pain-relief that your operational teams can employ while you pursue any necessary engineering or architectural changes.
AdChoices