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?
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 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 👌.
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.
If you're getting the appIntegrity incident in the production app, send us your packageName/bundleId and watcherMail at support@talsec.atlassian.net, and we will look into it.
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.