-
Notifications
You must be signed in to change notification settings - Fork 12
Callback Delay, Telemetry Impact, and Threat Scanning Completion Status
We would like to reflect a few performance and telemetry related topics that emerge occasionally.
Common Questions:
- It takes 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.
- Detections and related app callbacks are asynchronous. Network calls for the data collection are performed before the callbacks are invoked. Your app won't be slowed down in any way; 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 the 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.
TIP: If you're getting the appIntegrity error in the production app, send us ([email protected]) your packageName/bundleId and watcherMail, and we will try to look into it.
freeRASP collects security diagnostics data (read more about Data Collection) 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.
In general, there are two main things that will be improved:
- [WIP] Transfer to a better cloud infrastructure setup will further reduce the network delays
- [WIP] New API will allow checking if everything is OK once everything was checked (imagine sth like
await freeRASP.onInitialAssessmentDone{ result => ... })