On protecting HTML5 apps

One of the most repeated questions I get when talking about HTML5 is the following:

“How can I protect an HTML5 app from being copied?”

Most of the time the question is not that direct to the point but that’s the gist of it. An example is in the Q&A of my “Keep calm and trust HTML5” talk at Hackernews (40:07 onwards) and this is a more structured approach to answering this question.

In short: there are ways to protect HTML5 apps, but all of them are a lot of effort and will not keep people who want to steal your code off for long. Additionally I’d go as far as saying it is a wasted effort and based on an archaic and ill-advised approach to publishing software. You can’t steal a changing product – you can only try to keep up.

Of course there are apps that need to be protected from viewing. There are also algorithms that need to stay a secret to protect some business models and users from having their data leaked without their consent. Using an open format like HTML5 for these kind of algorithms and apps though is like sending out password reminders in cleartext, storing passwords unencrypted in your database or sending sensitive data over HTTP. Just because you can do immensely wrong doesn’t mean the whole technology stack is not to be trusted.

Protect by packaging – and forfeit a lot of benefits

The simplest way to protect your HTML5 code from being viewed and read (and maybe stolen) is to wrap it in a native wrapper and send it out as a native app (Android, iOS, other OS). By doing that you get the benefits of the closed ecosystems (if your app gets the thumbs up from the app market providers) but you forfeit the benefits of the web: ubiquitous findability, simple, atomic updates and a small code footprint.

Apps code is a constantly moving target

For your normal run-of-the-mill game (think Puzzle Games) or app (productivity app anyone?) spending your time and effort on trying to protect them from being source viewed is time spent on the wrong goals. If you think about it, the code of your application is not what makes it a success:

• Good apps change all the time – Twitter for example became the success it is by observing how people use it, and add functionality accordingly (Follow Fridays and Hashtags were not inventions of Twitter, but of their users
• Your code will be forced to change – this happens mostly when companies get bought and the code of the app needs to start talking to other products by those who bought them. So there is no “one version” to steal.
• There is always a new thing to support – the most successful apps branch out to different devices which means you’ll have to change and re-code when a new one comes out that is vastly different to others
• Apps are fueled by data and users – a great app allows us to do things with it, to add content or to get a simple interface to data we need. Instagram wasn’t bought for its filter algorithms – these are available openly on the web. It was bought for its user base and the data they add to the app (and personal information they willingly expose). A travel app isn’t a success because of the HTML that makes up its interface – its success is making it easy for me to get a lot of data from different sources and seeing them in a simple to use interface.
• A good app optimises for its environment – looking at the generated source in Chrome’s developer tools will be different to what Firefox or IE gets – if you play all of them to their strengths (and there are build scripts that help you with that). So “stealing code” in one of those environments gives the thieves only a snapshot of what the whole app is. Much like saving the HTML of a Yahoo page doesn’t get you the original PHP code.

Open and available fuels innovation

A lot of the fears about HTML5 and the perceived simple way to steal code is a failure to understand that code being in the open is one of the main strengths of HTML5 and the web. The web became what it is now because we could look at code. We can look at our own code while we debug it, we can look at other people’s code and learn from it. We can re-use other people’s code and build on it and improve it and release it for others to do the same.

Client side code, HTML, CSS and JavaScript is a commodity. It is there to make things work and boy do we have to do dirty tricks at times to make it work right here and right now. The environment we publish in changes constantly and trying to release a perfect piece of code that will never have to change and is our secret doesn’t work in it – at all. Secrecy is not what makes the success of a web app – adapting and being able to change quickly is.

Owning and locking up stifles growth

I remember making money with a few JavaScript routines and libraries. I was the one who knew about making menus fly in and out more or less smoothly in Netscape 4 and Internet Explorer 5. Looking at this code now makes me shiver and want to roll up in a fetal position. Seeing that some of this code is still in use as the companies I sold these routines to wanted them “protected” (minified and obfuscated) makes me sad. It is incredibly simple to steal this code with today’s development tools, but nobody bothers. Why? Because there is a cornucopia of free, documented and better solutions available now, on Google Code, on GitHub, on Freshmeat, on people’s blogs and in many other places. Many of the sites using my “commercial and protected code” are not working any longer the way they should. And the companies who bought it never bothered to upgrade their sites and use any of the free and excellent code they can get now. It is a matter of principles, not quality of the final product.

Open code is the best job ad

Web developers like to show off. Instead of showing off in a “I can do this and you can’t” we do it by “look what I managed to make a browser do and here is how I did it”. We learned that sharing means getting incredibly worthy feedback. We learned that people playing with our code means they improve it, find solutions to problems they had and we hadn’t thought of and test our products in environments we neither have access to nor understand. The best way to find and hire great developer talent is have them play with your work – instead of having to educate them when you hire them they already come with passion and knowledge about their job.

Problems worth your solving efforts

So, seriously: all the effort you may think of putting into making your app “protected” (which will most likely result in a glass shield) can be used to solve much bigger issues you should be thinking about:

• What makes your app unique – why should users flock to it, how does it give them what others don’t?
• Test your assumptions – is the UX you chose just because another app does it really the best way to achieve this goal? Get some user testing done, don’t pretend you are your user. The best results come from people breaking your work and using it in ways you haven’t thought of
• Think about your legal protection – the theft you should be worrying about it not your code – it is the idea of your app. The hundreds of Angry Birds clones didn’t rip the code, they copy the idea and the characters. Rovio doesn’t check the code of copied apps – they point out the obvious ripping of characters, music and gameplay and get their legal team to react to that

New playground, new rules

The openness of the web, the opportunity to publish on it and additionally in closed environments with an HTML5 app, the future friendliness of web technologies to the markets and environments of tomorrow is what we should be thinking about. A lot of the demands for “protected code” reminds me of a band trying to write a song that nobody else could play. The notes are not the song. The overall mixture of music, lyrics and delivery is what makes it unique and the band’s product. The same applies to our apps. Let’s not limit ourselves to repeat what has been done over and over again and try to protect it because we think nobody else can do the same thing we did. Let’s embrace that everything is a remix, that ideas are derivatives of other ideas and that our users are the ones that will shape our apps and games with their demands, their data and their time and effort to play and use them. By using an open format thieves could always only get a snapshot of what we do right now. If we spend most of our efforts on trying to put a lock on a door that was meant to revolve we spend our time focusing on the thieves instead of our users.