Each time you apply transformations to your project counts as a request, independently of the number of files and protections. Every time this protected version is executed, it does not count as a new service request. The protected version of the code doesn't contact our service. So in summary, you only do Jscrambler service requests when you have a new version of the code to protect.
Your protected code will continue to work regardless of you staying subscribed or not. You need to keep subscribed only in case you need to protect newer versions of the code. The ones you have protected before will work forever.
You can use our Code Annotations to control our transformations through several code blocks
Self-defending conceals the logic contained in functions and objects and prevent attempts of code tampering by using anti-tampering and anti-debugging techniques. With these techniques, if someone tries to tamper with the code, the code will break its functionality and if they try to use any JavaScript debugger, it will trigger defenses to prevent code analysis and the code will stop working too.
All of Jscrambler's Code transformations are developed to have the least impact possible. The performance hits are manageable and depend a lot on the application you are trying to protect.
However, Jscrambler has some features that can help you manage the performance impact of obfuscation like Application Profiling. This feature allows you to monitor the application at runtime and collect performance related metadata which will then be used to automatically produce recommended protection settings for your application. You can learn more about this in the Profiling documentation.
Additionaly, with Code Annotations you can manually annotate source code (e.g. functions, statements, variable declarations) to change Jscrambler behaviour during protection, which can be used to increase protection or to reduce the impact on performance.
You may use an API client if you would like to integrate Jscrambler into your development process and submit requests to our Web service programmatically. Check them out on API Clients.
Potency represents the power of a transformation to increase your code complexity. Resilience represents the difficulty to revert the transformed code into its original form. Cost represents the impact of a given transformation in execution time and space that it will have in a transformed application.
The Application Locks are a set of features that allow you to lock your application and your code to a specific environment or criteria. If you develop and sell JavaScript applications for example you’ll want to prevent that someone that didn’t pay or whose license has expired from executing your JavaScript. You can use Domain-Lock can lock your code to a predefined list of domains or OSs. If someone places it anywhere else, it will not execute correctly. You can also use the Date Lock feature to deliver expirable demos to your clients without incurring in the fear of JavaScript code theft or client-loss.
Any change to the application's source code will make the profiling data invalid. For this reason, if you select the automatic mode, we always recommend you to request new profiling. While in the annotations mode, you should only request new profiling, if you experience performance degradation on your application.
Code Annotations take precedence over all profiling operations.
As long as it takes to execute all the representative use-cases of your application.
No. If you stop profiling, you will need to restart profiling from the beginning to collect any additional data. If the instrumented application is closed but the profiling wasn't stopped, then it can be reopened for additional profiling, but if it is closed for too long (so it does not send any further data), profiling will be automatically stopped after some time.
It is also not recommended to leave the application open and idle for long periods unless that is something your end-users are also likely to do, since doing so have the profiler believe that being idle is a typical use-case of the application.
Yes. To do that go to "Protection History", select the desired protection and click the link in the "Profiling Report" section. As a side note, in the "Protection History", there is a column named "Profiling" which tells you if a protection was made using profiling settings, helping users to easily identify these kind of protections.
Yes, you can use Jscrambler CLI to protect a React Native application.
When the profiling service detects functions as being protection-sensitive (e.g. performance-critical) it automatically recommends specific protection settings to them.
You should be cautious in cases where a high percentage of the functions are recommended to be protected with a Light Obfuscation template, as this can reduce the level of protection on those functions. Please review each function individually to make sure that there isn't any case of a function that requires a high level of protection.
Not at this point, profiling service does not analyze code outside functions.
Not at this point, profiling service does not analyze code outside functions.
Yes, you can. When selecting the automatic mode, Jscrambler will ignore those profiling annotations.
The two types of annotations can coexist in the same files, but not in the same statement.
No, only enable and default keywords are available for profiling annotations. However, you can refer to aliases created with define keyword when using profiling enable annotations.
When you select off or automatic modes, Jscrambler ignores the profiling annotations present in your code. All the other non-profiling annotations continue to work as usual.