Remix Protection

Hello! My name is suu! I am discussing a topic that has been concerning me a lot for the past 2 years. It’s about remixes. A lot of future (or past) features games keep popping up which they don’t deserve to. I’m thinking about you should add a feature which does not allow remixes on your game. This is a short paragraph, but if anyone knows any code which protects your game (for now) please send me it!



For App Lab:

var channel = getAttribute("divApplab", "baseURI");
var originalChannel = "(channel id of the original app)";
channel = channel.replace("", "");
channel = channel.replace("/edit", "");
channel = channel.replace("/view", "");
channel = channel.replace("/embed", "");
if (channel != originalChannel) {
  while (true) {
    prompt("No remixes.");

For Game Lab:

var channel = window.getURLPath()[2];
var originalChannel = "(channel id of the original app)";
if (channel != originalChannel) {
  while (true) {
    prompt("No remixes.");

Put this in a library or some arbitrary point in the code.

It doesn’t seem to work for the game lab one. May you help me?

You can get the channel ID of a game by taking the url and copying the long gibberish after Make sure you remove /edit or /view as well.

I did that before you replied, but it just won’t work.

Great code, but isn’t there a chance that the remixer could just delete that code or remove the library?

Here is a solution I found:

You could extract the embed?nosource url of the project (from the iframe provided by embed option) and write some code in another project the opens this url. Then you can publish this project, and it won’t matter if people remix it because all remixes will lead to the same project anyway.

Also, another way to protect your project from its code being viewed and thus getting remixed, is storing all the code in a data table. Then write something that will read the code inside the table and run it. Remixed versions don’t have the same tables so they won’t see the code of the original project.

If your code is too large, though, you might have to separate it into pieces and eval() them individually.

See the first solution here

The problem with data tables is that they can be hacked quite easily (and also can’t be used in Game Lab). Storing code in data tables allows hackers to easily change how your app works and can allow them to execute malicious code (such as password stealing, showing grabify images, etc.)

1 Like

They can be hacked?!

Then it can be stored in key/value pairs. Or can key/value pairs also be hacked?

Those can be hacked as well, unfortunately.

That’s really disappointing :slightly_frowning_face: