Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
twine 2: how to publish story as HTML such that the html file cannot be loaded in twine by anyone
I know preventing an HTML file to be viewed is a very cumbersome and unreliable.
I am creating simulations as a tool to facilitate classroom training. This is paid. I dont want my corporate users to save the HTML file on their machine and figure out that it is created in twine, and then open it in twine and start customizing it and using it for long term and thus exclude me from the process.
How can I publish the story as HTML file such that this published html file cannot be opened in twine. So essentially stripping out the twine metadata.
Please help.
I am creating simulations as a tool to facilitate classroom training. This is paid. I dont want my corporate users to save the HTML file on their machine and figure out that it is created in twine, and then open it in twine and start customizing it and using it for long term and thus exclude me from the process.
How can I publish the story as HTML file such that this published html file cannot be opened in twine. So essentially stripping out the twine metadata.
Please help.
Comments
Like most HTML/Javascript single file web-applications, if you allow the end-user access to the file then they also have access to the source code.
You have a number of options:
1. Use a license / contract to restrict what the end-user is allowed to do to the application.
2. Convert the Story HTML file into a different type of application.
This can be done using a tool like NW.js / node-webkit which packages the Story HTML file within a PAK file that is access via an executable. The PAK files is basically an archive file which the end-user can still open to access the HTML source code, although some have stated that it can be encrypted but I have found no documentation explaining that feature.
3. Don't build your application using HTML/Javascript based technologies.
I encrypted the following twine story to demonstrate.
https://www.dropbox.com/s/iynih40xcosyig1/app.exe?dl=1
I didn't package all the needed nw.js files with it so it won't run on double click unless you put it in the same directory as a nw.js download from http://nwjs.io/ . It's just the default Twine story - if you want to confirm it works, download a version of nw.js, copy app.exe into the nw.js extracted directory and run app.exe. However, trying to read the html file inside app.exe should be restricted.
To do this you need to to run them through Unity using Cradle: https://github.com/daterre/Cradle
Cradle takes Twine stories and converts them into Unity script. You can then publish them with unity back into HTML5 to make an online file that probably cannot be fed back into Twine. I haven't tested it, but I doubt Twine could read the output once it's been put through Unity, since Unity has its own compilation process to make HTML5 games.
Alternatively, you can also make a native downloadable app that has whatever encryption Unity uses.
The drawback to this is you need to learn a bit about Unity to make the game, as it doesn't simply emulate Twine, but rather converts it to a format that can be used in conjunction with Unity scripts.
As an example you can pre-jit-compile the byte-code used in a NW.js project for a particular chip-set which makes the result very difficult to reverse engineer but doing so can have the side-effect of slowing the running of the application down, so the added security comes with the cost of a slower running application.
The PAK file will need to be decrypted (into memory/temporary storage) by the executable at run-time so that it can access and run the HTML code within it.
I'm not entirely sure how it works, and it likely has limitations. However, no security is 100% perfect, so I'm just happy to be able to protect against casual copying.
I find it more likely that you're not actually doing what you think you're doing. I'm not trying to be insulting, but what you're describing is literally magic.
Case in point, the example app.exe you posted does not run/show your test.html. It only shows the default, application-less NW.js window. It's also mispackaged, so even if NW.js could decrypt the files, it wouldn't work anyway—the package.json must be in the root of the package, your example's is in the test subdirectory.
Just to be sure NW.js isn't doing something magical, however, I tested an encrypted archive and NW.js was not able to decrypt the package files, as expected. (Note: You must be careful to ensure that you do not leave any of the unencrypted package files loose were NW.js might find them. This is extremely important as NW.js tries very hard to find a valid package manifest. Even if you explicitly specify a package, manually or bundled within the executable, if it doesn't find a valid manifest within those locations it will scan its local directory for one. If it does find one, then it will run it—without even complaining about the missing manifests in the other locations.)
Once you've ensured that NW.js cannot find a package other than the specific one you specify, if you run nw.exe on an encrypted ZIP archive manually: You should receive an error complaining about a missing manifest—since it was not able to successfully extract package.json.
In the same vein, if you run a bundled app—i.e. you've appended the encrypted ZIP archive to nw.exe: You should get an application-less NW.js window—i.e. a window showing the default NW.js page with NW.js build info in the bottom right corner. This is because it could not retrieve a valid manifest from the ZIP appended to the executable, so it assumes there simply wasn't one. You only get the missing manifest error if you specify a package manually.
PS: Again, I'm not trying to be insulting. However, you simply cannot be doing what it is that you think you are.
PPS: You're also including several files in the application package that don't belong in there—i.e. icudtl.dat, nw.pak, nw_100_percent.pak, nw_200_percent.pak, nw_elf.dll, nw_material_100_percent.pak, nw_material_200_percent.pak. Some of them should be part of your distribution, but they shouldn't be part of the application package.
As an alternative, you can wrap a nw.js exe in an Enigma Virtual Box.http://enigmaprotector.com/ (the nw.js website even describes the process)
You might be able to use that to protect the exe.
You can still obfuscate the html file if you need a bit of a hurdle.
And as far as hardcore crowd goes, I'd say that most indie developers shouldn't waste time trying to thwart them, as it's a waste of your time, energy, and resources—you're never going to stop them anyway and are unlikely to slow them down much without spending far more money than you probably have available.