Safety

A remote-access tool hands someone else your computer. Everything below exists to make sure that only happens when you meant it to.

1. Nobody gets in by knowing your number

Your DuoDesk-ID is an address, not a key. Someone who has it can make your computer ask you a question, and nothing else. Every incoming request produces a dialog that:

• names the caller, their ID and their platform;
• lists exactly what they are asking for, each one a checkbox you can turn off before accepting;
• starts on Reject, and counts down to a rejection — an unanswered dialog is a refusal, never an acceptance;
• warns you in plain words when the caller is an ID this computer has never let in before.

2. The unattended password

Set a password and the machine can answer when nobody is sitting at it. This is the one setting that genuinely opens a door, so it is worth understanding how it is handled.

• The password never travels. Your computer stores a salt and scrypt(password, salt) — never the password itself. A caller proves they know it by returning HMAC(scrypt(password, salt), nonce|sessionId) for a nonce that exists only for that one session. Recording the connection on the network gains an eavesdropper nothing, and replaying it later gains them nothing either. Our server relays that exchange and so does see the proof; turning one back into your password means guessing, at a full scrypt per guess, which is why the length below matters.
• Eight characters minimum, and the app refuses the handful of passwords everyone tries first. Twelve or more, mixed, is the real advice — anyone with your password and your ID has your computer.
• Three wrong attempts from an ID and that ID is refused for fifteen minutes.
• Changing the password revokes every reconnect token, which is the only thing "I changed the password" can honestly mean.
• Ask me anyway. A setting that keeps the accept dialog even for callers with the correct password — for a machine other people also use.
• Password only. The opposite setting: refuse every interactive request outright. Nothing to click means nothing anybody can talk you into clicking.

3. Two-factor

A standard TOTP secret you add to any authenticator app. When it is on, the password alone is not enough: the six-digit code is checked on your own machine, with one step of clock drift allowed either way, and a wrong code counts as a failed attempt.

4. Deciding in advance

Under Security → Who may connect, a machine can be switched from "anyone who knows my ID, and I decide each time" to only these IDs. On that setting an unknown ID is refused before anything appears on your screen — nothing pops up, nothing rings, there is nothing to misclick. There is a block list for the reverse case.

5. What a session is allowed to do

Permissions are granted per session and enforced on the machine being controlled, not requested politely by the machine doing the controlling. A viewer that sends a keystroke it was not granted has that keystroke dropped on arrival. You can revoke any of them mid-session from the Sessions list, and the change takes effect immediately:

• control of mouse and keyboard (off = watch only);
• clipboard sharing;
• file transfer — and incoming files land in Downloads, under a name stripped of anything that could point somewhere else;
• reaching services running on this computer — a separate tick, off unless you turn it on. With it, something listening here (remote desktop, a database, a web app) becomes reachable from their machine as if it were local. It reaches this computer only, never anything else on your network: the connection is made to this machine's own loopback address and the only thing they choose is which port. Turning it off closes anything open;
• looking through your folders — its own tick, separate from file transfer, because that has never meant this. File transfer means files may move and whoever sends one chooses which; this means they can see what is here and ask for a file by name. A permission granted before this existed does not quietly become this one;
• choosing where files are saved — a separate tick, off unless you turn it on. Without it the rule above holds absolutely: everything they send goes to Downloads and nowhere else, which is what stops a file being placed somewhere it would be run. With it, they can browse your folders and name one to save into — any folder you could write to yourself. Receiving a file and being told where to put it are two different things to agree to, so they are two ticks;
• audio;
• the privacy screen, which blanks your display for anyone standing next to it while the session runs — a paid feature of the person connecting to you, so a caller whose plan does not include it cannot blank your screen.

6. On the wire

• Media and data ride WebRTC: DTLS 1.2 handshake, SRTP with AES-128-GCM for the picture, SCTP over DTLS for input and files. That is the same transport your video calls use.
• Signalling runs over TLS to duodesk.io.
• Registration is an Ed25519 signature over a server nonce, so an ID cannot be claimed by anyone who does not hold the private key that machine generated.
• TURN credentials, when a relay is needed, are ephemeral — an HMAC valid for twelve hours, never a shared password baked into the app.

7. What the server knows

