Security Statement

1. The design principle

A remote-desktop product handles the most sensitive thing on a computer: the screen, and everything typed into it. The only durable way to protect that is not to be in a position to see it.

So DeskTunnel is built so that Trendifyr Tech (Private) Limited is not a party to the encryption of a session. Our servers introduce two devices to each other and then step out of the path. Everything after that is between the two endpoints.

This is a property of the architecture rather than a promise about our conduct, which is the distinction that matters: a promise can be broken, compelled or changed by a new owner, and a key we never had cannot be produced.

2. How a session is protected

• TLS 1.3, end to end. Every session is encrypted between the controlling and the controlled device.
• A fresh certificate per session. Each device generates an ephemeral certificate for each session rather than reusing a long-lived identity.
• Mutual certificate pinning. Each endpoint is told the fingerprint of the other through the coordination channel and verifies it at the handshake. A certificate that does not match is rejected — the session does not proceed.
• Session resumption is disabled, deliberately. Windows shares TLS session tickets machine-wide, and a resumed session skips the certificate check. Turning resumption off costs a fraction of a second at connect and closes that hole; we would rather pay it.
• Interception is visible. A middlebox that re-signs traffic fails the pin. The session is refused and the issuing certificate authority is written to the Windows event log, which is usually how somebody discovers their antivirus is inspecting TLS.

Consequently we cannot read screen contents, keyboard or mouse input, clipboard data, transferred files, audio or chat messages — and nor can anybody who compels, compromises or buys us.

3. Transports

Three transports are attempted in order, and the first that works is used:

1. QUIC, directly between the devices, with its own ALPN identifier and separate streams for control and video, so a large frame never delays a keystroke.
2. TLS 1.3 over TCP, directly between the devices.
3. A TURN relay, only if neither direct transport can be established.

The protection described in section 2 is identical on all three. Falling back to a relay changes the path, not the encryption.

Control messages and frame data are carried in a defined framing format, and every writer of a stream holds that stream’s single write lock, so frames cannot interleave and corrupt one another.

4. Relays

A relay — ours or one running on another user’s device — forwards bytes it cannot decrypt. It holds no key and is given none.

A relay necessarily observes, as any network intermediary does:

• the addresses of the two endpoints;
• the volume and timing of traffic;
• the duration of the connection.

It does not observe content. The full position, including when your own device may act as a relay and how to opt out, is in the Network Participation Terms.

5. Unattended access

A session with nobody present at the far end is allowed only by one of two deliberately separate routes: the organisation has marked the device unattended and the access grants admit the caller, or the device’s own setting allows it. Neither can be enabled by accident.

• The password never travels. It is stored as a PBKDF2-SHA256 hash with a random per-device salt. The caller proves knowledge with an HMAC over the session identifier, bound to both addresses. The refusal doubles as the challenge, so no extra round trip is added to a connection that does not need one.
• Escalating lockouts. Three wrong passwords and that network waits five minutes, then fifteen, then twenty-four hours. The ladder is remembered between locks and persisted across restarts.
• The lockout is keyed on the observed address. The relay stamps the caller’s public address from the socket; the caller’s own claim about who it is never used for this.
• Identity is proved twice. The coordination hub takes the caller’s address from the device token on the connection, never from the message, and rewrites the field the far end reads before forwarding it.
• Connect grants. An organisation can require a short-lived ES256 statement, minted by the management API, that a named person signed in at that moment may open this session on that device. The device verifies it offline, so an unreachable server never locks an estate out, and remembers its identifier so it cannot be replayed.
• The decision is local. A device polls its access policy periodically and decides for itself. A session costs no extra round trip, and turning access off is noticed within about three minutes.

One honest note. Where unattended access is enabled by a device’s own setting with an empty list of permitted addresses, anybody who knows that device’s address can connect to it. The software says so at the point of configuration, in as many words.

6. Permissions inside a session

What a session may do is granted by the person at the controlled device and can be withdrawn mid-session. Control, clipboard, file transfer, audio, elevation and input locking are separate permissions.

