Re: How to Kill a SVG
- --- In email@example.com, "Jim Ley" <jim@j...> wrote:
> "Gordon Bowman" <gordon_bowman@h...> wrote in message
> > Any obfuscated code can be unobfuscated, but it's only trivial if
> > the obfuscation process itself was trivial, e.g. garbled via
> > search and replace. Even then, you're guessing at what theoriginal
> > variable names are, losing the semantics of it, and making itrenamed and
> > difficult for the code to be maintable without a lot of work in
> > figuring out what variables and functions are actually for and
> > naming them appropriately.
> Not particularly difficult since the DOM interactions cannot be
> they're the key elements for understanding what the code does.True, but even with the DOM methods unchanged, we've all written
algorithms that have indepth comments to help us understand the
logic behind it at a later date. When those comments and the
meaningful variable names disappear, it can take time to make sense
of it all, intact DOM methods or no.
> > Obfuscation can get a lot more
> > complicated, of course, with flow-control obfuscation,
> > etc. Basically, obfuscation simply serves as a deterrent, makingit
> > more trouble than it's worth to try to steal the code instead ofaccidental
> > legally writing it from scratch.
> I would say obfuscations only value is in rebutting a defence of
> mis-use of your code when someone has stolen it, if there weresteps needed
> to read the code.Yes, I forgot that one. But I would say this is "another" value of
obscuation, not the only one.
> The "more trouble to steal than rewrite" I find on the web is
> achieved just by not writing very good script.also
> > As well, as I mentioned in a post last summer, obfuscation can
> > improve the run-time performance (as well as making the code sizethe
> > smaller). Back when I was working on Corel's dSVG, we found that
> > obfuscated code outperformed the non-obfuscatedyou don't
> > code "significantly".
> Yep, I've seen that a stated a lot, it's also undoubtedly true if
> optimise your code as you write it, but I've never seen it trueagainst code
> which has been written for speed. (The general reason is thecaching of
> references which you get as part of the obfuscation process, youcan just do
> that yourself.)The obfuscation that resulted in improved performance was a simple
search and replace, nothing intelligent about it.
> So whilst you could gain this optimisation you do it at aconisderable
> support and QA cost - you're QA'ing different code to what youdevelop
> against, line numbers and variable names mentioned in errors aredifferent
> to what you develop against.That's not really any different than the standard practice of
developing a C++ application in DEBUG mode, while giving optimized
RELEASE builds to QA.