I would like to bring the real state-of-the-art sound effect middleware onto Web Browser as long as WASM can prevent reverse-engineering. All my high-performance sound processors are written in C/C++.
I used to develop for desktop and android platform. Right now only for SoC/FPGA platforms, mainly develop for audio hobbyists in Japan.
Trying to prevent reverse-engineering is almost always the wrong approach, and usually futile. Given that there are a lot of successful organizations that are producing open-source software, I think just having closed source is enough for most people.
The only real way to prevent reverse engineering is with CPU-level encryption. The last time I looked into this, all the encrypted CPUs were still PowerPC-based, since that architecture is open and royalty-free. Although with SGX extensions and support for full memory encryption, there is a bit more support for encrypted data-in-use support on modern x86 processors in the pipeline, at least.
If it's really something you're worried about, the best solution is to handle all the processing at your end -- i.e. "in the cloud" -- where you control access, and keep all your proprietary work that you want to protect on that side of the system. Of course, that comes with performance considerations.
My creation has been successfully protected in an embedded platform. For year's never have an issue of reverse-engineering. Everything is highly encrypted. I just don't trust any platform except embedded. I've used to develop Android apps based on the same library from the embedded application. People easy to reverse-engineer the app but failed to extract the library for porting use in their custom mods. The libs are also encrypted.
This just means they weren't motivated enough to do it. It has to be exposed to the CPU and quite probably memory to be executed, which means unless those are encrypted and protected, someone with the motivation can just dump the assembly instructions from there.
Trust me. The stuff we were trying to protect was a lot bigger deal than just somebody's proprietary algorithms. Some people are very motivated to reverse engineer certain types of application, even if they have no interest in actually stealing or executing the code.
Most people aren't motivated to steal your code. If they just want to sell it, they'll figure out how to bypass your licensing system and sell forged licenses. They might even wrap it in a facade to look like their own application to less savvy users. If they want to compete with you legitimately, they're better off going cleanroom development to avoid running afoul of your intellectual property rights. At worst, it sounds like you were dealing with people with their own internal interests or small-time/casual pirates with no plans to profit from it.
I would like to bring the real state-of-the-art sound effect middleware onto Web Browser as long as WASM can prevent reverse-engineering. All my high-performance sound processors are written in C/C++.
I used to develop for desktop and android platform. Right now only for SoC/FPGA platforms, mainly develop for audio hobbyists in Japan.
Platform / Application
Sound Processors
... and more
I think I need to know more about this. Big audio fan.
Same here, count me as a fan of DAWs, VSTs and mixing and mastering plugins 🎵🎹
Trying to prevent reverse-engineering is almost always the wrong approach, and usually futile. Given that there are a lot of successful organizations that are producing open-source software, I think just having closed source is enough for most people.
The only real way to prevent reverse engineering is with CPU-level encryption. The last time I looked into this, all the encrypted CPUs were still PowerPC-based, since that architecture is open and royalty-free. Although with SGX extensions and support for full memory encryption, there is a bit more support for encrypted data-in-use support on modern x86 processors in the pipeline, at least.
If it's really something you're worried about, the best solution is to handle all the processing at your end -- i.e. "in the cloud" -- where you control access, and keep all your proprietary work that you want to protect on that side of the system. Of course, that comes with performance considerations.
My creation has been successfully protected in an embedded platform. For year's never have an issue of reverse-engineering. Everything is highly encrypted. I just don't trust any platform except embedded. I've used to develop Android apps based on the same library from the embedded application. People easy to reverse-engineer the app but failed to extract the library for porting use in their custom mods. The libs are also encrypted.
This just means they weren't motivated enough to do it. It has to be exposed to the CPU and quite probably memory to be executed, which means unless those are encrypted and protected, someone with the motivation can just dump the assembly instructions from there.
Trust me. The stuff we were trying to protect was a lot bigger deal than just somebody's proprietary algorithms. Some people are very motivated to reverse engineer certain types of application, even if they have no interest in actually stealing or executing the code.
Most people aren't motivated to steal your code. If they just want to sell it, they'll figure out how to bypass your licensing system and sell forged licenses. They might even wrap it in a facade to look like their own application to less savvy users. If they want to compete with you legitimately, they're better off going cleanroom development to avoid running afoul of your intellectual property rights. At worst, it sounds like you were dealing with people with their own internal interests or small-time/casual pirates with no plans to profit from it.
True. It just a matter of time.