Security & encryption

A remote session shows someone's screen and lets you work on their computer. ShareDesk is built so that only the two computers in the session can see it, the customer decides who gets in, and every step can be checked.

1. End-to-end encryption

Every session is encrypted from end to end with the open standards also used by video-call services (WebRTC). It's always on and can't be switched off:

• The screen travels as an SRTP stream encrypted with AES-GCM; the keys are agreed directly between the two computers via DTLS.
• Everything else – mouse and keyboard, clipboard, chat, sound, file transfers, the terminal and tunnels to other devices – travels in DTLS-encrypted channels of the same connection.
• The keys exist only on the two computers. They are created anew for each connection and never sent to our server or to a relay.

2. What our server does – and doesn't

Before two computers can talk directly, they need to find each other. That is the only job of our server:

• It passes on the connection request: the technician's name, company and photo, and the IP address the request came from, so the customer can decide.
• It passes on the technical details both computers need to reach each other. They are deleted as soon as they've been picked up; anything left over is removed within minutes.
• All of this runs over HTTPS. A ShareDesk ID can only be used by its own computer, so nobody can pose as someone else.
• It never receives the session itself: no screen, no input, no files, no chat.

When a network doesn't allow a direct connection, the session goes through a relay. A relay only forwards the already encrypted data; it has no keys and can't read it.

3. Verified devices and the security code

Encryption is only worth as much as the certainty that you're talking to the right computer. ShareDesk checks this itself:

• Every ShareDesk installation has its own device key (ECDSA P-256), kept in the Mac's keychain or, on Windows, protected by the system.
• At the start of every session, both computers sign this very connection with their device key, inside the encrypted channel. A computer that can't prove its key doesn't get a session.
• Known computers are remembered. If a known ShareDesk ID suddenly shows up with a different key, the ShareDesk app ends the session instead of continuing silently.
• Both sides show a six-digit security code. If it's the same on both screens, nobody is in between.

In the web viewer the connection is encrypted the same way, but a browser has no device key of its own. Such sessions are marked “unverified (browser)” on the customer's computer.

4. The customer decides

• Every request is shown. The customer sees the technician's name, company and photo, the ShareDesk ID and where the request comes from, and picks what the technician may do. “Accept” only becomes active after a moment and can't be triggered with the Return key, so nothing is accepted by accident. Unanswered requests disappear after 60 seconds.
• Seven separate permissions: control, clipboard, files, sound, privacy screen, terminal and tunnels. Each can be turned off before or during a session; without “control” the technician can only watch.
• Always visible. During a session a banner shows who is connected, with an End button and a button to hide the screen. If the technician records the session, the banner says so.
• Block and limit. IDs can be blocked; allow and block lists accept IDs and IP addresses. Repeatedly dismissed requests from the same ID are held back by the server.
• Only an unattended-access password, a one-time password or a technician the customer chose to trust skips the question – see below.

5. Unattended access

To reach your own computers without anyone at the screen, you set a password on them. ShareDesk never sends this password:

• The computer doesn't keep the password itself, only a value derived from it, in its keychain, readable on that device only.
• To connect, the technician's app answers a random one-time challenge (HMAC-SHA256) and so proves that it knows the password without revealing it. A proof can't be replayed and is bound to the encrypted connection.
• After five wrong passwords or codes, the ID is locked for ten minutes.
• Two-factor codes (TOTP, as with authenticator apps) can be required in addition; each code works only once.
• At the login window after a restart, only the screen and control are available – no files, terminal or tunnels.
• Optionally the Mac locks itself when the last session ends.

If you save an unattended password in your address book while signed in, the derived key is stored with your account and shared with the colleagues you share that computer with, so they can connect too. Use a strong password and share such computers only with people who should have access.

6. Technician accounts

Accounts are optional; they're for teams that want a shared address book, profiles and a session log.

• Passwords are stored only as a bcrypt hash and need at least ten characters.
• A sign-in is valid for at most 180 days; signing out ends it at once. The server keeps only a hash of it, and the Mac keeps it in the keychain.
• Repeated failed sign-ins are slowed down per address and per account.
• Invitation links expire after 30 days.

7. Signed apps and updates

• The Mac app is signed with an Apple Developer ID, uses the hardened runtime and is notarized by Apple.
• Updates are signed (Ed25519). The app installs an update only if the signature matches our key – on Mac and on Windows.

8. Data and location

• Our servers are operated by MarketVision AG in Switzerland.
• Without an account, the server keeps nothing about your sessions beyond the short-lived connection details above. With an account, it stores your address book, profiles and – if you sync it – your session log; the privacy policy lists everything, including diagnostics reports and how long data is kept.
• The app uses no tracking, analytics or advertising. The website uses Google Tag Manager with a consent banner; the privacy policy describes it.

9. Found a vulnerability?

Please tell us before you publish it: info@marketvision.ch. Describe what you found and how to reproduce it; we'll answer and fix it as fast as we can.