This content has been marked as final. Show 8 replies
This is nothing to do with swfs I'm afraid. Its related to your Operating system and file browsing software. A swf file is treated the same way as any other file in this regard.
You restrict access to your files based on the operating system and login accounts etc.
If you have permission to access to the file system and right-click a file in windows explorer for example, not matter what file type it is you can copy it. You may be able to restrict user permissions with different permission settings for different folders or file types though, perhaps in some OSes.
when it's in someone's cache, it's not your file. having any way to change the way the user's os would view or handle that file would be a substantial security issue.
Boxing Boom :just to clarify in case I wasn't clear: I wasn't suggesting in my last sentence that preventing copying from the browser cache was possible in some OSes, just that some types of user account permissions may permit access restrictions to various folders/file types - but that's only for computers you have directly admin control over and it would depend on the operating system. Basically you would need to own/manage the computers that you wanted to restrict. I agree with kglad entirely about the browser cache.
I focused on the local folder/local drive part of your question and assumed it was a general question related to that and not just the browser cache.
Kglad, is closer to what I was trying to explain, GWD I know what you mean.
Right, what I am trying to put across is this situ;
Any actionscriptor creates a swf file and decides to sell it, multiple times. Now let us assume its a slide show driven by XML. He/She packages it - swf, xml and some example photos. My question is, 'What can stop the purchaser from either passing on or selling this on? What can protect the ActionScriptor from being ripped off? Copyright infringement could go unnoticed for years - if sold in another part of the World.
Can the ActionScriptor script some sort of trigger in his/her code that sends back data, to altert him/her of how many times the swr has been copied and its location?
Maybe, I am just a little immature ;) or its a valid question ;~)
Many thanks to both of you, for your responses.
that's not immature. naive perhaps, but not immature.
look at it this way: if microsoft with all their resources cannot prevent the theft of their products what hope do you have of preventing the theft of yours?
all you can hope to do is to make it more or less difficult to steal your work. but the more difficult you make it to steal your work, the more burdensome it is for legitimate users to use your work.
case in point: microsoft and its "windows genuine advantage" fiasco.
If you sell an application, we'll assume the user has is the SWF, and maybe any externally loaded assets. While nothing is foolproof, there are a few things you can do make it very difficult to make it worth someone's bother to copy your work.
- First, don't give out the source code if you're that concerned.
but if you're doing work for an agency and not an end client, that
may not be an option as they own the rights to the work. In which
case it's their problem if it gets copied, not yours.
- Author your SWF in AS 3.0. To date not a single publicly
available application has been made to decompile an AS3 SWF. It's
almost as if, on the quiet, Adobe issued a cease and desist order
to the few manufacturers of SWF decompilers out there, cause no one
has updated their products for AS3 decompilation. (just a theory,
btw) Nor have I seen any underground AS3 decompilers on the P2P
networks, though they are rumoured to exist. Which means they'd
have to know a guy who knows a guy who knows an uber hacker who has
made his own AS3 decompiler. Which would be extremely rare. Unless
you're doing a project for the DoD, I would not worry about this
- You can protect the SWF from being hosted from a domain that is
not the client you sold the app to by using the _root._url
property, and checking if it's an authorized domain. You'd have to
combine this with an obfuscator though if authored in AS1 or AS2
- If you're using AS1 or AS2 (which are both the same at the
bytecode level), use an obfuscator. This will make it nearly
impossible for eomone who decompiles your SWF to understand your
code, and the good ones introduce illegal characters which still
work fine for the SWF, but when decompiled into an FLA and
recompiled will give the hacker compiler errors all over the place
so they won't be able to recompiler your code with their own
changes using a commercial decompiler.
- You can also protect the data to a certain extent by using encryption, but you gotta tread carefully on this one because a SWF hosted on a US server can't go over 128-bit encryption.
The goal is to make it not work someone's bother to copy your work. Even with an AS3 SWF, there is no way to protect your graphical assets, so the best they could do with an AS3 SWF is copy the look with none of the functionality, and that would be like creating the app from scratch for them. At best, AS2 obfuscators will make it too difficult to be worth someone's bother.
So there is no iron clad protection, but there are techniques that can be used.
Personally I don't bother with them, because most of my work is in AS3, which is pretty safe from hackers AFAIC. If it were a personal AS2 project where I didn't want to open source the code, or a client specifically requested code obfuscation, then yeah. But if someone wants to bother copying work that I've done for a client, I'd advise them of the copyright violation, and let the lawyers sort it out.
- First, don't give out the source code if you're that concerned. but if you're doing work for an agency and not an end client, that may not be an option as they own the rights to the work. In which case it's their problem if it gets copied, not yours.
Thanks guys, your feedback has been great. I guess its relying on copyright and lawyers ;~)
joeflash.ca, pretty cool cv! I liked the simplicity of your style. I have purchased that book Foundation cs3. Great resource; the carousel tut is great. The gel pill is old news, however the way shown is damn good approach for creating future buttons etc...
You're welcome, and thanks.