The rendezvous server introduces two machines and then forwards opaque blobs between them. It stores which ID belongs to which public key, a line per session saying which two IDs talked and for how long, and a ban list. It never sees your screen, your keystrokes, your clipboard, your files, your file names or your password — the first ones because the media and data path is end-to-end encrypted between the peers, and the password because it is checked on your own computer before anything is sent.

What a machine says about itself when it checks in. Alongside its ID and public key, a copy reports the name you gave it — the computer's own name unless you changed it — the operating system it runs on (Windows, macOS, Linux), the version of DuoDesk it is running, and, from 0.7.48, that operating system's version number (12.7.4, 10.0.22631) so we know how many machines a release that needs a newer system would leave behind. The server also derives a two-letter country from the address the connection arrives on and keeps only those two letters — the address itself is used to answer the connection and is never stored. No advertising ID, no browsing of any kind.

From 0.7.56 a machine also reports what it is, so that your own list of computers at duodesk.io/me can tell them apart: processor, memory, how big the disk is and how much is free, the kernel version, the maker, the model, how long it has been switched on, whether its antivirus, firewall and disk encryption are on, and the serial number — which is a hardware identifier, and the reason this is a switch rather than a consequence of installing DuoDesk. It is on by default and it is Settings → List this computer's specification on your account page; turn it off and the machine says so, and what is already stored is deleted rather than left to go stale.

It says nothing about you. No user name, no account you are logged in as, no file, no folder, no network share, and no list of the programs on the machine. It is a description of a piece of hardware, readable by the account the machine is linked to and by an admin of a team it is shared into — the same people who can read its log, because a serial number is what a purchase order and an insurance claim are keyed by.

Waking a sleeping computer, and the one identifier that is involved. If you turn on Tell computers you connect from how to wake this one, this machine hands its network hardware addresses to the computer being connected from — and to nobody else. They travel inside the same end-to-end encrypted session as everything else, the server never sees them, and they are stored in that person's own address book on their own machine. What it buys is a Wake button that switches this computer on again when it has gone to sleep, from the same network. The setting is off-able and lives beside the blanking one; turning it off stops this machine handing the addresses out again, and a computer that already has them keeps them until it removes this one from its list. Nothing about any of this reaches duodesk.io: the sentence above about no hardware identifier is about the server, and it stays true.

Files go the way the picture goes. A transfer rides the same encrypted peer connection, straight between the two computers. It is never uploaded to the server, and there is no copy of it anywhere but the two machines. When both ends sit behind a NAT that refuses direct traffic, the relay forwards the same encrypted packets — it cannot read them, and cannot tell a file from a frame of video.

Uninstalling asks why, and you can decline to answer. The uninstaller asks what went wrong and what to remove. If you leave the Send my answers box ticked, that answer is sent once — before anything is deleted — and it is: the reasons you ticked, up to 200 characters of free text if you typed any, this computer's public DuoDesk-ID, the operating system and processor type, the app version, how it was installed, how many days it had been installed, and which of your own files you asked it to remove. No name, no email, no computer name, no account — there is none to have. The address the report arrives from is used to rate-limit and is not stored with it. Untick the box and nothing leaves the machine; either way, a report that fails to send is dropped in silence and never holds up the uninstall.

Plans, codes and paying. A plan belongs to your account, not to a computer, which is why it follows you onto every machine you sign into. The server keeps which tier that account is on, where it came from — a code you redeemed, a payment, or something we granted by hand — when it started and when it runs out, and a line per code you have redeemed saying which code, on which machine, for how much. Card payments are handled by Stripe, on a page Stripe hosts: your card number, your name and your billing address are given to them and never reach our server. What the server keeps of a payment — Stripe's customer and subscription ids, the plan and its periods, the amount and the currency — is listed on the privacy page. A code redeemed at 100% off needs no payment provider at all and involves nobody outside this server.

8. How long any of it is kept

A policy nobody enforces is a sentence, not a policy, so each of these is a line of code on the server rather than an intention. An hourly sweep does the deleting; the window is ninety days.

