IE, you'd have to convert the javascript to C, and then compile the C into web-assembly, right? Does V8 have a method to convert JS to C?
IE, you'd have to convert the javascript to C, and then compile the C into web-assembly, right? Does V8 have a method to convert JS to C?
Otherwise, you will have a hard time to convert your Javascript code. You have to implement a JIT compiler and GC too. Webassembly was never designed to be a replacement for JavaScript. And especially, it was never designed to protect your source code. A minimizer/obsfucator does a great job of making your JavaScript code unreadable.
I hardly get that, all and every major backer of WASM did effectively admit at some point that "ip protection" was the one and only reason they back it.
The absence of a native dom interface or proper I/O implementation at this point means that WASM compiled code actually runs slower for everyday web apps than non-compiled code.
I'm sure you wouldn't mind providing sources for this bold claim?
This kind of obfuscation is harmful to the web, don’t do it. Also, any compsci student with a summer of free time can easily break it, so it’s useless, too. You’re just wasting your own time and the bandwidth and performance of your users.
In fact, if you tell me what site you want to obfuscate your code on with WASM, I (an average compsci student) will spend my next summer reversing it, deobfuscating it, and publishing the results publicly (just to demonstrate you how useless your obfuscation is).
Photoshop isn't on the web, but I oppose closed source in principle.
> Should they give away their source code?
Ideally, yes. If you do it is still your decision, but you still should be aware that if you introduce truly new concepts, someone will clean-room reverse them, and publish them.
> So, art programs kind of need source protection.
The Krita project begs to differ.
> I won't be making a web-version until this is the case. If you can crack NW.js source protection, let me know
Then you shouldn't make any build where the business code runs on the client. Even native binaries can be reversed, their functionality analyzed, and copied. Which is how LibreOffice/OpenOffice originally discovered how to parse the Microsoft Office formats.
When people paint, they want it responsive, no stream lag, no server hiccups. I must allow people to install the software on their computer. I would still like to protect the work I've done, because I'm just one guy making software, and I don't have marketing money. What would stop big companies from taking my source and spending more on advertising? I need source protection.
If your threat model is a company with billions in of dollars in revenue, then source protection is useless.
NW.js protection can be cracked, too, requiring maybe one or two man-months more. For a student reversing it, this is annoying, but not a problem.
For GoogleAppleAdobeZon? They dont even notice the cost difference. You can be Snapchat, have unique features, and have it all obfuscated — and Facebook can still copy it all in weeks.
The question isn't "will Adobe be able to copy my app" — the answer to that is always yes.
I think there are times when open source isn't the best. I never would have spent so much time making art software if I didn't think I could make it reasonably hard to crack. Eh, maybe I would have anyway, but I might have just made another mindless web app that wasn't difficult to code.
I think there are definitely cases where closed source works, especially when certain algorithms are easy to read but hard to contrive.
For native binaries, such as games, currently the strongest solution is Denuvo, from a team that formerly implemented copy protection for Sony. Decades of engineering went into it, at the risk of significantly slowing down the game, using several layers of obfuscation (including VMProtect), all wrapped around the existing, older obfuscation schemes, for a native binary.
The first version of it took a few hobbyists 6 months to break, by now games protected with it get usually broken within of one week or less by hobbyists.
That’s hobbyists.
If, as you truly say, your threat model is Adobe, or a similar corporation, your obfuscation is basically useless. If determined individuals can break some of the most advanced obfuscation schemes in days, how long do you think will it take Adobe to break yours, if they actually see you as competitor?
> I think there are definitely cases where closed source works, especially when certain algorithms are easy to read but hard to contrive.
They work short-term, but as soon as someone extracts the algorithm once, everyone has it. Especially considering that in most places algorithms are neither protected by copyright nor patents (including the EU).
Same story since the Amiga Days
As someone who worked for a while on painting tech at a BigCo, the truth is that the chance that a BigCo would steal an algorithm from your one-man-paint-app's minimally obfuscated JS is extremely close to zero (excluding if it was MIT/BSD OSS license, and even then I would be pretty surprised if it happened). Anything half as novel as you are describing would be better leveraged by talking about some of it as siggraph and then acqui-hire selling your company for millions to a Adobe/Microsoft/Apple type.
It makes perfect sense to not open source it, but if you are trying to build this as a business any amount of time you second you spend trying harden your source from some hypothetical reverse engineering boogeyman (that is likely to never even be trivially attempted) is time that would be much better spent on marketing or improving your product.
Almost every country on this planet has copyright laws.
If you're worried about them ignoring the law and taking your source code why are you not worried about them ignoring the law and physically stealing your computers?
[0] http://docs.nwjs.io/en/latest/For%20Users/Advanced/Protect%2...
Running JavaScript through an optimizing compiler and minifier will obscure pretty much the same information. But either way, you can step through the code in your browser's debugger to see what it does.