But I’m going to throw this out there again:
you can try but it is unlikely to cover 100% of the cases and it will take a lot of efforts.
It’s not impossible but it will really take a lot of hard work and unlikely to block 100% of all the “vilains”.
So to answer your question, no. It will not completely prevent your swf from playing on another domain. Anything you do only makes it harder. The question is how much work do you want to put into it and how hard do you want to make it?
Approach: Prevent caching
Counter: (easy) People can download the swf directly through the url
Approach: Use htaccess you can prevent people from hotlinking to the swf your domain is hosting
Counter: (easy) People can download the swf and host it themselves (at least they’re not using your bandwidth)
Counter: (medium) Spoof the referrer to make the request appear to come from the original domain
Approach: ExternalInterface checking window location
Counter: (medium) Use a tool to inspect and replace strings, such as domain paths, in the swf (requires resaving and hosting edited copy of the swf)
Approach: Use a parent swf to load your swf as a child
Counter: (easy-medium) People can download both once they realize a child swf is being used
Approach: Use a parent swf to load an encrypted child swf
Counter: (medium-hard) Depending on how its implemented, the key can be captured and reused with the same encrypted child
Approach: Write your swf only as a view for logic encapsulated on the server
Counter: (hard) Spoof requests to your server making it think its originating from your domain
Counter: (very hard) Reverse engineer your server interactions