HTML Web App Wrappers / Phonegap Alternatives

[SW6]

Hello,

New around here, first post....

To be brief, I'm looking for recommendations for native app wrappers for html5 games along the lines of PhoneGap / Cordova (which I've used) that do more to protect your game's source code and assets. Phonegap currently provides zero protection. The apk can be unzipped an everything is right there.

Does something like this exist? Maybe something that will compile or encode your wrapped assets?

Thanks!!

[mattstyles]

No, JS engines employ just in time compilation, i.e. they do it on the client. There are a couple of projects that can compile a binary from node source but they don't tend to work seamlessly and I haven't heard of any way to do this to punt stuff out mobiles know how to run.

[ivanix]

My 2 centavos,

Trying to stop code and asset theft is like prohibiting drinking and prostitution.  About the only thing you can count on is that most thieves are lazy so they will search for the lowest hanging fruit.

As a developer, there is two types of theft I would worry about. First one is they steal the graphic assets for use in their own game. Second is they simply relabel my app or game as theirs and take all the credit. 

If you can somehow encrypt just the graphics or spritesheets, then you can put up a little barrier for both situations. 

CodeAndWeb's TexturePacker can encrypt sprites heets which can be decoded by Cocos2d.  I am not sure why they don't have a JS decoder for HTML5 games, but it should be feasible.  Disclaimer: I have not used their product yet, but looks promising. I will follow up someday on this.

https://www.codeandweb.com/texturepacker/contentprotection

Another simple way to encrypt your sprite sheets is load them into canvas, then use the same techniques used for picture puzzles to cut out and scramble the pieces. Save the scrambled version as a static image that will be found in the assets folder.  The puzzle code will have info to put the pieces back in their original position and orientation, this info will be the decoding key.

The decoding key should not be included in the app itself. It should be retrieved from your server at runtime, preferably after the user/player has logged in using some time of trackable authentication i.e. social login.

That's the basics, but let's extend it a little further.  Think about excluding some of the puzzle pieces from the static file, which can only be retrieved from the server after the player authenticates and gets the decoding key.  When the app retrieves the missing tiles from your server.  You can have your server "watermark" the missing tiles using the decoderkey + the social id.

In that way,  when the time comes that you find your sprite sheets out on the internet,  you have some chance of tracing down who was the one leaking them.

 

 

 

 

 

 

 

[symof]

I would only worry about asset theft once that actually happens. If you're a small indy guy/girl then adding encryption to your files on the off-chance that someone might steal your stuff is nonsense, and adds to code complexity.

My first priority would be coding the complete game in a manageable time-frame, and then marketing.

By far the biggest hurdle, that I think indy devs have, is the marketing part, since from the onset this is a market PUSH from you to try selling it to someone that does not need it, or simply having someone play a game that you liked making. A market PULL would be when there is already an existing DEMAND for you game such as gold/platinum versions or sequels of the game.

As for using a native wrapper... You are again over-complicating things. And I will explain why.

 

The current direction of HTML5 on Android devices is to create Cloud Apps that can be linked into the Home Screen without downloading resources on the client device(no more then a JIT Browser would download during web browsing). You can read more on this from the google chrome dev pages at https://developer.chrome.com/multidevice/android/installtohomescreen

Now what this means is that you would no longer require a wrapper at all, since any HTML5 App that is distributed in the cloud will be available from the home screen. What this means in turn is that all your assets will initially be hosted on your webserver then sent to the client, so your full source code will no longer be available for download and disassembly, however disassembly will happen regardless of the amount of protections you put in place. What you are doing in essence is making it harder for someone that does not have sufficient experience to just copy-paste your full app and distribute it as their own.

So in the case of clouds apps and current development direction your best bet at hindering the copying process or re-host of files is to either do a urlencode for the assets that you use so that it is only available from the app.

OR

Use .htaccess to hinder direct links such as

http://stackoverflow.com/questions/7127153/php-how-can-i-block-direct-url-access-to-a-file-but-still-allow-it-to-be-downl

https://docs.joomla.org/How_do_you_block_direct_hot_linking_to_image_files_using_htaccess%3F

 

OR

My personal favorite. URL locking.

if(document.URL.indexOf("domain.tld") != -1) {
    //found
} else {
    //nope
} 

This checks if the string "domain.tld" exists in the current URL address bar. And then does stuff based on that. So you could redirect it to your homepage if the script is not on your website. Or maybe write an alert.

I wrote this handy fiddle for a more in-depth example:

https://jsfiddle.net/Lnbos3ns/

 

Frankly I wouldn't bother with any of these unless you actually find yourself in the position of losing revenue due to stealing. I personally have not yet done this for the apps that I have published, nor do I intend to do so, unless it becomes a genuine issue such as potential bandwidth theft, or hogging resources, that raises the cost for me.

 

Hope this helps.