Can you encrypt or prevent your jsx script code from being seen?

[Maple Stirrup]

If not, would you be able to with a plugin?

[Manan Joshi · Accepted solution]

Export it out as jsxbin, you can do that using Extendscript toolkit. To add another layer of security over it, you can use jsxblind library by Marc. See the details below

https://www.indiscripts.com/post/2017/01/jsxblind-new-version-for-extendscript-developers

-Manan

[hhas01]

To be clear, JSXBIN and friends are source code obfuscators, not compilers. What they do is make it harder for others to decipher your code by making it difficult to read: removing all comments and whitespace, replacing your descriptive variable and function names with randomly generated ones, add fake code that never actually runs but helps disguise the real code under reams of noise, etc. That’s about as good as you can hope for with a language such as JavaScript, where all programs are loaded and run from plain text source code files.

Some scripting languages (e.g. AppleScript) can save scripts in binary (bytecode) format, which requires specialist knowledge to convert back to human-readable code, and some (e.g. Python) have tools that can convert your scripts to C code and compile that, which would take a very skilled programmer a lot of time to reverse. Or you’ve always got the option of implementing your product as a C++ plugin, which again is a lot more expensive for others to reverse-engineer—and a lot more expensive for you to write in the first place.

That said, even programs written in fully compiled languages such as C++ and distributed in binary form only (e.g. Adobe Illustrator) aren’t immune to reverse engineering given sufficiently skilled and motivated programmers of dubious morals. (Hence all the w*r*z sites offering “cracked” versions of commercial software.)

It’s all a matter of weighing costs vs benefits. Your hope is that the time and labor (and possibly legal) costs to them of hacking your code significantly outweigh any benefits they might hope to gain, and so deter them from doing so. If it’s a simple low-cost script you wrote for a handful of clients then running through an obfuscator is likely sufficient to put them off trying to extract your “secret formula” and just pay their fair dues to use it. OTOH, if it’s a major software product that’s going to retail globally and generate millions of dollars a year then, yeah, someone’s likely going to crack that code. But that’s why you have copyright, software licenses, legally-binding contracts, and your own fleet of well-paid lawyers so you can go after those violators with the law.

HTH

--

p.s. Encryption isn’t really a practical solution as your customers’ computers need to be able to run your software themselves—which they can’t do if it’s been locked with encryption and only you have the key. So even if you do encrypt your main code, you still have to supply a way to decrypt it along with the key for performing that decryption… and you’re right back to where you were to begin with. Again, if you’re thinking on those lines you’ll be much better investing in a big bucket of chum for your legal department.

p.p.s. Were you doing high-end InDesign automation, you’d have another option which is to offer your automation as a hosted service (aka “SaaS”) where users upload their source files to your website which automates them using InDesign Server and returns them the finished files. That way users never have access to your proprietary automation code so cannot steal it (short of breaking into your server and/or data center and committing outright theft). But of course you have to consider if that operating model works for both them and you (and unless it’s earning you six-figure sums the costs of licensing IDS alone mean it’s not worth your trouble). That’s not an option with Illustrator though, which only allows existing license-holders within your own organization to use it.