• The record that two machines talked — the two IDs, when it started, when it ended and how — is deleted ninety days after it started.
• An abuse report, which is a host saying a caller was guessing passwords, is deleted ninety days after the last time that host complained. A repeat complaint keeps the row alive, because a fresh complaint is fresh evidence.
• What you said on the way out. After ninety days a leaving report loses the DuoDesk-ID it arrived with and whatever you typed in the free-text box — both are erased. What stays is the anonymous part we actually read: the platform, the version, how long it was installed and which reasons were ticked.
• Your machine's own row — its ID, its public key, the name you gave it, its platform and version — is kept for as long as the machine is registered, because it is the registration. Removing it is one button, and the number it held is retired: never handed out again, never honoured again.
• The ban list stays until a ban is lifted. That is its whole job.
• The log of who was on a machine — that two machines were introduced, when, and for how long, plus what the machine itself reports a session did as it ends: how many files moved and which way, how many commands were run, which ports were forwarded, whether the screen was blanked, and what the session was allowed to do. Never what was in any of it. No file name, no command, no keystroke, no clipboard — the server has never seen any of those and this log does not change it. Readable by the account the machine is linked to and by an admin of a team it is shared into, and kept the same ninety days as everything else;
• A team you are in keeps its name, who is in it and which role each of them holds, and which machines have been shared into it. A team shares knowledge of machines, never access to them: connecting to one still needs somebody there to accept, or its password. A member with the read-only role is not shown a machine's sixteen digits at all — without them there is nothing to dial. Leaving a team, or being removed from one, ends that access immediately;
• A Google or Microsoft account you have linked is kept as the provider's own identifier for you and the address it told us, so that signing in with it opens your account and nobody else's. It is a link, never a match: an address alone never opens an account, because an address is a thing companies reassign and a login that followed one would follow it to the next person. Unlinking removes it and that way in with it;
• What a machine says it is — the specification above — is one row per machine, replaced each time the machine reports and deleted ninety days after it last did. Turning the switch off deletes it immediately.
• What is wrong with a machine right now — that it has not been heard from, that its disk is nearly full, that it reports a defence switched off — exists only while it is true. When the machine comes back, or the disk empties, the row is deleted; there is no history of it. These appear on your own page, and at any webhook you set up to receive them, and nowhere else.
• Two-factor on your account, if you switch it on: the secret your authenticator shares with us, and the fingerprints of the ten recovery codes. The codes themselves are shown once and are not stored — we cannot tell you what they were, only give you ten new ones. Switching it off deletes both.
• Keys and webhooks you made yourself. An API key is stored only as its fingerprint — the key itself is shown once and cannot be recovered, only replaced. A webhook is the address you asked us to post to and the secret we sign with. Both are deleted when you revoke them, and a webhook is only ever pointed at the public internet: https only, never a private or local address, and redirects are not followed.
• Your own sign-in to the console at duodesk.io/me lasts twelve hours. It is a random value whose SHA-256 is stored, so the table is worthless stolen, and signing out deletes it. The console shows nothing but the machines linked to the account signing in — the name you gave a machine there and the group you put it in are your own words for it, stored against your account and nobody else's.
• The operator's own sign-in to the dashboard — not yours; there is no account for you to have — lasts twelve hours, a remembered device thirty days, and a half-finished sign-in ten minutes.

Two honest footnotes. The database is backed up once a day and the backups are kept a fortnight, so a row deleted today can survive in a copy for up to fourteen days before it is gone everywhere. And none of this is about your screen, your keystrokes, your clipboard or your files: those never reach the server at all, so there is no retention window to quote — there is nothing to keep.

Your own session log is a separate thing entirely. It lives on your machine, in the app, under Sessions, and is never sent anywhere.

9. What the operating system still controls

On macOS, DuoDesk cannot show your screen without Screen Recording and cannot be controlled without Accessibility, both granted by hand in System Settings → Privacy & Security. The app says so on its front page when either is missing, and a caller trying to connect to a machine that cannot capture is refused with that exact reason rather than left staring at a black rectangle. On Wayland, capture goes through the desktop portal and may ask each time.

10. If you think someone is in your computer right now

1. Open DuoDesk and press Disconnect on the live session, or quit DuoDesk from the tray — either ends it instantly.
2. Disconnect the network cable or turn off Wi-Fi if you cannot reach the app.
3. Change the unattended password. That revokes every reconnect token that was ever issued.
4. Add their ID to the block list; it is written in your Sessions log next to the time they connected.
5. If they touched anything financial, call your bank from a different device.

Found a security problem in DuoDesk? Say so before you say it anywhere else — the app and this site are maintained by one person and a real bug will be fixed rather than argued with. The address is on the contact section, and the machine-readable copy of this paragraph is at /.well-known/security.txt.