New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Source Code Protection #3041

Closed
Penagwin opened this Issue Oct 9, 2015 · 28 comments

Comments

Projects
None yet
@Penagwin

Penagwin commented Oct 9, 2015

It appears to have been a while since the last discussions on source code protection with snapshots. NW.js and enclosejs have found ways to do snapshots without including the source code. I was wondering if this could be looked at again, thank you!

@zcbenz

This comment has been minimized.

Show comment
Hide comment
@zcbenz

zcbenz Oct 9, 2015

Contributor

NW.js and enclosejs are using the same technology to implement source code protection, by compiling JavaScript code into V8's snapshot code and force turning off optimization. This method sacrificed performance greatly, simple benchmark shows ~50% speed down, but considering the various optimizations done by V8, the performance of real apps will be much worse.

And V8 never has plan of providing source code protection, so this situation won't change in future. On Electron's side we don't want to sacrifice performance for source code protection, and I'm closing this as won't fix.

Refs #2570, #169 (comment).

Contributor

zcbenz commented Oct 9, 2015

NW.js and enclosejs are using the same technology to implement source code protection, by compiling JavaScript code into V8's snapshot code and force turning off optimization. This method sacrificed performance greatly, simple benchmark shows ~50% speed down, but considering the various optimizations done by V8, the performance of real apps will be much worse.

And V8 never has plan of providing source code protection, so this situation won't change in future. On Electron's side we don't want to sacrifice performance for source code protection, and I'm closing this as won't fix.

Refs #2570, #169 (comment).

@etiktin

This comment has been minimized.

Show comment
Hide comment
@etiktin

etiktin Oct 9, 2015

Contributor

I don't think that performance is really an issue for the majority of applications that might need source code protection. From a quick look at nw.js issues, it doesn't seem that most users of this feature are complaining about the performance, so I guess it's good enough.
The feature should be configurable so it won't hurt the performance of regular applications.

Many companies that create paid applications for corporate or consumers want source code protection so they can protect their IP. Some might even be obligated to do that according to their contracts. For them, Electron is a non-starter. So by not offering this feature we're limiting our user base.
I'm aware that they can protect the sensitive code in a native addon, but I think most of our users choose to use Electron, because they want to write applications using web technologies and not mess around with low level C++.

