OK, it's like this: SWF launched in standalone player can interact with the system AND load remote content, just like the browser can do the same thing. SWF launched in browser plugin can only access permitted folders on your hard disc. To allow access to the folder you should either use the web interface (see my previous link), or read from the link Ami posted and try to figure out how to do that on Mac (you are not required to use web interface to establish local trust relationships between SWF and specific locations in file system, it's just that, I simply don't know how to do that on Mac...) There's yet another option for launching a SWF - that's how I usually do that - from the local HTTP server, in such case it acts more like as if it was deployed to the actual server and all the following rules apply. I would definitely recommend the later way of debugging as it is the most similar to the live situation. The loading of content other than SWF into another SWF is governed by policy files aka crossdomain.xml. You need these files if you are loading content from domains other than SWF origin. The loading of other SWFs by SWF is governed by two things: ApplicationDomain provided to the Loader when loading SWF with LoaderContext - by default it won't allow crosscripting. Security.allowDomain() doesn't define how classes are loaded into application domain, however, should prevent security errors related to crosscripting.
Well, yes, it is complicated...