An organisation’s session policy sets a ceiling that cannot be raised during a session. It is checked twice — by the Windows service before it forwards a grant, and by the session component before it acts on one. Revoking a permission is never blocked by a policy.

Capabilities are pre-granted only where the organisation vouched for the caller. Where somebody at the device accepted the session, or where the device’s own switch allowed it, the caller asks for permissions as normal — because accepting a session is agreeing to let somebody in, not agreeing to hand them the lock screen.

7. Accounts and tenancy

• Account passwords are hashed with bcrypt. We cannot recover one; we can only reset it.
• Every query in the management API is scoped to one organisation. A query that could cross that boundary is treated as a security defect, not a bug.
• Roles are built from a catalogue of granular permissions rather than a few fixed levels. Access grants resolve predictably: a deny beats an allow, lower priority wins, then the more specific target.
• Management actions are written to an audit log, retained for the period of the plan.
• Sign-in attempts are rate-limited and accounts lock after repeated failures.

8. Infrastructure

• All connections to our servers are encrypted in transit.
• Database access is parameterised throughout; no query is built by concatenating user input.
• Access to production data is least-privilege within our team and is logged.
• Backups are taken regularly and restoration is tested.
• Local application settings are stored encrypted on your own device.
• We never see your card. Payment details go directly to SafePay’s hosted page; we receive a reference and an amount.

9. What this does not protect against

This is the section we would read first. No design protects against everything, and a security page that implies otherwise is not worth reading.

• A compromised endpoint. If malware is running on either computer, it can see the screen before we encrypt it and the keystrokes after we decrypt them. End-to-end encryption protects the link, not the ends.
• Somebody you let in. The most common failure is not technical: it is a person who was persuaded to grant access. See section 4 of the Acceptable Use Policy.
• A weak unattended-access password. Lockouts slow an attacker down. They do not rescue a password of “1234”.
• An empty allow-list. As set out in section 5, that configuration means anybody who knows the address can connect.
• Traffic analysis. We encrypt content, not the fact that a connection happened, its timing or its volume.
• Your own administrators. If you use DeskTunnel through an organisation, its administrators can see which devices you connected to and when. That is what a management dashboard is for.
• Physical access. Somebody at the keyboard of either machine does not need us.
• Our own mistakes. We write software, and software has defects. Which is what section 10 is for.

10. Reporting a vulnerability

If you have found a security problem in DeskTunnel, please tell us at [email protected]. We would far rather hear it from you than read about it later.

Please include:

• what the issue is and where — a component, a URL, a version;
• how to reproduce it, in enough detail that we can see it ourselves;
• what an attacker could achieve with it;
• how you would like to be credited, if you would.

What we will do:

• acknowledge your report within three (3) business days;
• give you an initial assessment within ten (10) business days;
• keep you informed while we work on it, and tell you when it is fixed;
• credit you publicly if you want that, and not if you do not.

We ask that you give us a reasonable opportunity to fix an issue before disclosing it publicly. We suggest ninety (90) days, and we will say so if we need longer and why. We do not operate a paid bug bounty at present. We would rather say that plainly than imply one exists.

11. Safe harbour

We will not pursue legal action against you for good-faith security research conducted within these boundaries, and we will take steps to make it known that your research was authorised if a third party raises it with us.

Those boundaries are that you:

• test only against your own accounts, devices and data;
• do not access, modify, destroy or retain data belonging to anybody else, and stop immediately and tell us if you encounter it;
• do not degrade the Service — no denial-of-service testing, no load testing, no spam;
• do not use social engineering, phishing or physical attacks against our staff, our users or our premises;
• give us a reasonable period to remediate before publishing;
• comply with the law.

If you are unsure whether something is in scope, ask us first at [email protected]. We will answer.

This is not an abuse channel. If somebody is misusing DeskTunnel against you, see section 8 of the Acceptable Use Policy.

12. Contact

Trendifyr Tech (Private) Limited
Pakistan
Security: [email protected]
Privacy: [email protected]

This statement describes the Service as at the date above. It is a description, not a warranty: the warranties and disclaimers that apply are in section 17 of the Terms of Service.