We store some basic metadata about Websocket connections that open up to our servers. Specifically, we store originating IP address, user agent, the originating URL of the request, and associated customer and anonymous identifiers so we can match up an incoming request with the customer that has our code snippet installed.
We use this data to display relevant information during a screenshare, such as whether or not the user is connected and online, what kind of browser they’re using, and their IP address derived location.
We also store basic timestamp data associated with these requests, such as the time a request or a screenshare started/ended, as well as some basic performance timings related to a screenshare, such as milliseconds it takes for a screenshare to load, that we monitor to ensure that our product is performant.
Our screensharing software will transmit web data in realtime between the client and the agent viewing the client’s screen, and we leverage Websockets to transmit this data. None of the screensharing data that is transmitted gets stored or saved to our servers/databases. We also don’t output detailed logs of screensharing or capture logging associated logging data. Just basic timestamp and origin data, as said above.
We use pretty standard encryption to authorize agent-side websocket connections, routing all data via SSL on both the agent and the client and using HMAC 256 signed tokens to grant access to a screensharing session that matches the same customer information.
Our screensharing client will automatically exclude iFrames from broadcasting, which handles most third party hosted payment forms like Stripe and Braintree, but we also have class and data selectors you can add to inputs or forms which will ensure no data ever leaves the client’s browser. Additionally, we have configurable options in our application that allows you to target CSS classes on inputs and forms that will disable replication on those elements, preventing any sensitive info from ever leaving the client’s browser without having to do any code changes.
Currently, we store this associated metadata for the length of a customer’s tenure with Median, and can delete it upon request.
Median is hosted on Microsoft Azure, which handles the management of our infrastructure for us, and we rely on a central RDBMS (We are fans of Postgres) to hold all of our information.