Consent-first remote support in the browser

June 2, 2026 · 9 min read

Helping someone with a computer problem usually means one of two extremes: either you talk them through every click over the phone, or you install heavyweight remote-desktop software that quietly keeps access long after the call ends. The Remote Support tool on UtilityTools.eu aims for a calmer middle ground — real help, including moving the mouse and typing on the other machine, but built so the person receiving support stays in control of every step.

This article explains what the feature does, how the pieces fit together, and — because it is the part that matters most — exactly how the security model works.

What it can do

Screen sharing — the customer shares their screen so the agent can see the problem.
Voice and chat — talk through the issue without a separate phone call, or type messages.
Full-screen viewing — the agent can expand the shared screen edge-to-edge for detailed work.
Real mouse & keyboard control — with a separate approval, the agent can actually move the cursor and type on the customer’s computer.

Screen sharing, voice and chat all run in the browser using WebRTC — no installation needed. The one thing a browser tab physically cannot do is move your real operating-system mouse or press real keys, so that single capability is handled by a tiny optional Desktop Helper the customer downloads and runs only when they want hands-on control.

How a session flows

The customer opens Remote Support and starts a session. They choose a password and receive a one-time code (formatted like ABCD-EFGH).
They give the agent the code and password. The agent enters both to request to join.
Nothing is shared until the customer approves the join.
The customer separately decides whether to share their screen.
If hands-on help is needed, the customer downloads the Desktop Helper, runs it, and pairs it with a 6-digit code shown in its window — then grants remote control as a distinct, revocable approval.
When finished, either side ends the session and everything is torn down.

The security model

Remote control of a computer is exactly the kind of capability that deserves real scrutiny, so the design assumes the question every careful user asks: “Can someone use this to get into my machine without me wanting it?” The honest, detailed answer is below. The short version: access only exists because the customer creates it, every sensitive step needs a separate approval, and there is no unattended or silent reconnect.

1. The customer creates access — there is no standing door

A session does not exist until the customer starts one. There is no always-listening service waiting for an agent to dial in. The agent cannot initiate anything; they can only join a session that the customer deliberately created, using a code and password the customer chose and handed over out-of-band.

2. Two secrets, single-use, with brute-force limits

Joining requires both the one-time code and the password. The password is never stored in clear text — only a salted hash, compared in constant time. The code is single-use: the moment it is claimed it is burned, so it cannot be replayed. Wrong-password attempts are counted, and too many lock the code entirely, which stops guessing attacks.

3. Layered approvals you can revoke instantly

Seeing the screen, sharing audio, and controlling the mouse/keyboard are separate permissions. Approving a join does not start screen sharing; sharing the screen does not grant control. Remote control is its own explicit toggle, and the server drops control input the instant the approval is not active. Revoking is immediate — the agent’s clicks simply stop being delivered.

4. The desktop helper is loopback-only and cannot be reached from the network

This is the part people worry about most, so it is worth being precise. The Desktop Helper:

Listens only on 127.0.0.1 (localhost) and explicitly rejects any connection that is not from the local machine. It is not reachable from the internet or the local network.
Makes no outbound connection to the agent. The agent never connects to the customer’s computer. Instead, the customer’s own browser tab talks to the helper locally, and the agent only ever talks to the relay server.
Requires a 6-digit pairing code — shown only in the helper’s own window — before the browser may send it anything. A wrong code is refused.
Injects input only while the control gate is on, which mirrors the customer’s server-side approval. It also auto-disables after 30 seconds of silence.

In other words, there is no “reverse connection” an outsider can dial into. Even a program already running on the customer’s own machine would still need the pairing code and an active approval to do anything — and if hostile software is already running locally, it has far easier options than this narrow, gated path.

5. No unattended access, and everything expires

If the customer closes the tab or disconnects, the session ends — there is no silent reconnect and no saved credential to come back through. Sessions also time out automatically after a period of inactivity and have a hard maximum duration. Because session state lives in memory and dies with the session, there is nothing left behind to reuse afterward.

6. Stopping is always one action away

Any one of these halts input immediately: clicking Revoke remote control or Stop support in the browser, closing the helper window, pressing Ctrl+C in it, or simply doing nothing for 30 seconds. The customer never has to “find the right button” in a panic — multiple independent off-switches all work.

7. Auditability

Each session keeps an activity log of the meaningful events — when an agent joined, when control was approved, when it was revoked, when the session ended. The customer can see this trail, so the session is transparent rather than a black box.

Honest limitations

No tool should pretend to be magic, so here are the real edges:

WebRTC reveals IP addresses. Screen and voice are peer-to-peer, so during an approved session each side may learn the other’s public IP. Routing media through a relay (TURN) can hide this if needed.
Social engineering is the real risk, not the network. The dangerous scenario is tricking someone into starting a session and reading out their code — which is why the tool repeatedly reminds customers to only do this with a person they actually contacted for help.
The helper is unsigned today. Windows may show a SmartScreen prompt the first time it runs. That is a trust/UX issue, not a remote-access hole; code signing removes the prompt.
Trust still matters. While you grant control, the agent can act on your machine. The protections limit when and whether that happens — they cannot replace choosing who you let in.

Why this design

Traditional remote-desktop tools optimise for the technician: install once, connect anytime. That is convenient for IT departments but uncomfortable for everyday users who can’t tell whether access really ended. This feature flips the priority. It is slightly more work to start — a code, a password, explicit approvals — and that friction is the point. It makes “I am temporarily letting this specific person help me right now” the only thing that can happen.

How to use it

Open Remote Support and start a session; set a password and share the code with your helper.
Approve the join when they request it, then choose whether to share your screen.
For hands-on help, download and run the Desktop Helper, type its 6-digit code into the page, and approve remote control.
End the session — or just close the tab — when you’re done.