HTML Subset Discussion

The proposal presented here is to support a strict subset of HTML5 and a strictly limited set of styles. This pages provides an explanation of why this is necessary, with the intention that discussion about the extent of this subset can take place here.

Issues Arising from Unlimited Support of HTML, CSS and JavaScript

There are several issues which would result from allowing unlimited HTML content in Symphony chat messages, which fall into the following categories. Since the content of Symphony messages are encrypted it is not possible for the content of messages to be validated centrally or at message submission time. Where an API Agent is used, the API Agent process does see the unencrypted message content, and this process could therefore reject suspicious or invalid messages, but only a sub-set of messages pass through this channel and in any event, these processes are under the control of individual customers and a bad actor could simply disable these checks.

It is therefore necessary for each and every client, to validate or sanitize message content prior to displaying each message, and this means that there is a need to a) consider carefully what that validation process entails and b) ensure that such checks can be performed in a timely manner on all client devices including web, mobile, API Agent and content export scenarios.

Security Issues

Security exploits through malicious JavaScript on web pages are well documented and widespread. Many approaches are used to mitigate the risk posed by such content and many Symphony customers have extensive perimeter defenses including firewalls and proxies which are capable of inspecting the content of network traffic and blocking dangerous content. The end to end encryption provided by Symphony defeats many of these measures so for example, even if a web proxy has the necessary certificate infrastructure to terminate SSL sessions and inspect their content, the payload of Symphony chat messages remain opaque because they are encrypted at the application level.

It is therefore insufficient to simply rely on customers' existing security infrastructure to protect Symphony users from malicious content.

Vulnerabilities arise unexpectedly from time to time, and were a serious security issue to be discovered in browsers this would require an emergency roll out of a new version which mitigated the new threat. In the case of users of the desktop web client this would presumably be covered by customers' existing security processes, but in the case of users of the Symphony desktop wrapper client, or mobile clients, this would require the rollout of a patched client which customers would currently be reliant on Symphony LLC to provide.

Privacy Issues

Privacy issues with HTML email are similarly well documented. The most obvious case is where a message contains an image which is hosted on a server under the control of the sender of the message and the message content is personalized so that the image URL contains the identity of the recipient. The sender of the message then knows when the message is displayed for each user. Browser finger-printing (see https://panopticlick.eff.org/) could be used to discover details about the identity of other (possibly cross-pod) Symphony users, which would be an issue for some customers.

Usability Issues

Unrestricted use of HTML would allow message senders to do things which on the one hand are uniquely creative and on the other hand destroy the consistency of the user experience for the receivers of those messages. Pop-up windows and browser add-ons to block them are widespread on the web, and while users understand and expect that when they switch from one website to another they will see a distinct user experience, to have the same thing happen from one message to another would be irritating to most users. 

Aside from the issues caused by malicious or badly behaved message senders, since it is clear that not all HTML or JavaScript can be permitted, it will inevitably be necessary for each client to limit the set of formatting which will be supported. It is also clear that not all devices will be capable of rendering everything which all other devices can render, and therefore the rendering of messages will modified in some cases. If the decision as to what to block is left to each client then a message sender will be uncertain as to what the effect of sending a message will be. It therefore seems desirable to explicitly state what features are supported and which are not, and to ensure that all clients are able to render all supported features.

Approaches to HTML Message Support

There are several approaches which could be taken to supporting HTML messages in Symphony. One approach is to select a very limited sub-set of capabilities which we know can be supported on all clients. Over time there is no reason why we cannot extend that subset of supported capabilities. The other approach is to be as permissive as possible and to take the position that everything which is valid HTML5 and CSS should be supported.

The more complex the set of allowable markup is the more complex the code to validate messages becomes and the more complex the rendering (particularly on the mobile clients) needs to be, and the more likely it is that some exploitable capability is included which either leaks information or allows an attacker to compromise the system.