49
\$\begingroup\$

I'm in the middle of planning a game built using JavaScript and HTML5.

I'm having trouble understanding how you could prevent someone from simply copying the JavaScript from the web server and either making their own game with it (not my biggest concern), or substituting their own JavaScript functions and dashing any hope for reliable clients in the wild if the game was to eventually support multiplayer.

Can anything be done to prevent just anybody from reading the JavaScript?

If not, should all game processing be taking place on a server somewhere with the client's only responsibilities being capturing user input and drawing graphics?

\$\endgroup\$
2
  • 24
    \$\begingroup\$ You're last paragraph reads about right, its true for business apps, and its true for games, always treat the client as hostle. \$\endgroup\$
    – Nate
    Commented Sep 9, 2010 at 14:48
  • 4
    \$\begingroup\$ If I can READ it, my browser already has a copy. Then I can also save it somewhere else. Anything you allow to be read, can also be copied. \$\endgroup\$
    – BerggreenDK
    Commented Nov 21, 2010 at 2:36

12 Answers 12

Reset to default
49
\$\begingroup\$

Keep all your game data and logics on the server. Part of the game which is on the client side can be copied using appropriate tools anyway (even if it's in Flash or Java), so just accept it and don't care too much about it.

To keep your javascript less copyable, because of bad readability, you can minify it. That's a good practice anyway as it makes the gaming site download faster.

\$\endgroup\$
4
  • 4
    \$\begingroup\$ Depending on the coding practices, all of the content on the server can be compromised as well. To minify the code and obfuscate only deters those that do not want to take the time and logically map out what it is doing. Bottom line is, if your worried about the intellectual property rights of your code; don't put it on the web. \$\endgroup\$
    – John
    Commented Sep 9, 2010 at 18:24
  • 1
    \$\begingroup\$ That does not mean you should not minify, that deters the lazy people. You can also try processing your game logic on the server and return json objects through ajax, but the return can still be viewed with firebug. Obfuscate your production version but keep a heavily comment version for yourself (this makes it harder to maintain). You can do things to deter people, but it is never 100% safe. \$\endgroup\$
    – John
    Commented Sep 9, 2010 at 18:31
  • 3
    \$\begingroup\$ Indeed. Expanding minified code doesn't even take much effort. jsbeautifier.org \$\endgroup\$
    – James
    Commented Sep 10, 2010 at 4:46
  • \$\begingroup\$ @John please notice sometimes deterring lazy people is irrelevant, since some games are ruined once a single cheater appears, so it's not relevant if only one or many are cheating. \$\endgroup\$
    – o0'.
    Commented Mar 11, 2012 at 12:02
12
\$\begingroup\$

how you could prevent someone from simply copying the JavaScript from the web server and either making their own game with it (not my biggest concern)

This is where the law helps. In practice this doesn't seem to happen very often.

or substituting their own JavaScript functions and dashing any hope for reliable clients in the wild if the game was to eventually support multiplayer.

There are no reliable clients in the wild, for exactly this sort of reason. Give up on this dream now. :)

\$\endgroup\$
2
  • \$\begingroup\$ The law is not going to be of much use when the site hosting it is in a country that does not care much about intellectual property rights, or is otherwise antagonistic to your country for whatever reason. Even when that's not the case, the cost of initiating a (potentially international) legal action is likely far beyond the financial resources of someone who would ask this question here. \$\endgroup\$
    – Paul Legato
    Commented Sep 26, 2012 at 21:23
  • \$\begingroup\$ The intent of the answer was not so much to recommend legal action, but to suggest that trying to lock down such software is mostly pointless, at least in part because many of the people who would copy it are discouraged by law, but also because clients can be reverse engineered whether they use Javascript or not. \$\endgroup\$
    – Kylotan
    Commented Sep 26, 2012 at 23:42
8
\$\begingroup\$

Just as everyone else has recommended; keep as much code as possible server-side.

A method I have used to deal with code copying is a bit odd, but it has worked well so far.

  • Server-side, generate unique id and store it for later.
  • Server-side, add unique id in script element during html rendering.
  • Client-side, create a WebSocket connection and pass the unique id to the server.
  • Server-side, match id against current list.
  • If match is not found, close connection.
  • If match is found, replace message handler with your "proper" one and discard id.
  • Stream your secret code to client as JSON, {"func":"function(){dostuff();}"}
  • Client-side, watch for messages, if they contain "func", eval it.

Now your secret code is executing client-side and won't show up in view-source or inspectors/consoles. There is still ways to get at the code, but it's quite a bit more difficult.

