Tuple’s Security Details

As a remote control application, we recognize the importance of excellent security practices. While we are a small team, we work hard to punch above our weight on security.

This document covers our security practices and policies. If you are interested in the data we collect and store, please see our privacy policy.

General practices

Access to servers, source code, and third-party tools are secured with two-factor auth.
We use strong, randomly-generated passwords that are never re-used.
Employees and contractors are given the lowest level of access that allows them to get their work done. This rarely includes access to production systems or data.
We use automatic security vulnerability detection tools to alert us when our dependencies have known security issues. We are aggressive about applying patches and deploying quickly.
We don’t copy production data to external devices (like personal laptops).

Access control and organizational security

Personnel

Our employees and contractors sign an NDA before gaining access to sensitive information.

We perform a penetration test through a third party annually. The latest assessment concluded that “the security posture of the Tuple platform was found to be in line with industry’s best practices.” If you’d like a full copy of the results, send us an email.

Authentication

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. The token is invalidated after 30 days of inactivity.

All further interaction with the API is done by providing an Authorization header with this token.

Media Servers

Tuple hosts our own media servers in multiple regions on AWS:

us-east-2 (Ohio, USA)
us-west-2 (Oregon, USA)
ap-southeast-2 (Sydney, Australia)
eu-west-3 (Paris, France)

Media servers are only used when 4 or more participants are on a call. They are responsible for relaying end-to-end encrypted audio and video data.

Encryption

Definitions

Data - Clicks, keystrokes, drawings, animations, etc.
Media - Video (webcam and screenshare) and audio

All data and media during a 2 or 3-person pairing session are sent peer-to-peer (avoiding our servers) and are encrypted end-to-end.

All data during a call with 4 or more participants are sent peer-to-peer. Media is sent end-to-end encrypted and relayed through our media servers.

When we say “end-to-end”, we mean it in the way you’d expect: your data and media 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 in peer-to-peer connections are encrypted using Datagram Transport Layer Security (DTLS) version 1.2, while media streams are encrypted using Secure Real-time Transport Protocol (SRTP).

When there are 4 or more participants on a call, encrypted media streams are relayed through our servers using SRTP. Each frame in the stream is encoded using AES-256 encryption. Keys are randomly generated by each participant and are never reused. Keys are exchanged using peer-to-peer data channels over DTLS. We do not store any user media on these servers. Our servers never have access to the keys and cannot decode any media.

All communication between the Tuple client and our backend is encrypted with TLS 1.2. User data is stored in Amazon RDS with encryption at rest using AES-256. Details of their encryption 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.

Data flows

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 connection. The peers exchange keys directly through an encrypted tunnel. The keys are never sent in plain text.

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 Cloudflare’s Calls TURN 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 when using the TURN protocol.

Architecture diagram

Tuple topology

Local capture

Tuple can capture what happens on a call — a transcript of what’s said, recordings of any screen that gets shared, the annotations drawn on those screens, and metadata about the apps visible on them. We built the feature so that all of it happens on your own machine. Capture is currently only available on macOS.

Capture is off until you turn it on. You can toggle it on during a call like any other call control, or have it start automatically when you join one. It’s all managed in your capture preferences.
Participants are notified. When you start capturing, every other person on the call receives a notice, and each capturing participant carries a Capturing indicator in call participant lists for as long as it’s active. Joining a call that’s already being captured raises the same notice.
Transcription runs entirely on-device. Spoken audio is converted to text by a Whisper speech-to-text model running locally on your computer. The first time you capture a call, the app downloads the model from our servers and verifies it against a SHA-256 checksum; after that, no audio or transcript is ever sent to us to perform transcription.
Nothing captured is uploaded. The transcript, screen recordings, annotations, and app metadata are written only to a database on your machine — they are not stored on, synced to, or accessible by Tuple’s servers. (During calls with 4 or more participants, end-to-end encrypted media is relayed through our servers as described above, but it cannot be decrypted by us or used for capture.)
Audio is transcribed, then discarded. Normally audio is transcribed in memory and never written to disk. The one exception stays local: if no transcription model is loaded when someone speaks — the model is still downloading, say — that snippet of audio is held in the same local database so it can be transcribed on-device afterwards, and is deleted as soon as its text exists. Either way, it is never uploaded.
Recordings can be configured to expire. Screen recordings are a working buffer for the call, not an archive. Tuple sets a maximum screen recording cache size (which you can configure), deleting the oldest first. You can also set whole capture sessions to be deleted after a given time. Deleting a capture session permanently removes its transcript, recordings, annotations, and app metadata from your local database, with no server-side copy to clean up.
The store is protected by your machine, not by a key we hold. Captures live in a single SQLite database under your user account, in ~/Library/Application Support/. We have no key to it and no way to read it — and by the same token it is only as protected as the disk it sits on, so we recommend running with FileVault enabled.

