Hide source code possibility

[darky]

I mean about executable container, which not allow to show source code.
Not offer obfuscation

[Mithgol]

The users will have that container and the open source decoder (which is node-webkit) and the key (if there is a key), because node-webkit needs to open that container somehow (in order to execute its contents).

How do you expect the container's contents to remain concealed then?

[aesposit]

@Mithgol
My suggestion is to add the capability to compile the js&css files in the exe executable as embedded resources and then use them internally as custom NWURL.
Something similar to this : http://www.developer.nokia.com/Community/Wiki/How_to_Embed_Resources_in_the_Application_Executable

[graphnode]

My suggestion is to add the capability to compile the js&css files in the exe executable as embedded resources and then use them internally as custom NWURL.

Aren't executable resources even easier to read than just appending a zip file to node-webkit like it happens in the Windows deploy?

[aesposit]

@graphnode
the problem is that the zip file is extracted in the temp dir and so easily readable.
BTW if you have hackers cracking your apps probably nothing can stop them.
What I would like to achieve is making hard (not impossible) to see my code.
I am trying to use this process in Windows:

1. Encrypt your js resources with a unique desktop key (I use node-ffi with a HW HD serial number dll)
2. Embed those resources in the exe (normal users don't know that)
3. Launch the exe and it internally in memory decrypt/loads the resources in the nw browser/node context

Any suggestion is welcome

[darky]

I front-end dev and don't want to show my source (HTML/CSS/JS) customers up to get money.
But they want to see state of project and I have next idea: to give customes special build of node-webkit (Windows) with next features:

1. without toolbar, plugins, e. t. c. superfluous...
2. open my server resource by https
3. with special user-agent password, which checked by server

How to create this build:

1. Build node-webkit master branch with features
2. Use Visual Basic Script:
   CreateObject("Wscript.Shell").Run 'nw.exe --no-toolbar --url="https://my-server.herokuapp.com" --user-agent="lhMf4Tct78ro08r74hUTR88bJ258FI" '
   This script exported in exe with ExeScript for example

[rogerwang]

It should be possible to 'protect' the JS code with something based on v8 snapshot. We'll see this feature, but some contract is still suggested to protect your IP by law.

I can see a standalone tool to compile the code into v8 snapshot and the support in node-webkit to load them on start.

[nprbst]

+1 for V8 snapshot support!

[robgrz]

I understand that this would just be an annoyance for someone who is truly dedicated to getting your code/source or copying the program but it would be a major roadblock for many people.

It would be a big benefit for some of the applications we've been looking at using node-webkit for.

+1 for me

[rogerwang]

Please see the document here:

https://github.com/rogerwang/node-webkit/wiki/Protect-JavaScript-source-code-with-v8-snapshot

Comments are welcome.

[rogerwang]

This feature was just released with 0.4.2.

[dubcanada]

@rogerwang may I ask why it is limited to such a low amount? If it's based off V8 and using a heap snapshot should it not be limited to maximum heap snapshot size (256mb?)?

[rogerwang]

@dubcanada it's not a hard limit and can be fixed. The reason of the current limitation is that the objects or code has to be in the same page when deserializing.

[kevsmt]

We are looking to use node-webkit on a application, which by nature requires the codes (some) to be compiled, specially authentication of the product limitations, etc. From the wiki; "snapshot": "mysnapshot.bin" I assume only 1 bin file? can this be "snapshot": [ "a.bin", "b.bin" ] ? and what does ~30% slower mean, assuming, the compiled js only returns js code computations or the js also touches ui staff? and the compile js can also access nodejs.require?

[changtimwu]

@rogerwang
Wow! Your commit is surprisingly short.

I'd like to add such a feature to off-the-shelf command line nodejs executive so I can launch node with snapshot this way.

node -snapshot snapshot.bin

According to your patch, it seems that V8::Initialize can accept a snapshot binary stream as parameter.

Besides loading the snapshot binary file and pass it to where nodejs initialize v8 instance, is there anything I need to take care?

[frankhale]

I'm thinking of migrating an intranet web application off the server and rewriting it for node-webkit. Given the baggage/limitations of nwsnapshot and the fact that anyone can read and or modify the code, how are you guys dealing with database authentication and such that requires usernames/passwords? I suppose doing something like this would also entail wrapping database access into a set of web services (and those would have to live on a server somewhere). Then the node-webkit app uses an API key assigned to each user or something to gain access.

[jtenner]

@frankhale Hosting the solution on IIS for an intranet application on a domain was a perfect solution for me.

The login popup uses windows authentication and it worked perfectly.

I don't know what your solution needs to look like though.

[szwacz]

@frankhale everything what is on client machine should be by definition considered untrusted. Making desktop application is nothing different in that matter, so all your sensitive data should stay on server.

[frankhale]

Windows authentication would certainly work and that is how it's currently
being done. There are actually no usernames/passwords floating around as
it's all client certificate based. I'm just trying to figure out the best
avenue of approach in order to move the traditional web application pieces
to a node-webkit client side application and how best to eliminate the need
for resources on the web server.. So I suppose a small authentication piece
on the webserver combined with web services for the database access would
be the simplest route. Additionally a mechanism for auto-updating the
client side code.

On Wed, Nov 20, 2013 at 1:46 PM, Jakub Szwacz notifications@gh.neting.ccwrote:

@frankhale https://github.com/frankhale everything what is on client
machine should be by definition considered untrusted. Making desktop
application is nothing different in that matter, so all your sensitive data
should stay on server.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/269#issuecomment-28916542
.

[sesteel]

I am wondering why the code runs slower. Could anybody offer an explanation?

[petejkim]

This just provides a false sense of security. I could see the full source code using the Dev Tools after loading the snapshot.bin file.

We should just accept the fact that there's no reliable way of protecting JS source code. /cc @rogerwang

[rogerwang]

@petejkim there is a bug introduced in 0.8.0 which makes the source code exposed. Could you please try again with 0.7.4?

[darsain]

I am wondering why the code runs slower. Could anybody offer an explanation?

I'd also want to know. From my limited point of view, the snapshot should save loading time, as stuff doesn't need to be loaded individually and interpreted anymore, and run equally fast when loaded. But I have no idea how this actually works... so why is it 30% slower? And can anything be done about it?

I'm actually not that interested in hiding the source code, but instead this seems like a nice way how to put all stuff into one nice bin file and not have it scattered everywhere, or in need of unpacking into tmp folder and running from there. This looks like the nicest way how to package apps, no?

[CosmoMyzrailGorynych]

The temp folder of node-webkit application may have own access policies which deny any access to the user, like Windows 8 Metro-applications do.
Also it would be cool if app.nw could be protected by password which is stored directly in app.nw.

EDIT
I'm gonna use such a snippet until any alternatives appear. It simply clears some scripts in temp folder as they're cached in webkit and thus not necessary to remain in fs.

temp_folder = process.cwd();
/* lots of code go there */
$(function () {
    if(temp_folder.indexOf('Temp/nw') != -1)
      fs.readdir(temp_folder, function (err, files) {
        if (err) console.log(err);
        else {
          for (i = 0; i < files.length; i ++) {
            if (files[i].indexOf('.js') || files[i].indexOf('.html') || files[i].indexOf('.css'))
            fs.unlink(temp_folder + '\\' + files[i], function () {
              void(0);
            })
          }
        }
      });
  });

Be careful: I occasionly killed all my code this way one day :[ Better create a copy before trying.

[rogerwang]

@darsain the code run slower because it's compiled with the slower compiler in v8. The other (faster) one needs runtime profiling data to do better optimizations.

[cyrusdavid]

I tried using enigma virtualbox for the hope of that but there are still nw* forders popping up on the temp folder. I'm hopeful there would be a solution to this soon ❤️ Well aside from the slower compiled code.

[hashseed]

Also: igorklopov/enclose#9

[namaljayathunga]

How can I hide toolbar programmatically?

[ColonelBundy]

@namaljayathunga check the wiki.

[rohan-deshpande]

Chiming in on this topic as it's pretty interesting for me. I'm developing a (hopefully) closed source game engine with JavaScript and NodeWebkit (I'm still on v0.10.5). Is it necessary to do a v8 snapshot of the entire codebase, or can you say, compile your own code this way but load other, open source libraries the regular way so that they get optimisation benefits?

For example, I have all my proprietary code concatenated to game.js, however the libraries that I use are inside of vendor.js. Can the snapshot somehow run the vendor code normally and run the snapshot of the game code or is this an "all or nothing" situation?

[hashseed]

Having a custom snapshot does not affect other parts of V8, including compiling and running scripts. So your game.js can be included in the snapshot, but vendor.js does not need to be.

However, V8 snapshot is not designed to hide source code. Chances are that the source of game.js will be serialized into the snapshot as well. Extracting it from the snapshot would be fairly easy.

[rohan-deshpande]

Ah right that's good to know, but as per #269 (comment), doesn't the recompilation avoidance stop the source code from being exposed or am I misunderstanding?

[hashseed]

Well you could definitely hack V8 to drop the source code, and make sure it's not used for display or recompilation, but V8 does not support this out of the box. Unfortunately I don't know whether nw.js has patched V8 to do that.

[rogerwang]

@hashseed @rohan-deshpande yeah, NW supports dropping source code for source code protection, check http://docs.nwjs.io/en/latest/For%20Users/Advanced/Protect%20JavaScript%20Source%20Code/

[rohan-deshpande]

Thanks @rogerwang, so let's take my example (#269 (comment)), if you used the source code protection for game.js but not for vendor.js would you only see speed reductions in game.js code and not vendor.js code?

[rogerwang]

@rohan-deshpande the document said this clearly: "The compiled code runs slower than normal JS: ~30% performance according to v8bench. Other non-compiled JS source code will not be affected."

[rohan-deshpande]

Cool! Yes I read that just wondering if I read it correctly or not. Thanks for clearing it up :)

[hashseed]

@rogerwang you could give this a try: run V8 with --ignition --turbo. That forces V8 to use a different compiling pipeline. Ignition is our upcoming interpreter that compiles source to bytecode. We can then optimize from bytecode directly without having to parse from source.

[rogerwang]

@hashseed great! will try.

[danschumann]

Are there any issues with source code protection mentioned here? http://docs.nwjs.io/en/latest/For%20Users/Advanced/Protect%20JavaScript%20Source%20Code/

I know a previous version had a bug and I'm wondering if my source code would be totally protected.

[rogerwang]

@danschumann no there is no issues.

[alphasdev]

How reliable this way to protect source code now? Is it possible to crack the javascript source code now (last ver nwjs 0.20.1)?

[baconbrad]

@alphasdev How reliable this way to protect source code now? Is it possible to crack the javascript source code now (last ver nwjs & chromium)?

Refer to the two comments above yours.

[darkguy2008]

Haha, come on, if he'd release the source code, alphasdev and all of us would be able to know. What is the point of publishing something on GitHub if you are not going to use it for SOURCE CODE ? It's not a file hosting ffs.

[alphasdev]

@darkguy2008, off topic.

[darkguy2008]

That's not offtopic, we're talking about the code protection which we can't see if the source code is not published. It's pretty on-topic for me.

[baconbrad]

That's not offtopic, we're talking about the code protection which we can't see if the source code is not published. It's pretty on-topic for me.

I cannot see how someone's opinion on GitHub's purpose pertains to or aids this discussion/issue.

[darkguy2008]

Ah crap, my bad, I thought this was about that other side-project which uses nw.js and claims to be able to hide the source code but he never releases the source code because he's a jerk. Sorry about all the offtopic xD

[hashseed]

This should become possible soon. V8 is going to switch to a bytecode interpreter and the new optimizing compiler in the next few months. Once that's done, V8 will no longer need the source code, if everything is compiled to bytecode ahead of time.

[danschumann]

@hashseed isn't this topic about a similar method of protection? I open up the .bin files with a hex editor and I see a few recognizable names, including strings, but isn't the rest already some sort of byte code which cannot be turned back into readable javascript?

You're just saying that they're adding it to the core V8, including web browsers soon, right?

[jportoles]

@danschumann the issue is that currently, in order to compile to a native V8 snapshot, run time V8 optimizations have to be sacrificed, and hence the code ends up being 30-50% slower. A bytecode compiler/interpreter would solve this problem by natively supporting compiled javascript while still being able to do run time optimizations. Thus it would be a win-win for NW.js to adopt this method of compilation vs the existing one, once @hashseed and their team get their implementation ready.

[hashseed]

Currently, V8 needs to include the source string for the functions it includes in the snapshot. Otherwise it cannot recompile these functions to optimized code. Afaik nw.js includes a hack to remove the source string to obscure it, but that prevents optimization.

V8 will soon move to a compiler pipeline that does not need the source string to recompile to optimized code anymore. So for these, we could introduce a new option to eagerly compile functions to include the bytecode in the snapshot, and in return be able to drop the source string.

[rogerwang]

Happy to announce that it's fixed finally, source code protection performance vastly improved: https://nwjs.io/blog/js-src-protect-perf/

[f3l1x]

@rogerwang Good job man.

[ghost]

I am very late here, but @rogerwang my biggest respect - thank you very much!