\$\endgroup\$
5
  • \$\begingroup\$ If I needed to grab something from the above solution; I would connect true WebSocket too and try to make a "fake client", or use a Firebug debugging tool in a browser and just stop the script to checkout the values. \$\endgroup\$
    – BerggreenDK
    Commented Nov 21, 2010 at 2:40
  • \$\begingroup\$ You can't make a fake client unless you can somehow predict what unique ids are currently available, as they are generated at page load time and tossed at script connection time. Also, stopping the script and looking at the values is difficult, since you are eval'ing an anonymous function. Like I said, there are still ways to get at the code, it's just more difficult. For the most part, enough so that your code should be "safe enough". You can't do much more than that with client-side code. \$\endgroup\$
    – Stephen Belanger
    Commented Nov 21, 2010 at 16:29
  • 1
    \$\begingroup\$ It'd be pretty easy to write a fake client that just loads the real client from the server and scrapes the current secret value from it each time it starts. \$\endgroup\$
    – Paul Legato
    Commented Sep 26, 2012 at 21:25
  • \$\begingroup\$ I wouldn't say it's "easy" so much as "not impossible". As I said, there are ways around it. There's no such thing as a perfectly secure system. Just adequately obscured interfaces such that most will find it too much effort to hack. In this case, you'd be streaming bits of code, so a hacker would need to create a client to receive and arrange the code into a useful structure. You'd stream code as you need it, so the hacker wouldn't have immediate access to the full code dump. \$\endgroup\$
    – Stephen Belanger
    Commented Sep 26, 2012 at 21:51
  • \$\begingroup\$ Sending functions over websocket is ridiculous. If you are this paranoind, you should instead have implemented another SSL layer where the client code that knows the key is an anonymous function. That way only way to get anything from the communication would be to do a memory dump of JS core. Not even I know how to do that. \$\endgroup\$
    – Tomáš Zato
    Commented Mar 11, 2020 at 11:18
3
\$\begingroup\$

The only way to be reasonably certain that your game code will be secure is to build a client/server type of game and put as much code as you can on the server. And of course, make that server secure!

The main issue is that if code is running on my computer, I can inspect it, decompile it, and figure out how it works. This is true for JavaScript, Flash, C++, anything else. In fact, in MMO development (which is where the bulk of my professional experience is) the assumption from the very beginning is that the client is compromised: whatever you have written for the client is already in the hands of whoever wants it, malicious or not.

Minifying code does provide a tiny amount of protection against people who are too lazy to unminify it using one of the many tools out there. (But production code should be minified to reduce its data footprint.)

But if you're in a situation where, say, your boss wants some kind of code protection, you can google "Javascript obfuscator" -- there's a lot of free and for-pay software out there that makes JS at least about as impervious to decompiling as Flash is.

\$\endgroup\$
1
  • \$\begingroup\$ I just want to point out that C++ is not on the same level as Javascript. C++ compiles to assembly, which someone needs to be read in order to understand the logic of a game. Each statement in C++ can create multiple lines in assembly, which makes it a very time-consuming task. Obfuscating javascript is not the same, since its the same language. Anyone can "beautify" it and start reading almost human-readable statements. \$\endgroup\$
    – Tom Tsagkatos
    Commented Aug 9, 2019 at 13:56
3
\$\begingroup\$

Aside from all this talk of code obfuscation, be sure to put a very clear copyright declaration at the top of each file and make it obvious that the license doesn't allow for alteration or commercial usage. This gives you legal recourse if someone does try to copy it. If you aren't willing to go to court over it, then this whole question is mostly academic.

\$\endgroup\$
1
  • \$\begingroup\$ This is fine for what it's worth, but that's not much. The concept of intellectual property is in practice not recognized in many countries, and in any case the legal costs of a court case are likely far beyond what a poster to this site has available, particularly if the attacker is in another country. \$\endgroup\$
    – Paul Legato
    Commented Sep 26, 2012 at 21:27
0
\$\begingroup\$

I think if you make your game multi-player, which entails keeping your game logic in the server you would probably make it at least less appealing to steal. You can't trust the client really. As someone has already mentioned, there are tools for even compiled languages like Java and Flash, that can reverse engineer the text of the code from the byte code.

\$\endgroup\$
0
\$\begingroup\$

I think people caught on this problem are looking at it wrong. Don’t look at how code has been protected - your game engine isn’t your game. You should be protecting data - look at how websites, Netflix, and Spotify protect themselves from scrapers.

On the server side, you need to monitor the resources people are requesting. You can look for two things that would be suspicious:

