Are there supported ways of protecting code?

It’s been awhile since I looked into this but are there better or recommended ways of protecting the code contained in Capacitor apps? I’ve read through Capacitor Security and they are definitely some good practices but it would be nice to be able to make it harder to access the raw code in the first place.

It looks like this plugin might help though it doesn’t work with Capacitor apps yet.

The other option I’ve seen floating around is just obfuscating the code but that’s fairly easy to deobfuscate. I did that Jscrambler recommended though I’m not sure how well it works and it’s kind of expensive.

There are a lot of parallels between software and books, and a lot of the same issues come up. Realistically, I think you will save yourself a lot of time, effort, and anguish if you treat this as a legal issue within the framework of copyright law, as opposed to a technical issue.

If Alice gives Bob her code to execute on machines under his control, he can read it. This is especially true of interpreted languages like JavaScript. The AES plugin you mention is not going to help here, because in order for the code to execute, the key must be readable in plain text somewhere. Bake that into your app binary and Bob can decrypt things just as easily.

To summarize: if you’re worried about somebody cloning your app, talk to lawyers. If you’re worried about secrets being extracted from your app binary, design your system so that secrets are not included in the app binary.

3 Likes

Agree with @rapropos. If you have sensitive code (typically proprietary algorithms), it’s best to run those server-side.

@rapropos thanks for response and in general I agree with both points made in your summary.

I think the main benefit of encrypting the www and having it decrypted at runtime as done in AES Plugin is it slightly raises the amount of effort required to just copy and modify the code. For example, without any kind of encryption you can just download an APK or IPA file, right-click, run the code through a deobfuscation tool, and start exploring away. By merely adding the additional encryption step it could discourage a percentage of people who are looking to steal an app with minimal effort.

In my case I have several Cordova/Ionic-based apps the need to be fully functional offline and don’t rely too much on a server. How would you keep proprietary code on the server while also having an app that functions entirely offline?

Ultimately we have gone the lawyer route in the past but it’s expensive, slow, and doesn’t always produce a positive outcome. For example, several of our apps get targeted by companies abroad, most commonly Vietnam in our case. We spend time getting one shut down they just open another account, make minimal changes, and the process starts again. In the case of dealing with DMCA takedowns via Apple it can take 6-12 months each time to get a resolution.

The way I look it this issue is this.

My ability to write this response to you in this forum is totally dependent on the freely-given efforts of thousands of people over decades. Whether it’s the Chromium browser I’m using, the WWW in the first place, the Debian Linux system it’s on, the GCC compiler that built it all, the very concept of TCP/IP networking, or any of the other zillions of open-source projects underpinning all of that, I didn’t have to directly pay anybody for it. This, naturally, is also totally true of Ionic Framework, and all the stuff underneath it.

I have donated money and contributed to some of these projects over the years. I have had people pay me to develop software that is itself based on these free projects. I try to be responsive to my customers’ needs, and like to fantasize that I’m good enough at doing that to make a living. I would rather concentrate my effort in that direction - making more and cooler apps, or helping other people to turn their visions into reality - than towards the “walled guarden” (deliberate misspelling) model of obfuscation and copy protection. I feel I am a happier, if not monetarily richer, developer and netizen with this worldview.

All that being said, if you’re still reading, I don’t know what your app domain is, so I’ll just have to generalize, but many mobile apps involve production, consumption, and transmission of information. If your app domain can somehow involve information that you generate or curate, then that would seem to be a logical place to move it to the server. Offline or unapproved clones would have stale data, providing an incentive to use your official app. Some other app domains lend themselves to community building, which is another place you can differentiate yourself from somebody peddling a clone of your code. Finally, you can sell support or do “feature bounties”.

In summary, we’re all standing on the shoulders of free software giants here, so I think it feels most natural to adopt their strategies for finding ways to get compensated for their effort, instead of trying to retrofit economic models built on scarcity of physical objects.

Again I don’t disagree and probably should have provided a bit more context surrounding the apps I’ve been referencing. I’m still reading and appreciate the response.

We have several educational-based apps with a fixed amount of content and features. There is an additional inapp purchase to remove ads and unlock a few other features for those wanting them. We don’t have plans of expanding the available content or features much more at this point in time. Other than Firebase Analytics and some Remote Config settings used for A/B testing there is little additional network connectivity required. What typically happens when someone clones our app is:

  • Change the name
  • Change the styling
  • Run all of our images through a script to slightly alter their colors
  • Run all of our recorded audio through a script to slightly alter the pitch
  • Replace other strings like inapp products, and Firebase project settings

They basically make as many minimal changes required to try to make a case that their app is unique when we send a takedown request although 99% of the code is identical. Since this mainly seems to be happening from developers in Vietnam where the cost of living is lower and they didn’t actually have to spend time making the app they undercut our inapp purchase price by about half. If we don’t catch them soon enough they start to gain traction in the stores given that they are essentially the same thing for much less.

In retrospect 5 years ago when initially making the apps we should have considered a structure that had more built-in resiliency. Hindsight is 2020 in this regard, we have learned from that mistake, and will certainly not being taking this approach in future apps. So my initial post about trying to protect our code was from the perspective of just trying to add another roadblock to try to discourage cloning. Not completely unlike password encryption, where with enough computing power any password can theoretically be cracked, but the time required to do so is the deterring factor. In this case by encrypting it makes it slightly less easy than right clicking and browsing the contents.

We are certainly grateful for all of the awesome open-source projects that helped us build our apps over the years but being open-source is a choice. In the case of our existing apps they are not intended to be open-source.

Thanks for providing more details. In this sense, I absolutely understand why you’d want to protect the code.

I haven’t used it, but Jscrambler comes up a lot. I suppose you’ll have to weigh its cost vs the cost of fighting app clones that steal your revenue.