As security is one of Symphony’s core tenets, our approach to DIP integration must not introduce any risks in this area. DIP providers usually offer two integration mechanisms for applications based on web technologies like the Symphony client:
- The first mechanism, called embedded mode, requires the DIP provider to launch the web application as a web view in one of its window containers.
- The second mechanism, called standalone mode, allows the DIP provider to work with applications launched as standalone processes and interact through inter-process communication. This mechanism involves integrating proxy libraries (provided by the DIP) to communicate with the DIP agent through DIP-specific and FDC3 APIs.
From a technical standpoint, the embedded mode is much simpler to implement and is probably the best option for applications that do not manage sensitive information. However, web applications running in DIP webviews do not run in the browser’s sandboxed environment, which means that code running in the DIP can technically access all data loaded in the webapp memory. Importantly, this would compromise Symphony’s security chain, such as messages and chat cryptographic keys, which is why embedded mode is not the default Symphony integration mechanism.
As previously mentioned, our integration solution is to rely on optional plugins (also known as adapters) that will allow communication with any DIP, while still running the Symphony client as a standalone process. A secondary benefit of this approach is that running as a standalone application also ensures better performance: the Symphony client can run in the background, enabling it to quickly react to any client-side events.