1 - Requesting resources in an order that doesn’t make sense in my game. IE, if you have a set of level data and a set of enemy data, where it would be expected that levels are retrieved then enemies for that level, it wouldn’t make sense if you saw back to back requests from an account for level data without requests for enemy data in-between. Or if that level sequence doesn’t make sense - IE, if level 3 has to be visited before level 2, but you see them access 1, 2, 3.

2 - Requesting resources too quickly. It wouldn’t make sense for a request for level 2’s data to come just a second after the request for level 1’s data.

If either behavior is detected on the server side, you can block their account from making further requests and pop up a bug report form on the client end. If your piracy detection system has a bug, then it’s proper to ask for details - you’ll review and unblock their account if it turns out you were wrong. If you’re right, then they’re stuck with an uneasy feeling that you’re onto them and might stop trying.

You can further monitor for if you’re ending up with a lot of accounts getting blocked in a certain part of the world - might indicate someone really determined to steal the data (without even bothering to play the game properly.)

Someone determined to steal the game could still do a proper 100% play through, capturing every single data packet, but the more value your game offers, the harder it’d be for them to accomplish.

\$\endgroup\$
-1
\$\begingroup\$

You need to use a Javascript Minifier. There are many options available feel free to find one that you like. To save you some research here's one you could try Yahoo Minifier. I haven't run that myself but I assume it will do what you need. The goal is to 1) reduce file size and 2) obfuscate code. This is accomplished by removing all whitespace, comments, and replacing variable names with shorter, nonsensical ones.

Most web applications today have a significant amount of Javascript and use tools such as these to try to protect their IP. As others have said you should always ask, "Can I do this on the server?" for important or sensitive operations, but I believe this should offer some protection.

\$\endgroup\$
4
  • 8
    \$\begingroup\$ Security by obscurity obscures potential for security. :) \$\endgroup\$
    – Rushyo
    Commented Sep 10, 2010 at 11:42
  • 1
    \$\begingroup\$ Oh please. I hear this quote all the time but it's absolutely not true. Truth be told obscuring the JS would at least deter some people. \$\endgroup\$
    – Sergio
    Commented Oct 6, 2010 at 17:24
  • 3
    \$\begingroup\$ minifier doesnt help him. I believe most "serious" people knows how to "expand" those scripts again. \$\endgroup\$
    – BerggreenDK
    Commented Nov 21, 2010 at 2:37
  • 2
    \$\begingroup\$ @Sergio: you hear this quote all the time because, you know, it is true. It will deter "some" people, true, but deterring "some" people is pointless: when you're cracked once, you go down. \$\endgroup\$
    – o0'.
    Commented Aug 2, 2011 at 14:52
-1
\$\begingroup\$

Use Google closure compiler http://code.google.com/closure/compiler/ It is not just a js minimizer ;)

What are the benefits of using Closure Compiler?

  1. Efficiency. The Closure Compiler reduces the size of your JavaScript files and makes them more efficient, helping your application to load faster and reducing your bandwidth needs.

  2. Code checking. The Closure Compiler provides warnings for illegal JavaScript and warnings for potentially dangerous operations, helping you to produce JavaScript that is less buggy and and easier to maintain.1.

\$\endgroup\$
-1
\$\begingroup\$

Or you could use something like Game Maker HTML5 to create your game which will obfusicate the code for you. That means that it will make the code unreadable to humans. And it'll be near impossible to edit.

\$\endgroup\$
1
  • 2
    \$\begingroup\$ -1 Obfuscation will only go so far. It certainly won't protect the game from being copied or altered - as has been mentioned on the other obfuscation answers to this question. \$\endgroup\$
    – doppelgreener
    Commented Oct 22, 2012 at 15:29
-1
\$\begingroup\$

Anything proprietary should be kept server-side. Client side you only provide enough for it to facilitate their use of the game.

\$\endgroup\$
-1
\$\begingroup\$

Putting everything on the server could have performance issue and not really using all the potential of the web as we know it today.

You can write your code in c++ and compile it to binaries.

Native Client (NaCl).

See https://stackoverflow.com/questions/9018537/how-to-run-c-programs-on-the-web-inside-a-browser

\$\endgroup\$
1
  • \$\begingroup\$ Welcome to GDSE. OP is asking about JavaScript specifically; so while they maybe could re-write to C++ & use NaCl, that solution doesn't really address the needs as stated. Also, answers should be as self contained as reasonably possible - mentioning NaCl & dumping a link isn't as good as offering a summary as to what NaCl is or why it might help. \$\endgroup\$
    – Pikalek
    Commented Aug 14, 2019 at 14:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .