As a remote control application, we recognize the importance of excellent security practices. While we are a small team (currently just 3 founders and a few contractors), we work hard to punch above our weight on security.
Tuple has no employees, but our few contractors sign an NDA before gaining access to sensitive information. Contractors are given the lowest level of privilege required to complete their tasks, which rarely includes access to production data.
At sign-up, each customer is given an invite link to share with their team. Each team member can use that link to set up a new account with their email and password. User passwords are hashed using bcrypt before being stored.
When a user logs in, they are given a 20-byte authentication token, generated with the SecureRandom tool in the Ruby Standard Library. This is valid for 30 days.
All further interaction with the API is done by providing an Authorization header with this token.
All data streams during a pairing session are sent peer-to-peer (avoiding our servers) and are encrypted end-to-end.
When we say "end-to-end", we mean it in the way you'd expect: your data is not (and cannot be!) decrypted by anything other than the clients involved in the call. Stated another way: the only people that can see anything that happens in a pairing session are its participants.
Data channels are encrypted using Datagram Transport Layer Security (DTLS) version 1.2, while video and audio streams are encrypted using Secure Real-time Transport Protocol (SRTP).
All communication between the Tuple client and our backend is encrypted with TLS 1.2. Our backend server is managed by Heroku and uses their Automated Certificate Management service. User data is stored in Heroku Postgres and details of their implementation can be found here.
Metadata about app usage and pairing sessions are stored in Mixpanel using their API. Details of their security processes can be found in their Security Questionnaire.
All logged-in users are connected to a signaling server using the WebSocket protocol.
When a Tuple client wants to initiate a call, it sends an "Offer" through the signaling server and identifies the recipient of the call. The server then pushes that message to the intended recipient. The user on the receiving end will be prompted with an incoming call and can accept or decline. If the user accepts, the client sends an "Answer" and the peers then negotiate an encrypted peer-to-peer connection. The peers exchange keys directly through an encrypted tunnel. The keys are never sent in plain text and do not pass through our servers.
In most cases, both peers will be able to identify addressable IPs and ports on which to establish a peer-to-peer connection using the STUN protocol. Under some restrictive firewall configurations, this is impossible and traffic must be routed through an intermediate server using the TURN protocol. We use Twilio's Network Traversal Service in this case. These servers cannot decrypt the contents of the data packets, and only route based on the UDP layer. Under no circumstances does video, audio, keystrokes, cursor movements, or clipboard data pass through our servers.
Logs are stored separate from our backend infrastructure in a private CloudWatch area.
These logs are retained for 30 days, after which they are permanently deleted.
Application analytics can be permanently deleted on request.
Both the client and our backend are regularly scanned for dependencies with known security vulnerabilities.
Vulnerable dependencies are patched and redeployed rapidly.
Our backend server is hosted on Heroku, which runs on top of Amazon Web Services.
Amazon's data center operations have been accredited under:
No. Tuple is a screen-sharing app, so we send only the contents of your screen (and audio) during calls, but we never send any complete files over the network. Things on your filesystem stay local. In most cases, video streams are directly peer-to-peer. When using certain firewall configurations we use a relay server, but all data is encrypted end-to-end and cannot be decrypted on that server.
When two peers begin a call, the first step is to exchange keys for encrypting the communication. This happens directly between the peers.
The exchange is encrypted with DTLS (a derivative of SSL). The clients use a self signed certificate (asymmetric-key) based on RSA to exchange the keys they will use.
Thus, the exchange of keys is a) encrypted and b) done directly peer-to-peer. The packets never touch any servers under our control. We cannot intercept the exchange of keys and would see only encrypted data if we tried.
Also, the code that handles this exchange is from WebRTC, which is open-source, frequently audited, and primarily written and maintained by Google's security experts.
We're not in the business of making money off of data. We do collect information about how users are interacting with our app so we can improve the product and provide faster, more effective support when issues arise. These events include:
In addition, the following metadata is collected by Mixpanel:
Users are identified in our system by their email address and are asked to provide a name. We don't attempt to collect any demographic information, and don't log IP addresses on incoming connections.
You are always prompted to accept incoming requests before screen sharing or remote control is possible. The prompt includes the calling party's name and avatar.
Please email us at firstname.lastname@example.org, which will notify us very loudly and we'll get back to you ASAP.
While we'd eventually love to achieve these certifications, we don't hold them at this time.
Great! Please email us and we'll happily update this doc.