Security

1. Consent is decided on the customer's machine

The decision to share a screen is made and enforced by the program running on the customer's computer, not by our server. Our side passes the question along and records the answer. There is no instruction we can send that turns sharing on, and no support request we could be persuaded to action that would do it either. If the person at the keyboard does not say yes, nothing is sent.

Looking and controlling are two separate questions. Allowing a technician to see a screen does not let them type or click, and a request for control before sharing has been allowed is refused outright.

2. What the customer can see, and stop

• A banner is on screen for the whole session, carrying the technician's name and the company they work for. It cannot be dismissed.
• Stop is in that banner, and it ends the session immediately from their side.
• The tool removes itself when the session ends. Nothing is left running or installed on a machine that was only visited.

3. The traffic

Screen images and the keyboard and mouse input sent back travel directly between the technician's browser and the customer's computer, encrypted end to end. Where a direct connection cannot be established, the traffic is relayed through our infrastructure, and in that case the relay carries ciphertext it has no key for. We do not have a copy of the picture at any point, in transit or at rest, and we do not record sessions.

4. The record

Who asked, who allowed, whether control was granted and when the session ended are written into the conversation as they happen, and that record cannot be edited or removed by anyone using the product, including the organisation that owns it. Connections to managed devices, where nobody is at the keyboard, are recorded the same way.

5. The software on the customer's computer

Installers are signed, and the signature stays valid when an organisation's branding is applied, because branding is applied at download time rather than by rebuilding the program. A customer checking the publisher of the file they have been asked to run sees a signature that verifies.

6. Accounts

• Passwords are hashed, never stored in a form we could read.
• Sign in with Google is available, and email addresses are verified before an account can do everything.
• Accounts are for named people, so the record of who did what means something.

7. Where it runs

The database is in Zurich, Switzerland. Signalling and the relay run on Cloudflare's network. Section 6 of the privacy policy lists every processor and what each one does.

8. What we have not done yet

We hold no security certifications. There has been no third party penetration test. This is a new product, and saying otherwise on a page like this one would be the least trustworthy thing on it. When either of those changes it will be stated here with a date.

9. Reporting a vulnerability

Write to security@livedesk.sh with enough detail to reproduce it. We will acknowledge within response time and keep you informed until it is closed. We will not pursue anyone who reports a genuine issue in good faith and gives us a reasonable opportunity to fix it before publishing.