Blog

Every entrepreneur needs to walk away from a few smoking craters. It builds character and informs the next endeavor. In that spirit, we offer this post-mortem of our Zarqon Active License Control System.

What Were We Thinking?

In early 2009, the future of Adobe Flex and Air was bright. The platform had matured, and the possibility of a single codebase for desktop, mobile, and web was in sight. Companies were flocking to it, and business was booming for those who could make it sing. Apple’s App Store had only recently opened, and access to it via Adobe Air was still more than a year away. Desktop and web were the attainable targets, but there was a lot of opportunity there.

Although we’ve always been a services company, it was hard not to think of new ideas for applications that could be created, and if one could stratify features to exploit the freemium model, the money truck would just roll up to the door every week. We came up with of a number of such ideas, and the itch to start building something was too great to resist.

But for every potentially earth-shaking app we could envision, a single issue kept coming up, staying our action: How do you give away some of the features and sell access to others? No matter what we built, we had to come up with a licensing scheme for it as well. It only made sense to attack that problem first. It would break the logjam and let us get rolling on something, while we continued to flesh out which app to build.

The Big Picture

As the architecture for the Zarqon project began to move forward, two things became immediately apparent:

1. It was a non-trivial endeavor.

2. Everyone else building freemium Flex and Air apps faced the same issue as us.

What we were building was an Adobe Air desktop app that would manage licenses stored in Amazon S3 buckets. There would also be an API library that could be embedded into apps to allow them to read read stored licenses and determine what features were enabled. If we documented and polished it, maybe it could sell it.

And best of all, it would prove its own concept. We could sell access to the License Manager and its features and secure them using… Zarqon itself! Would the universe implode? We didn’t know but we had to try. If we were successful, we’d have our first product.

Above is the fifty-thousand foot view of the system, and the hardest part was coming up with an approach that let the licenses be encrypted and safely downloadable by anyone while remaining unusable to anyone but the license holder. This allowed us to use ‘dumb’ Amazon S3 buckets for storage and avoid running a license server (and all the ongoing responsibility of protecting it from attack).

Spy vs Spy

ActionScript resembles JavaScript in many ways (after all they share a common ancestor in ECMAScript 3, but ActionScript is compiled into bytecode for execution by Flash Player. As a result, developers often had a misguided notion that their code was secure from prying eyes. As it turns out, there are several Flash decompilers out there that can extract the source code, sometimes complete with comments, at the click of a button.

How could I possibly secure the object code from hackers who could just decompile it, skip over the license checks, and then distribute a cracked copy of the software? The day I learned about about Flash decompilers was a very depressing day.

Would I have to find a way to encrypt part of the code itself and decrypt it at runtime? Was it even possible to secure a Flash app? Was the whole project dead in the water?

Further research turned up the microcosm of Flash obfuscators. As it happens, there is this whole murky underworld of black-hat and white-hat hackers who continually figure out how to break each others’ code with some new twist.

Obfuscators do a job similar to JavaScript minification (also referred to as uglification). It does things like replacing meaningful variable names with single characters, removing whitespace, etc. Only it goes way further. There are so many ways to mangle code and still leave it runnable that these products are typically built so that you heap layer upon layer of obfuscation until the program finally fails. Or you can just turn on all the features of the obfuscator and if the code runs, great. If not, then peel away the layers of the onion until you’re left with something that does. For every setting, you must compile and test the code. If it’s a desktop app, then you are most likely signing it, so you have to do that each time as well, to be 100% certain that a release candidate will actually execute all its use cases properly.

While it was heartening that there was an approach to defeating the black-hats, it was certainly outside the scope of what we were trying to do: license management. Adding obfuscation would clearly turn this into an endless hacking quagmire. Nope.

I ended up writing an in-depth article on the subject for Flex and Flash Magazine.

So we teamed up with the best of the obfuscators, KindiSoft SecureSWF, and got a discount for our customers, in exchange for which, we’d council them to use Kindi, which is what we used for Zarqon itself.

This is a great example of where a strategic partnership is better than going it alone. Kindi was fighting the good fight and was in it for the long haul. We might be able to charge more for our product if it handled this function, but the maintenance nightmare that came with it was untenable.

That was ok, though because we wanted single developers to be able to realize the dream of putting out a licensed app and making an income from it. There were no other licensing systems when we started, but by the time we were done, there were a few, and they were expensive. Big corporations could probably afford what they were charging, and it might cover what they were having to pay their staff to run and protect their licensing servers. Instead, we would sell to the little guy and make money from that market.

And for awhile, it worked.

The Nails in Flash (and Zarqon’s) Coffin

In 2010 Apple’s App Store was gaining momentum, and Steve Jobs delivered his Thoughts on Flash letter, which seemed as if it would exclude Flash from mobile forever. Eventually, with Adobe Air 2.0, it was possible to put apps into the App Store, but that didn’t work like the desktop model. Zarqon didn’t make sense for mobile, since there was a gatekeeper through which apps were delivered, and no way to copy an app from one phone to another really. But it didn’t matter, because Mr. Jobs’ declaration that Flash was a thing of the past set off reverberations in the echo chamber that eventually tore the Flex and Flash industry apart.

Amid industry-wide clamor about HTML5 and open standards, Adobe, in 2011, chose to Open Source the Flex SDK with a little help from The Apache Foundation. While some developers cheered, industry experts hailed it as a sign that Adobe was abandoning Flash. Businesses no longer saw the Flash Platform as a viable long term option for building new products. By 2014, the call for products such as Zarqon had waned dramatically. As a result it was no longer cost effective for us to offer and maintain the product.

Our Takeaways

Firstly, the whole spy vs. spy business was an eye opener. We just did not see that coming. There weren’t any other competitors out there for Zarqon at the start, and we didn’t go down the ‘what-if’ road far enough to realize what an issue this was going to be. Sometimes the further in you go, the bigger and messier it gets.

Secondly, and most importantly, it showed us that no matter how technically superior a product may be (meaning Flex), if the company that owns it fumbles the ball, a whole industry can be decimated. Zarqon was a canary in the coal mine for us. As the sale of Zarqon licenses waned, so did the calls for our ActionScript architecture and development services. Should we move the practice back to J2EE? Over to .NET? No. No matter how rich those industries may seem, there are companies at the top of the food chain that could wreck the whole thing. That’s why we chose to move to HTML5. It may seem chaotic, and less suited too OOP and pattern-based architecture than ActionScript, but no single entity can destroy it.

Remembering Zarqon