In the previous part, we delved into the different steps of achieving isolation between the module sandbox and the host app during the development phase. These involved having separate access control, compiled module sandbox SDK, and separate obfuscation for module sandbox.
As we bring this series to a close, we confront challenges involved with integrating common dependencies between the host app and the module sandbox. Privacy concerns, data isolation, and the need for stringent security standards prompted the adoption of “Tenantization” as a novel solution. This practice involves encapsulating and isolating the instances of dependencies, within the dedicated environment of the module sandbox.
The forthcoming discussion will elaborate on the benefits of shared dependencies, the benefits of tenantization, and specific use cases of tenantization. From networking to analytics library, each dependency has been compartmentalized, establishing a robust barrier that guarantees safety.
Benefits of Shared Dependencies
Leveraging the existing dependencies of the host app within the module sandbox offers a multitude of advantages. Coupled with tenantization, it fortifies the commitment to maintain robust security measures for our module sandboxing solution.
- Code Reusability: By sharing dependencies, developers can avoid code redundancy, ultimately reducing the overall development effort required.
- Easier Maintenance: Centralizing the management of dependencies can streamline the maintenance process. This approach ensures that updates, bug fixes, and changes are uniformly applied, minimizing the likelihood of inconsistencies or errors.
- Streamlined Development Workflow: Utilizing shared dependencies can enhance the efficiency of the development workflow. When developers across various project segments leverage common dependencies, collaboration becomes more seamless and effective.
Benefits of Tenantization
In the absence of proper isolation mechanisms like tenantization, the utilization of shared dependencies within the module sandbox could pose significant risks, potentially compromising security and privacy. In the absence of sufficient safeguards, the host application could potentially obtain unrestricted access to sensitive data housed within the module’s sandbox Tenantization, with its emphasis on encapsulating and isolating dependencies within the module’s sandbox environment, offers numerous advantages.
- Enhanced Security and Privacy: The compartmentalization enabled by tenantization reduces the risk of interference by the host application. As each dependency is initialized and isolated within the module sandbox, this process ensures that any data flowing through dependencies is also secure, and no unauthorized access by the host app is allowed.
- Simplified Maintenance: Through the practice of tenantization, segregating dependency instances enables us to effectively streamline their management. Updates and modifications can be applied to the module sandbox’s dependency instance without having any effect on the host app and its functionality.
Networking Dependency
Following the principle of tenantization, the module sandbox maintains a dedicated and self-contained instance of the Networking dependency. This exclusive instance manages all network communications within the module sandbox. The following are the key components managed by this dedicated Networking instance:
- SSL Certificates: The module sandbox maintains distinct SSL certificates for SSL pinning purposes. These certificates serve as a robust layer of security, ensuring encrypted communication remains exclusive within the module sandbox, fortifying the integrity of data exchanges.
- Network Communication: The isolated Networking library instance is responsible for facilitating all interactions with the backend. All the related configurations and functionality like interceptors, network sessions, API endpoints, etc., are all isolated within the module sandbox environment. This separation ensures that no interference or data leakage occurs between the host app and the module sandbox, guaranteeing the privacy and security of user data.
- User Authorization Token: Within the module sandbox environment, a distinct authentication token is maintained, separate from that of the host application. Since the host application is unable to access the authentication token specific to the module sandbox, it effectively prevents any unauthorized attempts by the host app to call the services of the module sandbox.
- Token Refresh: A vital mechanism that ensures uninterrupted user access to secured resources. By guaranteeing that this process is conducted independently from the host application, we further enhance privacy, consistent with our dedication to providing a secure and user-centric experience.
- Checksum: To maintain data integrity, checksum generation, and validation are conducted separately within the module sandbox. The salt used to generate the checksum is isolated within the module sandbox separate from that of the host app. This additional layer of security assures that data received from the backend has not been tampered with during transmission and vice versa.
- Request/Response Encryption and Decryption: The module sandbox isolates encryption and decryption processes for requests and responses respectively, guaranteeing the confidentiality and integrity of data exchanged with the module sandbox’s services. The cryptographic keys used for the encryption/decryption are isolated within the sandbox, preventing the host app from tampering with data exchange.
Analytics Dependency
As we strive to protect user data, we now shift our focus to another essential dependency. Tracking user behaviour is a common practice, but it becomes imperative to isolate and secure the analytics data generated within the module sandbox, preventing any unauthorized access or tracking by the host app. To achieve this, we have harnessed the power of tenantization, successfully segregating the analytics functionality. Here are the key considerations addressed while applying tenantization:
- Network Communication: The networking dependency instance of the module sandbox is injected into this library, allowing it to operate autonomously and independently of the host app. Furthermore, network configurations, including the API endpoints to which analytics data is transmitted, are also encapsulated within the module sandbox. This segregation ensures that analytics data generated by the sandboxed app remains exclusive and isolated from that of the host app.
- Batching for Efficiency: Sending each analytic event individually in real-time can be inefficient and resource-intensive. To optimize this process, analytics events are first collected and stored in a local database within the module sandbox. Subsequently, these events are transmitted periodically in batches, reducing overhead and enhancing performance. Essentially, to uphold the highest level of data isolation and privacy, distinct databases for caching event data are maintained for both the module sandbox and the host application.
Drawbacks of Shared Dependencies
Even though the usage of shared dependencies provides the above-mentioned benefits, it also comes with a few drawbacks highlighted below.
- In Android, module sandboxes may utilize different versions of shared dependencies compared to the host app, potentially causing app inconsistencies. However, this issue can be effectively addressed by implementing a centralized process to manage dependency versions. On the other hand, in iOS, it’s customary to maintain uniform dependency versions across the entire app. Deviating from this convention often results in app crashes.
- Re-generation of module sandbox: As highlighted in the previous part of this series, the best way to include the module sandbox withinthe host app was to integrate it as a compiled binary SDK. However, there are platform-specific conditions that may necessitate the regeneration of this binary SDK, even if no changes occur within the module sandbox itself.
- For Android, a regeneration may be required if there is a breaking change in any shared dependency, i.e. the compilation of the module sandbox fails because of a code change in a shared dependency.
- In iOS development, it is customary to maintain the same versions of shared dependencies, even in the absence of any breaking changes. This is for the reason that in iOS there is no guarantee that the app would run successfully even if no breaking change was there for the module sandbox.
To simplify the compiled binary SDK re-generation, an automation pipeline could be set up, which will re-generate the SDK on any code changes in the shared dependency. Additionally, an integration test suite could be created to preemptively identify and address any potential issues.
- Limited Autonomy: Modules might lose autonomy if they heavily rely on shared dependencies. Changes to a shared dependency may require coordination among different teams, slowing down development.
Conclusion
In this three-part series on module sandboxing, we embarked on a journey to enhance security and isolation within our app ecosystem.
Beginning with an introduction to the concept in Part 1 and navigating the challenges during development in Part 2.
We now conclude with a focus on integrating shared dependencies. The implementation of tenantization, encapsulating and isolating the module sandbox dependencies within itself, emerges as a novel solution, ensuring dedicated environments for each component and upholding stringent security standards.
This series stands as a testament to our commitment to fortified security, and privacy. While our journey concludes here, the impact resonates in the strengthened foundation of our technology, promising a secure and resilient future for our app ecosystem. Stay tuned for more innovations as we continue pushing the boundaries of technology and security!