Callback Delay, Telemetry Impact, and Threat Scanning Completion Status
We would like to reflect on a few performance and telemetry-related topics that emerge occasionally.
Common Questions:
Why does it take too long to finish all the checks?
How to know when all checks are finished?
When are telemetry data transmitted?
Key Notes:
Incidents that are triggered during the development (integration & testing) won't happen to a majority of users in the production.
Callbacks can be invoked slower if the freeRASP backend endpoint is overloaded. Data collection takes precedence. However, do not worry; the application will function as intended, and only callbacks might be a little delayed.
freeRASP's threat detection operates asynchronously and continuously. The
Talsec.start(...)function merely initiates monitoring; it does not perform a synchronous, one-time scan that returns all results immediately. Actual threat detections are reported over time via callbacks.
The Performance
freeRASP works smoothly in production, but it may be tricky to understand all the freeRASP concepts during development. During the integration and testing of the freeRASP, you may have observed that it took longer than expected to get results for all threats (callbacks). You want to get results quickly, respond to threats effectively, and ensure there is no noticeable jankiness in the UI interactions.
freeRASP has to do a lot of work once started. The cold boot is a really intensive moment when all detections must be performed, telemetry data transmitted, and callbacks to your app must be delivered (in this order).
Talsec team efforts and community contributions allow freeRASP to improve the performance and security trade-offs continually by tuning the asynchronous processes, network activity, and internal business logic. Like that time when the internal detector ordering was reworked to significantly speed evaluation based on this reported issue and the telemetry insights about the speed of detectors 👌.
Beware Development vs. Production Environment Bias
Remember the phrase "It is darkest before the dawn"? The integration and testing of freeRASP are inherently accompanied by unintentional threat callbacks invoked by incorrect provisioning of the app's signature (appIntegrity callback), using a simulator for development, an unofficial store (because you haven't published it yet), and others. We've all been there.
It may also seem disconcerting to see that it takes too long until the last expected threat callback invokes. Yet, keep in mind that in production, these incidents won't happen for the genuine unaltered apps run in normal conditions. The performance impact will be negligible. On the contrary, the comfort of a potential attacker and performance degradation in adverse conditions is acceptable.
Cold Boot Telemetry & Best Effort Service
freeRASP collects security diagnostics data (read more in User Data Policies) in accordance with the Fair Usage Policy. Every detected threat is immediately synchronously logged to a common freeRASP backend. Latencies inflicted by the overload of the endpoint are unfortunate, but we continuously improve and scale as much as possible.
Why freeRASP Doesn't "Finish": Understanding Asynchronous Security Monitoring
freeRASP is designed to provide continuous, real-time mobile application security by operating asynchronously in the background. Unlike traditional security scans that might perform a one-time check and deliver all results synchronously, freeRASP constantly monitors for potential threats. When you call Talsec.start(...), it does not execute an immediate, comprehensive scan that finishes and returns a full snapshot of your app's security status. Instead, this function simply initiates the monitoring service, allowing freeRASP to begin its ongoing vigilance.
Due to this asynchronous nature, any immediate attempt to retrieve the security status after Talsec.start(...) is called will likely yield an outdated result. Threat detections happen over time, in the background, and freeRASP communicates these detections through callbacks. These callbacks are functions you define that get triggered when a specific threat (such as a debugger being attached or a screenshot detected) is identified. It is these callbacks that are responsible for updating your application's understanding of the current security state.
It takes some time for freeRASP to actually detect threats and trigger its corresponding callbacks to report them, the callback solution provided for all freeRASP flavors ensures an accurate reflection of freeRASP's ongoing, dynamic threat detections.
Last updated