Is there some other way we can offer source code protection in Electron? Maybe we can offer some build script that will block devtools and remote debugging. The script can also encrypt each file in app.asar (but we'll need a safe way to store the decryption password in the code).

@zcbenz, can you reconsider?

Contributor

etiktin commented Oct 9, 2015

I don't think that performance is really an issue for the majority of applications that might need source code protection. From a quick look at nw.js issues, it doesn't seem that most users of this feature are complaining about the performance, so I guess it's good enough.
The feature should be configurable so it won't hurt the performance of regular applications.

Many companies that create paid applications for corporate or consumers want source code protection so they can protect their IP. Some might even be obligated to do that according to their contracts. For them, Electron is a non-starter. So by not offering this feature we're limiting our user base.
I'm aware that they can protect the sensitive code in a native addon, but I think most of our users choose to use Electron, because they want to write applications using web technologies and not mess around with low level C++.

Is there some other way we can offer source code protection in Electron? Maybe we can offer some build script that will block devtools and remote debugging. The script can also encrypt each file in app.asar (but we'll need a safe way to store the decryption password in the code).

@zcbenz, can you reconsider?

@paulcbetts

This comment has been minimized.

Show comment
Hide comment
@paulcbetts

paulcbetts Oct 9, 2015

Contributor

Maybe we can offer some build script that will block devtools and remote debugging.

This should be easy to do, just don't add a menu item for it, no?

I'm also 👎 on this feature, web technology is just not an appropriate software choice if you need to give your software to customers but ensure they never read it. Snapshots are generated by V8, which means its format is documented - this isn't "protection".

Contributor

paulcbetts commented Oct 9, 2015

Maybe we can offer some build script that will block devtools and remote debugging.

This should be easy to do, just don't add a menu item for it, no?

I'm also 👎 on this feature, web technology is just not an appropriate software choice if you need to give your software to customers but ensure they never read it. Snapshots are generated by V8, which means its format is documented - this isn't "protection".

@etiktin

This comment has been minimized.

Show comment
Hide comment
@etiktin

etiktin Oct 9, 2015

Contributor

This should be easy to do, just don't add a menu item for it, no?

I think it's more complicated than that, since we support Chromium's command line arguments. So even if we don't include a devtools shortcut, you can still pass the --remote-debugging-port=8315 and access the decrypted source through http://localhost:8315.

Snapshots are generated by V8, which means its format is documented - this isn't "protection".

From what I understand, this is not the case. The snapshot is made by running the code through v8 and then taking a snapshot of the heap (reversing that is pretty much like reversing native code). The "problem" is that it also saves the source code in the snapshot so it can do some optimizations during the run. What nw.js and EncloseJS apparently do is to remove that source code and make sure that v8 is ok with that.

web technology is just not an appropriate software choice if you need to give your software to customers but ensure they never read it.

Web technologies were also considered not appropriate for making desktop apps (Electron, nw.js, Chrome apps), server side apps (Node.js), mobile apps (Cordova, React native) and IoT (IoT.js), but people are still using it for that. The amount of innovation that is happening with web technologies is unparalleled, so naturally, makers of propriety applications don't want to be left behind and are interested in using them.
It would have been one thing if no one has done it before, and then we could of said, "well we don't even know if it's possible...", but that's not the case.
We can either find some way to support it, or tell folks: "Use nw.js instead". I think it's better to see if we can support it (one way or another). I want more enterprise developers to use it, because it would strengthen the community (bug fixes, popularity etc.).

Contributor

etiktin commented Oct 9, 2015

This should be easy to do, just don't add a menu item for it, no?

I think it's more complicated than that, since we support Chromium's command line arguments. So even if we don't include a devtools shortcut, you can still pass the --remote-debugging-port=8315 and access the decrypted source through http://localhost:8315.

Snapshots are generated by V8, which means its format is documented - this isn't "protection".

From what I understand, this is not the case. The snapshot is made by running the code through v8 and then taking a snapshot of the heap (reversing that is pretty much like reversing native code). The "problem" is that it also saves the source code in the snapshot so it can do some optimizations during the run. What nw.js and EncloseJS apparently do is to remove that source code and make sure that v8 is ok with that.

web technology is just not an appropriate software choice if you need to give your software to customers but ensure they never read it.

Web technologies were also considered not appropriate for making desktop apps (Electron, nw.js, Chrome apps), server side apps (Node.js), mobile apps (Cordova, React native) and IoT (IoT.js), but people are still using it for that. The amount of innovation that is happening with web technologies is unparalleled, so naturally, makers of propriety applications don't want to be left behind and are interested in using them.
It would have been one thing if no one has done it before, and then we could of said, "well we don't even know if it's possible...", but that's not the case.
We can either find some way to support it, or tell folks: "Use nw.js instead". I think it's better to see if we can support it (one way or another). I want more enterprise developers to use it, because it would strengthen the community (bug fixes, popularity etc.).

@zcbenz

This comment has been minimized.

Show comment
Hide comment
@zcbenz

zcbenz Oct 10, 2015

Contributor

Having a good solution for source code protection is cool and probably necessary for certain commercial softwares, but we don't have such plan in Electron, and apparently all major users of Electron don't have needs for that.

If someone has worked out a solution for source code protection and wants to contribute it back to Electron, we will be happy to accept that, but at least for now we don't have any interest to work on that.

Also a decent way to implement source code protection is probably to work out a solution in V8 first, patching V8 is a maintenance hell and source of bugs.

Contributor

zcbenz commented Oct 10, 2015

Having a good solution for source code protection is cool and probably necessary for certain commercial softwares, but we don't have such plan in Electron, and apparently all major users of Electron don't have needs for that.

If someone has worked out a solution for source code protection and wants to contribute it back to Electron, we will be happy to accept that, but at least for now we don't have any interest to work on that.

Also a decent way to implement source code protection is probably to work out a solution in V8 first, patching V8 is a maintenance hell and source of bugs.

@clintwood

This comment has been minimized.

Show comment
Hide comment
@clintwood

clintwood Oct 10, 2015

FWIW, I've switched to Electron from nw.js. The way I packaged my nw.js app for desktop was using the free Enigma Virtual Box which worked well and gave some protection. Unfortunately Enigma doesn't seem to work with Electron for me (more investigation to be done to identify why) and would definitely be my preferred choice over seeing Electron compromised from a performance point of view.

clintwood commented Oct 10, 2015

FWIW, I've switched to Electron from nw.js. The way I packaged my nw.js app for desktop was using the free Enigma Virtual Box which worked well and gave some protection. Unfortunately Enigma doesn't seem to work with Electron for me (more investigation to be done to identify why) and would definitely be my preferred choice over seeing Electron compromised from a performance point of view.

@etiktin

This comment has been minimized.

Show comment
Hide comment
@etiktin

etiktin Oct 10, 2015

Contributor

We use EVB for certain projects (unrelated to Electron), but it doesn't provide source code protection. If you don't set compression the code is readable in the executable and if you do it's still pretty easy to extract (it's not encrypted). In any case, the source is still readable through remote debugging.

EVB does work with Electron at least for some folks (see #1094). The only problems I saw with EVB in the past was some false positives from certain anti-virus apps (only happened when extracting dlls to tmp, but you can instruct it not to do that) and when trying to hook the output executable using some ancient methods.
Using EVB does hurt performance on process startup, but usually it's barely noticeable.

Contributor

etiktin commented Oct 10, 2015

We use EVB for certain projects (unrelated to Electron), but it doesn't provide source code protection. If you don't set compression the code is readable in the executable and if you do it's still pretty easy to extract (it's not encrypted). In any case, the source is still readable through remote debugging.

EVB does work with Electron at least for some folks (see #1094). The only problems I saw with EVB in the past was some false positives from certain anti-virus apps (only happened when extracting dlls to tmp, but you can instruct it not to do that) and when trying to hook the output executable using some ancient methods.
Using EVB does hurt performance on process startup, but usually it's barely noticeable.

@clintwood

This comment has been minimized.

Show comment
Hide comment
@clintwood

clintwood Oct 10, 2015

@etiktin, you are correct, hence the 'some protection'. Their 'Enigma Protector' paid for product does appear to offer protection in conjunction with EVB. I guess I'm just pointing out an alternative way to gain some protection.

clintwood commented Oct 10, 2015

@etiktin, you are correct, hence the 'some protection'. Their 'Enigma Protector' paid for product does appear to offer protection in conjunction with EVB. I guess I'm just pointing out an alternative way to gain some protection.

@etiktin

This comment has been minimized.

Show comment
Hide comment
@etiktin

etiktin Oct 10, 2015

Contributor

Enigma Protector does offer some more serious mechanisms to protect IP, but users that are allowed to use it (e.g. they have the password) can use Electron's remote debugging and get the source.
Thanks for pointing it out though. I was just trying to inform potential users of the limitations.

Contributor

etiktin commented Oct 10, 2015

Enigma Protector does offer some more serious mechanisms to protect IP, but users that are allowed to use it (e.g. they have the password) can use Electron's remote debugging and get the source.
Thanks for pointing it out though. I was just trying to inform potential users of the limitations.

@polarathene

This comment has been minimized.

Show comment
Hide comment
@polarathene

polarathene Oct 13, 2015

apparently all major users of Electron don't have needs for that.

That's not really a good metric? You could have other potential major users of Electron, yet they didn't adopt Electron due to the lack of source code protection. Sorta like a burger joint saying all their customers are happy eating meat burgers and don't have interest in burgers for vegans, so that market is completely ignored, the vegans might have happily became customers to the burger joint if they were catered for, instead of voicing interest in vegan burgers they find a burger joint that caters to vegans instead.

I've had an enterprise client for a project in the past but the lack of source protection with Electron put them off it, which is unfortunate since I quite like Electron :(

polarathene commented Oct 13, 2015

apparently all major users of Electron don't have needs for that.

That's not really a good metric? You could have other potential major users of Electron, yet they didn't adopt Electron due to the lack of source code protection. Sorta like a burger joint saying all their customers are happy eating meat burgers and don't have interest in burgers for vegans, so that market is completely ignored, the vegans might have happily became customers to the burger joint if they were catered for, instead of voicing interest in vegan burgers they find a burger joint that caters to vegans instead.

I've had an enterprise client for a project in the past but the lack of source protection with Electron put them off it, which is unfortunate since I quite like Electron :(

@clintwood

This comment has been minimized.

Show comment
Hide comment
@clintwood

clintwood Oct 13, 2015

@polarathene, 100%! In my case I'm deploying apps into large public sector clients who want the source protected for security reasons to prevent hacking on sensitive data - in this case not an IP related issue but more security related.

clintwood commented Oct 13, 2015

@polarathene, 100%! In my case I'm deploying apps into large public sector clients who want the source protected for security reasons to prevent hacking on sensitive data - in this case not an IP related issue but more security related.

@wolftune

This comment has been minimized.

Show comment
Hide comment
@wolftune

wolftune Oct 16, 2015

The accurate term here is "restriction" not "protection". As in "want the source restricted". Everyone who wants to do this can keep doing it and just describe it more clearly. Cheers.

wolftune commented Oct 16, 2015

The accurate term here is "restriction" not "protection". As in "want the source restricted". Everyone who wants to do this can keep doing it and just describe it more clearly. Cheers.

@arthurakay

This comment has been minimized.

Show comment
Hide comment
@arthurakay

arthurakay Oct 22, 2015

I realize I'm late the party here, but I wanted to add my $0.02

Having a good solution for source code protection is cool and probably necessary for certain commercial softwares, but we don't have such plan in Electron, and apparently all major users of Electron don't have needs for that.

IMO that's a bit of a co-out answer, particularly the "all major users... don't have needs for that". I think the reality is far closer to "all major users... are trying to find an answer for this, but have stopped asking because they see it's not a priority for the dev team". It's perhaps the only reason why anyone would pick nw.js over Electron at this point (my opinion, anyhow).

I realize this is a free and open-source project, but let's not pretend that security isn't something everyone should care about. Whether-or-not the source code is proprietary is irrelevant, security should be a priority.

We have looked at tools like enclose, jxcore and others extensively -- and one of my major beefs right now is that while they "work" inside Electron, I can't wrap the runtime node modules (e.g. browser-window) into the snapshot/build/whatever-you-call-them.

On Electron's side we don't want to sacrifice performance for source code protection

I don't think anyone is asking Electron to sacrifice performance, but that's a trade-off many of us are willing to make on our own code. Even in nw.js the "snapshot" isn't (always) the entire project -- it's a subset of the JS code chosen by the developer.

I'm also 👎 on this feature, web technology is just not an appropriate software choice if you need to give your software to customers but ensure they never read it. Snapshots are generated by V8, which means its format is documented - this isn't "protection".

Combined with the existing .asar format, uglify and other methods of "security through frustration" would give most companies the satisfaction of saying "our code isn't in clear text files". It may not be encrypted and safe from NSA snooping, but I don't think that is an expectation anyone has (or at least me).

Case and point: nw.js is "good enough" for most people, even though I'm sure it's "security" is far from robust.


You guys are killing things with Electron! This project is amazing, and we really appreciate the work you are putting into it -- but I really think it's misguided to dismiss this option as something people don't want.

arthurakay commented Oct 22, 2015

I realize I'm late the party here, but I wanted to add my $0.02

Having a good solution for source code protection is cool and probably necessary for certain commercial softwares, but we don't have such plan in Electron, and apparently all major users of Electron don't have needs for that.

IMO that's a bit of a co-out answer, particularly the "all major users... don't have needs for that". I think the reality is far closer to "all major users... are trying to find an answer for this, but have stopped asking because they see it's not a priority for the dev team". It's perhaps the only reason why anyone would pick nw.js over Electron at this point (my opinion, anyhow).

I realize this is a free and open-source project, but let's not pretend that security isn't something everyone should care about. Whether-or-not the source code is proprietary is irrelevant, security should be a priority.

We have looked at tools like enclose, jxcore and others extensively -- and one of my major beefs right now is that while they "work" inside Electron, I can't wrap the runtime node modules (e.g. browser-window) into the snapshot/build/whatever-you-call-them.

On Electron's side we don't want to sacrifice performance for source code protection

I don't think anyone is asking Electron to sacrifice performance, but that's a trade-off many of us are willing to make on our own code. Even in nw.js the "snapshot" isn't (always) the entire project -- it's a subset of the JS code chosen by the developer.

I'm also 👎 on this feature, web technology is just not an appropriate software choice if you need to give your software to customers but ensure they never read it. Snapshots are generated by V8, which means its format is documented - this isn't "protection".

Combined with the existing .asar format, uglify and other methods of "security through frustration" would give most companies the satisfaction of saying "our code isn't in clear text files". It may not be encrypted and safe from NSA snooping, but I don't think that is an expectation anyone has (or at least me).

Case and point: nw.js is "good enough" for most people, even though I'm sure it's "security" is far from robust.


You guys are killing things with Electron! This project is amazing, and we really appreciate the work you are putting into it -- but I really think it's misguided to dismiss this option as something people don't want.

@paulcbetts

This comment has been minimized.

Show comment
Hide comment
@paulcbetts

paulcbetts Oct 22, 2015

Contributor

I realize this is a free and open-source project, but let's not pretend that security isn't something everyone should care about. Whether-or-not the source code is proprietary is irrelevant, security should be a priority.

Code obfuscation is not security (or at least, is a very poor approach to thinking about security). We care a great deal about security. Code obfuscation is about satisfying ill-informed corporate policy. Which is a legitimate use-case! But so are a lot of other features that we want to do, features that move Electron as a platform forward.

Code obfuscation has a very real cost - it's a huge piece of up-front work (i.e. hours that are being spent not making Electron better), and a maintenance nightmare. There are two people who can pay that cost:

  1. Corporations with brain-dead corporate policy can pay the cost of not being able to use great tools like Electron, which means they have a motivation to change this policy - incentives that go the right way! OR
  2. The Electron dev team can pay the cost, slowing down progress for every project in the world that doesn't have brain-dead corporate IP policy, and BigCorps can continue to be rewarded for their bad decisions.
Contributor

paulcbetts commented Oct 22, 2015

I realize this is a free and open-source project, but let's not pretend that security isn't something everyone should care about. Whether-or-not the source code is proprietary is irrelevant, security should be a priority.

Code obfuscation is not security (or at least, is a very poor approach to thinking about security). We care a great deal about security. Code obfuscation is about satisfying ill-informed corporate policy. Which is a legitimate use-case! But so are a lot of other features that we want to do, features that move Electron as a platform forward.

Code obfuscation has a very real cost - it's a huge piece of up-front work (i.e. hours that are being spent not making Electron better), and a maintenance nightmare. There are two people who can pay that cost:

  1. Corporations with brain-dead corporate policy can pay the cost of not being able to use great tools like Electron, which means they have a motivation to change this policy - incentives that go the right way! OR
  2. The Electron dev team can pay the cost, slowing down progress for every project in the world that doesn't have brain-dead corporate IP policy, and BigCorps can continue to be rewarded for their bad decisions.
@arthurakay

This comment has been minimized.

Show comment
Hide comment
@arthurakay

arthurakay Oct 22, 2015

@paulcbetts if I understand correctly, your point is that:

  1. V8 snapshot approach isn't anything more than code obfuscation
  2. Implementing this particular feature would be time consuming for the Electron team, and (in your opinion) not worth the cost of development/maintenance
  3. Any company who needs such source-code protection ought to be able to afford another solution

I am willing to concede the first point, though I still believe it's "good enough" for the vast majority of people interested in Electron. As far as I can tell, this is about the only relevant difference between Electron and nw.js -- and while your goal shouldn't necessarily be to implement every feature of your competitor, it is an obvious bullet point on the list of pros/cons for everyone interested in such a product.

On the second point, perhaps you're right that the Electron team should not have to bear this cost. Maybe V8 snapshots are the wrong solution for the reasons you mention -- but is that simply the end of this conversation? As far as I can tell there isn't a public roadmap for Electron, so if there are other features (more awesome, more important, whatever) I am very curious why the question of "source code protection" (deliberately not using the word "security") gets brushed aside so quickly.

On the third point, you're absolutely right. Companies using Electron, or any OSS product, need to bear significant costs to protect their source code. I'm not suggesting that Electron be the set-it-and-forget-it solution, but the you've already committed to the .asar format which (at least on the surface) seems like halfway to agreeing with the need to lock-down parts of the runtime/source code.

I realize that we can agree to disagree, but the three points you brought up (assuming I've summarized them accurately) are very different from saying "all major users... don't have needs for that". In my case, we have gone to significant lengths to customize Electron modules (among other things) for our own protection. I am sure that others have as well.

If it isn't already obvious, I think Electron is far and away a better solution than nw.js. Maybe it isn't your goal to crush the competition, but this issue is a sticking point for a lot of people who would otherwise be using Electron (even if it's because of flawed logic).

arthurakay commented Oct 22, 2015

@paulcbetts if I understand correctly, your point is that:

  1. V8 snapshot approach isn't anything more than code obfuscation
  2. Implementing this particular feature would be time consuming for the Electron team, and (in your opinion) not worth the cost of development/maintenance
  3. Any company who needs such source-code protection ought to be able to afford another solution

I am willing to concede the first point, though I still believe it's "good enough" for the vast majority of people interested in Electron. As far as I can tell, this is about the only relevant difference between Electron and nw.js -- and while your goal shouldn't necessarily be to implement every feature of your competitor, it is an obvious bullet point on the list of pros/cons for everyone interested in such a product.

On the second point, perhaps you're right that the Electron team should not have to bear this cost. Maybe V8 snapshots are the wrong solution for the reasons you mention -- but is that simply the end of this conversation? As far as I can tell there isn't a public roadmap for Electron, so if there are other features (more awesome, more important, whatever) I am very curious why the question of "source code protection" (deliberately not using the word "security") gets brushed aside so quickly.

On the third point, you're absolutely right. Companies using Electron, or any OSS product, need to bear significant costs to protect their source code. I'm not suggesting that Electron be the set-it-and-forget-it solution, but the you've already committed to the .asar format which (at least on the surface) seems like halfway to agreeing with the need to lock-down parts of the runtime/source code.

I realize that we can agree to disagree, but the three points you brought up (assuming I've summarized them accurately) are very different from saying "all major users... don't have needs for that". In my case, we have gone to significant lengths to customize Electron modules (among other things) for our own protection. I am sure that others have as well.

If it isn't already obvious, I think Electron is far and away a better solution than nw.js. Maybe it isn't your goal to crush the competition, but this issue is a sticking point for a lot of people who would otherwise be using Electron (even if it's because of flawed logic).

@etiktin

This comment has been minimized.

Show comment
Hide comment
@etiktin

etiktin Oct 22, 2015

Contributor

In regards to "V8 snapshot isn't anything more than code obfuscation", I don't think that's the case (details in a previous comment).

It's hard talking about cost when we don't have any estimate for the time it takes to implment something like this in Electron. If it takes a couple of days, to me it seems like a no brainer and we should just do it. If it takes weeks then it should wait in the backlog.

Currently the code is completely in the clear. You don't need any knowledge in reversing to take an Electron app, insert some malicious code and redistribute it. The ease of it, is disturbing.
Edit: Some could argue that that's pretty similar to java and .net, and that's true, but at least they have some 3rd party tools that offer source code protection.

Contributor

etiktin commented Oct 22, 2015

In regards to "V8 snapshot isn't anything more than code obfuscation", I don't think that's the case (details in a previous comment).

It's hard talking about cost when we don't have any estimate for the time it takes to implment something like this in Electron. If it takes a couple of days, to me it seems like a no brainer and we should just do it. If it takes weeks then it should wait in the backlog.

Currently the code is completely in the clear. You don't need any knowledge in reversing to take an Electron app, insert some malicious code and redistribute it. The ease of it, is disturbing.
Edit: Some could argue that that's pretty similar to java and .net, and that's true, but at least they have some 3rd party tools that offer source code protection.

@polarathene

This comment has been minimized.

Show comment
Hide comment
@polarathene

polarathene Oct 23, 2015

Not a solution to the issue for everyone, but has anyone had experience with Edge.js? It allows you to compile propriety code into .dll files and interface with them via Edge.js with Node. Not sure if this approach is suitable for all needs though, perhaps some devs want to protect JS code that interacts with packages/libs in JS(is there any reason to protect this source too?).

polarathene commented Oct 23, 2015

Not a solution to the issue for everyone, but has anyone had experience with Edge.js? It allows you to compile propriety code into .dll files and interface with them via Edge.js with Node. Not sure if this approach is suitable for all needs though, perhaps some devs want to protect JS code that interacts with packages/libs in JS(is there any reason to protect this source too?).

@kalinkrustev

This comment has been minimized.

Show comment
Hide comment
@kalinkrustev

kalinkrustev Oct 24, 2015

What about WebAssembly? It looks like a good fit for Electron, having the probability of it appearing in V8 in the near future.

kalinkrustev commented Oct 24, 2015

What about WebAssembly? It looks like a good fit for Electron, having the probability of it appearing in V8 in the near future.

@paulcbetts

This comment has been minimized.

Show comment
Hide comment
@paulcbetts

paulcbetts Nov 30, 2015

Contributor

@polarathene We use edge.js in the Slack app on Windows. While a bit finicky at times, it definitely works for us. You should use the edge-atom-shell package

Contributor

paulcbetts commented Nov 30, 2015

@polarathene We use edge.js in the Slack app on Windows. While a bit finicky at times, it definitely works for us. You should use the edge-atom-shell package

@timfish

This comment has been minimized.

Show comment
Hide comment
@timfish

timfish Feb 2, 2016

Contributor

I agree that this shouldn't be a priority for the electron team, but for many hardware manufacturers, locking to your device comes under business continuity.

I've worked for a couple of hardware manufacturers who's hardware was cheap to produce but had a high retail price because years had been spent adding features to the software. They were plagued by far eastern manufacturers attempting to clone their hardware and/or software. I even disassembled an Android app and found that one company had converted reflected c# code to Java with matching method names and code mistakes! Mostly we were successful at hindering them through obfuscation.

You could argue that companies in that position should not be using JavaScript, but the speed of cross-platform development using electron can't really be ignored. If a company has IP worth protecting it can probably afford the time to do a pull request.

Could it be added relatively easily to electron/atom/common/asar/asar_util? Would the decryption key be trivial to spot in the native executable? It would all be available in memory but would at least stop casual browsing and modification.

Contributor

timfish commented Feb 2, 2016

I agree that this shouldn't be a priority for the electron team, but for many hardware manufacturers, locking to your device comes under business continuity.

I've worked for a couple of hardware manufacturers who's hardware was cheap to produce but had a high retail price because years had been spent adding features to the software. They were plagued by far eastern manufacturers attempting to clone their hardware and/or software. I even disassembled an Android app and found that one company had converted reflected c# code to Java with matching method names and code mistakes! Mostly we were successful at hindering them through obfuscation.

You could argue that companies in that position should not be using JavaScript, but the speed of cross-platform development using electron can't really be ignored. If a company has IP worth protecting it can probably afford the time to do a pull request.

Could it be added relatively easily to electron/atom/common/asar/asar_util? Would the decryption key be trivial to spot in the native executable? It would all be available in memory but would at least stop casual browsing and modification.

@chino23

This comment has been minimized.

Show comment
Hide comment
@chino23

chino23 Feb 4, 2016

stunned that this is still dismissed as a no go from the devs.

I'd really love to give electron a try but I won't even bother until this is available. Not having this option is the biggest deal breaker for me, plus 2 other teams I know.

It's a real shame. I don't think you realize how much this hurts the adaption of the product. Everyone I talk to developing apps dismisses electron for this reason alone.

chino23 commented Feb 4, 2016

stunned that this is still dismissed as a no go from the devs.

I'd really love to give electron a try but I won't even bother until this is available. Not having this option is the biggest deal breaker for me, plus 2 other teams I know.

It's a real shame. I don't think you realize how much this hurts the adaption of the product. Everyone I talk to developing apps dismisses electron for this reason alone.

@paulcbetts

This comment has been minimized.

Show comment
Hide comment
@paulcbetts

paulcbetts Feb 4, 2016

Contributor

I think we have all the feedback that we need on this issue. If you have a tangible fact to contribute please do, but please don't add any more "But I waaaaaant it!"-style comments.

Contributor

paulcbetts commented Feb 4, 2016

I think we have all the feedback that we need on this issue. If you have a tangible fact to contribute please do, but please don't add any more "But I waaaaaant it!"-style comments.

@denistsoi

This comment has been minimized.

Show comment
Hide comment
@denistsoi

denistsoi Feb 4, 2016

the thing about hiding your source - especially from a js perspective -
it's sort of an architecture problem (if you package and separate your
program into microservices instead of one large program... you'd yield more
"protection").

However, there is documentation about encrypting your files under various
methods, both native binaries and js (though js has it's weaknesses ofc).

but to be very very frank...
I doubt many talented developers care about your code. (we neither have the
curiosity nor the time... and rather spend our time on github reading code
there).

Denis Tsoi
Frontend Web Developer http://www.github.com/denistsoi | *@denistsoi
http://www.twitter.com/denistsoi
| +852 6183 6919*

On Thu, Feb 4, 2016 at 9:29 AM, Paul Betts notifications@github.com wrote:

I think we have all the feedback that we need on this issue. If you have a
tangible fact to contribute please do, but please don't add any "But I
waaaaaant it!"-style comments.


Reply to this email directly or view it on GitHub
#3041 (comment).

denistsoi commented Feb 4, 2016

the thing about hiding your source - especially from a js perspective -
it's sort of an architecture problem (if you package and separate your
program into microservices instead of one large program... you'd yield more
"protection").

However, there is documentation about encrypting your files under various
methods, both native binaries and js (though js has it's weaknesses ofc).

but to be very very frank...
I doubt many talented developers care about your code. (we neither have the
curiosity nor the time... and rather spend our time on github reading code
there).

Denis Tsoi
Frontend Web Developer http://www.github.com/denistsoi | *@denistsoi
http://www.twitter.com/denistsoi
| +852 6183 6919*

On Thu, Feb 4, 2016 at 9:29 AM, Paul Betts notifications@github.com wrote:

I think we have all the feedback that we need on this issue. If you have a
tangible fact to contribute please do, but please don't add any "But I
waaaaaant it!"-style comments.


Reply to this email directly or view it on GitHub
#3041 (comment).

@kethinov

This comment has been minimized.

Show comment
Hide comment
@kethinov

kethinov Feb 5, 2016

Guys, I think we all would love to be able to have this feature, but hassling the electron team repeatedly isn't gonna deliver it. The only even remotely feasible way to do it is V8 snapshots, which as mentioned earlier in the thread comes with tons of extremely hacky tradeoffs which the electron team has judged fairly as not worth the hassle.

The NW.js team implemented it using that appraoch, but they consider it an experimental feature because it is using V8 snapshots in a way that they weren't really designed for. The right approach to solving this problem is to get V8 to support this as a feature, not electron. They're the ones we should be hassling, if anyone.

That said, @paulcbetts, the edge.js approach you mentioned is intriguing. Are there are any hello world examples or sample apps out there to help those of us interested in this understand how we might use that as a reasonable fallback until such time that V8 provides a good way for electron to implement this a natively supported feature in the future (if ever)?

kethinov commented Feb 5, 2016

Guys, I think we all would love to be able to have this feature, but hassling the electron team repeatedly isn't gonna deliver it. The only even remotely feasible way to do it is V8 snapshots, which as mentioned earlier in the thread comes with tons of extremely hacky tradeoffs which the electron team has judged fairly as not worth the hassle.

The NW.js team implemented it using that appraoch, but they consider it an experimental feature because it is using V8 snapshots in a way that they weren't really designed for. The right approach to solving this problem is to get V8 to support this as a feature, not electron. They're the ones we should be hassling, if anyone.

That said, @paulcbetts, the edge.js approach you mentioned is intriguing. Are there are any hello world examples or sample apps out there to help those of us interested in this understand how we might use that as a reasonable fallback until such time that V8 provides a good way for electron to implement this a natively supported feature in the future (if ever)?

@paulcbetts

This comment has been minimized.

Show comment
Hide comment
@paulcbetts

paulcbetts Feb 5, 2016

Contributor

@kethinov To be clear, we don't use edge.js for source protection, but we do use it. I don't know of any sample apps that use it but the idea is that you'd write a C# DLL with classes you want to run, then edge.js lets you just call methods on those classes. Something like:

let jsFunc = edge.func({
  source: 'MyCSharpNameSpace.SomeClass.AStaticMethod()`,
  references: [locationOfMyCSharpDll]
});

jsFunc(1,2,3, (result) => { /* this is a callback */ });

The edge.js website has lots of examples and they work the same way under Electron. I've made an Electron compatible edge.js at edge-atom-shell

Contributor

paulcbetts commented Feb 5, 2016

@kethinov To be clear, we don't use edge.js for source protection, but we do use it. I don't know of any sample apps that use it but the idea is that you'd write a C# DLL with classes you want to run, then edge.js lets you just call methods on those classes. Something like:

let jsFunc = edge.func({
  source: 'MyCSharpNameSpace.SomeClass.AStaticMethod()`,
  references: [locationOfMyCSharpDll]
});

jsFunc(1,2,3, (result) => { /* this is a callback */ });

The edge.js website has lots of examples and they work the same way under Electron. I've made an Electron compatible edge.js at edge-atom-shell

@paulcbetts

This comment has been minimized.

Show comment
Hide comment
@paulcbetts

paulcbetts Feb 5, 2016

Contributor

@McFarts:

"I think we have all the feedback that we need on this issue. If you have a tangible fact to contribute please do, but please don't add any more "But I waaaaaant it!"-style comments."

Contributor

paulcbetts commented Feb 5, 2016

@McFarts:

"I think we have all the feedback that we need on this issue. If you have a tangible fact to contribute please do, but please don't add any more "But I waaaaaant it!"-style comments."

@baconbrad

This comment has been minimized.

Show comment
Hide comment
@baconbrad

baconbrad Feb 5, 2016

Contributor

@paulcbetts Want to elaborate why you are deleting my post? You obviously don't care about the future of gaming and using electron as a gateway, very sad.

These type of posts appear on Electron and NW.js forums constantly. And while this is something both teams would like to give it's users they understand such a feature would inevitability be fruitless. This is due to the design of Chromium, V8, etc. The source has to be exposed in some manner for it to be processed and rendered for the user. Meaning all they can do is make the process difficult to be reversed engineered but not impossible by any means. So source code "protection" is more or less a false sense of protection.

Sure you have V8 snapshots but there is a reason no one is using them. They are major performance killers and have a lot of gotchas using them. So for any game application you can rule them out.

To ultimately protect it you need to use a high level compiled language. Sure you can throw the idea of converting JavaScript to C++ or machine code and have a Chromium and Node.js based application is just an insane undertaking which complicates things much more than just saying it. In the end you get something like V8 snapshots which runs so poorly no one uses it anyways. And all the devs and their man hours that could of been used to improve Electron basically got wasted on this feature.

Another thing you are forgetting is ASAR, Electron, and all it's surrounding technologies are open source. Nothing is preventing you from modifying them to make an encrypted ASAR that can only be decrypted and unpackaged by a custom Electron build. Sure, if someone really wanted to they could find away to crack this and possibly get your source. But this is essentially the same thing you are demanding of the Electron team.

So having a game written in over 50,000 lines of code and wanting to use electron as a platform, with hundred's of man hours put into the game isn't a good 'tangible fact' or argument for source code protection? Got it. I'm done here, as you don't even want to take into consideration of other people's suggestions or ideas.

As a developer before you start a project you should understand and know your technologies. If you set out and create a 50,000 line game knowing there is no way to secure the source, then get mad because you can't protect the source, then that is your mistake and not the Electron/NW.js teams mistake.

Contributor

baconbrad commented Feb 5, 2016

@paulcbetts Want to elaborate why you are deleting my post? You obviously don't care about the future of gaming and using electron as a gateway, very sad.

These type of posts appear on Electron and NW.js forums constantly. And while this is something both teams would like to give it's users they understand such a feature would inevitability be fruitless. This is due to the design of Chromium, V8, etc. The source has to be exposed in some manner for it to be processed and rendered for the user. Meaning all they can do is make the process difficult to be reversed engineered but not impossible by any means. So source code "protection" is more or less a false sense of protection.

Sure you have V8 snapshots but there is a reason no one is using them. They are major performance killers and have a lot of gotchas using them. So for any game application you can rule them out.

To ultimately protect it you need to use a high level compiled language. Sure you can throw the idea of converting JavaScript to C++ or machine code and have a Chromium and Node.js based application is just an insane undertaking which complicates things much more than just saying it. In the end you get something like V8 snapshots which runs so poorly no one uses it anyways. And all the devs and their man hours that could of been used to improve Electron basically got wasted on this feature.

Another thing you are forgetting is ASAR, Electron, and all it's surrounding technologies are open source. Nothing is preventing you from modifying them to make an encrypted ASAR that can only be decrypted and unpackaged by a custom Electron build. Sure, if someone really wanted to they could find away to crack this and possibly get your source. But this is essentially the same thing you are demanding of the Electron team.

So having a game written in over 50,000 lines of code and wanting to use electron as a platform, with hundred's of man hours put into the game isn't a good 'tangible fact' or argument for source code protection? Got it. I'm done here, as you don't even want to take into consideration of other people's suggestions or ideas.

As a developer before you start a project you should understand and know your technologies. If you set out and create a 50,000 line game knowing there is no way to secure the source, then get mad because you can't protect the source, then that is your mistake and not the Electron/NW.js teams mistake.

@lee-dohm

This comment has been minimized.

Show comment
Hide comment
@lee-dohm

lee-dohm Feb 5, 2016

Member

We understand that this is a capability that many people would like to have available to them. There is an old saying though, "You have to pick your battles." Creating a system for robust source code protection on the client is not a battle that the Electron team feels that we have the resources to wage effectively. Until that changes, our answer on this is going to continue to be the same.

If people want to continue discussing this, methods of implementation, options or alternatives, please feel free to do so (civilly) on Discuss, the official Atom and Electron forum.

Thanks everyone for your dedication to Electron and for all the feedback!

Member

lee-dohm commented Feb 5, 2016

We understand that this is a capability that many people would like to have available to them. There is an old saying though, "You have to pick your battles." Creating a system for robust source code protection on the client is not a battle that the Electron team feels that we have the resources to wage effectively. Until that changes, our answer on this is going to continue to be the same.

If people want to continue discussing this, methods of implementation, options or alternatives, please feel free to do so (civilly) on Discuss, the official Atom and Electron forum.

Thanks everyone for your dedication to Electron and for all the feedback!

@electron electron locked and limited conversation to collaborators Feb 5, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.