4 ms·

What do you think the suitability of Electron is for software that is designed to provide revenue with per seat licences and no service component? I.e. 'tradit

by fsloth 11y ago

What do you think the suitability of Electron is for software that is designed to provide revenue with per seat licences and no service component? I.e. 'traditional desktop app'. It seems to me, given how easy it seems to be to copy and modify an Electron application a third party could always copy an application, whitewash it and capture a portion of the market. The counter point to this is that ownership of the developer brand and distribution channel is which will always drive sales. I'm not sure which aspect is more important when planning a technology platform and revenue model...

grinich 11y ago
People can crack/clone desktop apps regardless of the language they're written in. You can certainly add the same types of protection to Electron apps that might be found in traditional native apps, but it just makes things harder and not necessarily impossible. One of the benefits of Electron is the updater system, which allows you to release updates pretty frequently. You could tie that to the paid user account and just innovate faster than people cloning your app! Electron also uses a specific binary packing system (ASAR) to ship app code, so cloning is also a bit harder than just copying a bunch of JS files. https://github.com/electron/electron/blob/master/docs/tutorial/application-packaging.md https://github.com/electron/electron/blob/master/docs/tutori...
- tehno 11y ago
  Cloning is as simple as "npm install asar && asar extract app.asar", modify what you want and "asar pack" again. So the packing system is really no protection in itself. See https://github.com/electron/asar https://github.com/electron/asar
voltagex_ 11y ago
That seems like a legal problem rather than a technical one. People who want to crack or even rebadge your software will always be able to.
- soundwave106 11y ago
  This is true given a dedicated enough programmer. Since most programmers aren't quite this dedicated, however, this isn't 100% true. From what I am aware, in lower level (C++) development there are some definite strategies to "deter" piracy even at a technical level. Stuff that Urs (developer of u-He software synthesizers) talks about here, eg: https://www.kvraudio.com/forum/viewtopic.php?f=4&t=400768&start=270#p5639387 https://www.kvraudio.com/forum/viewtopic.php?f=4&t=400768&st... Basically: A) Make the protective schemes as non-obvious as possible in a disassembler (obfuscation, making the copy protection part of some core routines etc.) B) Provide a few obvious "sweeteners" that "pretend crack" the software for a period, but then show a "whoops your copy is pirated here's a offer to purchase it" later. (EG: a time bomb.) This allows the crackers to get their 0 day warez thrillz, without actually truly cracking the program. Of course, none of this is 100% insurmountable. That's not the point of this exercise. The goal is to basically make cracking the software a chore more beyond usual, and therefore, not worth the typical cracker's time. I am not sure how one would approach this with managed software or web-wrapped software (although if you can run the copy protection in a native module, that would be the way to go.)
Sophistifunk 11y ago
Trying to stop piracy through client-side technical means is always going to be a losing battle, becasue you can't trust the client. But you can embed native modules in Electron apps, so you can do whatever you were planning to do in native code to "verify" the installation, and then load JS only after decrypting it in native code. Compiling your licensing / decryption code for 3 platforms still beats having to maintain 3 copies of the whole app's source.
- kethinov 11y ago
  I don't think the issue is piracy per se. People want the ability to compile down the JS into native code for obfuscation reasons to prevent/discourage derivative works. I know you can do that to some extent by minifying your JS code and I also know that no obfuscation or compilation technique is going to 100% prevent derivative works, but it helps a lot and it's a feature that many wish the Electron team would look into. NW.js has it, but it's super hacky as it uses (abuses) the V8 snapshot feature to deliver the functionality, seriously degrading performance in the process.
z3t4 11y ago
I've been thinking long and hard about this and I think one strategy, how stupid it might sound, is to release the software unfinished then make updates like SaaS.
frankwiles 11y ago
As others have said, you can never really truly protect things on the client side no matter what language tech you use. We used Electron (well still called Atom-shell back when we started) for building Spectrum (https://www.devspectrum.com https://www.devspectrum.com) which we charge per seat and it's been a great development experience and it's certainly performant enough to handle tons of local logging capture/filtering.

by fsloth 11y ago

grinich 11y ago

People can crack/clone desktop apps regardless of the language they're written in. You can certainly add the same types of protection to Electron apps that might be found in traditional native apps, but it just makes things harder and not necessarily impossible. One of the benefits of Electron is the updater system, which allows you to release updates pretty frequently. You could tie that to the paid user account and just innovate faster than people cloning your app! Electron also uses a specific binary packing system (ASAR) to ship app code, so cloning is also a bit harder than just copying a bunch of JS files. https://github.com/electron/electron/blob/master/docs/tutorial/application-packaging.md https://github.com/electron/electron/blob/master/docs/tutori...

tehno 11y ago
Cloning is as simple as "npm install asar && asar extract app.asar", modify what you want and "asar pack" again. So the packing system is really no protection in itself. See https://github.com/electron/asar https://github.com/electron/asar

voltagex_ 11y ago

That seems like a legal problem rather than a technical one. People who want to crack or even rebadge your software will always be able to.

soundwave106 11y ago
This is true given a dedicated enough programmer. Since most programmers aren't quite this dedicated, however, this isn't 100% true. From what I am aware, in lower level (C++) development there are some definite strategies to "deter" piracy even at a technical level. Stuff that Urs (developer of u-He software synthesizers) talks about here, eg: https://www.kvraudio.com/forum/viewtopic.php?f=4&t=400768&start=270#p5639387 https://www.kvraudio.com/forum/viewtopic.php?f=4&t=400768&st... Basically: A) Make the protective schemes as non-obvious as possible in a disassembler (obfuscation, making the copy protection part of some core routines etc.) B) Provide a few obvious "sweeteners" that "pretend crack" the software for a period, but then show a "whoops your copy is pirated here's a offer to purchase it" later. (EG: a time bomb.) This allows the crackers to get their 0 day warez thrillz, without actually truly cracking the program. Of course, none of this is 100% insurmountable. That's not the point of this exercise. The goal is to basically make cracking the software a chore more beyond usual, and therefore, not worth the typical cracker's time. I am not sure how one would approach this with managed software or web-wrapped software (although if you can run the copy protection in a native module, that would be the way to go.)

Sophistifunk 11y ago

Trying to stop piracy through client-side technical means is always going to be a losing battle, becasue you can't trust the client. But you can embed native modules in Electron apps, so you can do whatever you were planning to do in native code to "verify" the installation, and then load JS only after decrypting it in native code. Compiling your licensing / decryption code for 3 platforms still beats having to maintain 3 copies of the whole app's source.

kethinov 11y ago
I don't think the issue is piracy per se. People want the ability to compile down the JS into native code for obfuscation reasons to prevent/discourage derivative works. I know you can do that to some extent by minifying your JS code and I also know that no obfuscation or compilation technique is going to 100% prevent derivative works, but it helps a lot and it's a feature that many wish the Electron team would look into. NW.js has it, but it's super hacky as it uses (abuses) the V8 snapshot feature to deliver the functionality, seriously degrading performance in the process.

z3t4 11y ago

I've been thinking long and hard about this and I think one strategy, how stupid it might sound, is to release the software unfinished then make updates like SaaS.

frankwiles 11y ago

As others have said, you can never really truly protect things on the client side no matter what language tech you use. We used Electron (well still called Atom-shell back when we started) for building Spectrum (https://www.devspectrum.com https://www.devspectrum.com) which we charge per seat and it's been a great development experience and it's certainly performant enough to handle tons of local logging capture/filtering.