App metadata in a capture

If a sharer turns on Share app metadata, the window title and content URL of their focused app are sent to the people on the call over the same end-to-end encrypted data channel as the rest of the call’s data (never to us) and are stored by anyone who is capturing. The sharing machine scrubs those values before they leave it: sign-in and OAuth URLs are dropped outright, credentials are stripped out of the URLs that do get sent, and secrets recognized inside window titles are replaced with •••. Apps hidden by App Veil share nothing at all. That scrubbing is a curated set of heuristics rather than a complete secret detector — see Sharing app metadata for the exact rules and their limits.

Agents, the CLI, and triggers

The same local-only guarantees apply to our command-line interface (CLI) and MCP server. The tuple CLI talks to the desktop app over a local socket on your machine (there is no network call to our servers) and access is gated behind an explicit authorization that you grant, and can revoke, in the app; the decision itself is stored in your macOS Keychain. Tuple also fires local call-capture-started and call-capture-complete triggers, which run scripts you install yourself.

If you choose to connect an AI agent to a live call, or write a trigger that ships a transcript somewhere, that content goes wherever you point it. That’s your decision, not something Tuple does on your behalf.

Data Retention and Logging

Server and application logs are retained in hot storage for 30 days in BetterStack, after which they are archived to cold storage in Amazon S3 for two years before permanent deletion.

Software development practices

Code written by any developer is signed off by at least one other person before committing.
Code is tested in a staging environment against a QA checklist before deploying to production.
The Tuple client is code-signed with our Apple developer ID and has the Hardened Runtime mode enabled (which protects against code injection, DLL hijacking, and process memory space tampering).
The Tuple client is automatically scanned for malware and notarized by Apple on every deploy. See Apple’s notarization service for details.

Vulnerability detection

Both the client and our backend are regularly scanned for dependencies with known security vulnerabilities.

Vulnerable dependencies are patched and redeployed rapidly.

Hosting

Our backend infrastructure is hosted on Amazon Web Services (AWS).

Amazon’s data center operations have been accredited under:

ISO 27001
SOC 1 and SOC 2/SSAE 16/ISAE 3402 (Previously SAS 70 Type II)
PCI Level 1
FISMA Moderate
Sarbanes-Oxley (SOX)

FAQs

Does my code pass through your servers?

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, media streams are directly peer-to-peer, but with 3 or more participants they may be routed through our servers. If you enable Share app metadata, the titles and URLs of the windows you focus while sharing are sent to the other people on the call over the end-to-end encrypted data channel — never to us — after your machine scrubs credentials out of them.

Does anything Tuple captures from a call reach your servers?

No. Capture runs entirely on your own machine: speech is transcribed by an on-device model, and the transcript, screen recordings, annotations, and app metadata are stored only in a local database on your computer. None of it is uploaded, synced, or readable by us. See Local capture above for the details.

How are keys exchanged between clients?

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.

What user data do you collect?

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:

Sign-In and Sign-Out events
Interaction with features of the app (e.g. mouse modes, switching hosts)
Crashes and other errors
Changes in network availability status
Changes in connectivity state with our backend server and peers
Calls made
Whether Capture was used, and which settings it ran with; never the transcript, recordings, annotations, or app metadata a capture produced

In addition, the following metadata is collected by Mixpanel:

The version of the Tuple being used
The user’s operating system version
The user’s display dimensions

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.

Does the app automatically accept inbound calls, or does it prompt you first?

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.

How do I report a potential vulnerability or security concern?

We are continually engaged with a team of researchers in a private bug bounty program and therefore do not provide compensation for independent reports. However, if you have a concern please email us at security@tuple.app, which will notify us very loudly and we’ll get back to you ASAP.

$3M cyber liability (each occurrence)
$3M errors and omissions (each occurrence)
$1M general commercial liability (each occurrence)
$6M umbrella liability (each occurrence)

Any further questions?

Great! Please email us and we’ll happily update this doc.