Skip to content
Anslation

How a session stays in the right hands.

One-time codes, consent, roles and an audit log, with the screen going straight between two browsers. Here is how each part works, the optional device agent included, and what Anslation Remote does not do.

Six parts, each one checkable.

Codes, consent, approvals and roles are checked on the server, so a page or a script cannot skip them.

  • One-time codes

    Made on the server, shown once, kept only as a keyed hash, valid once for 15 minutes. Each network address gets 10 join tries a minute.

  • Consent

    When the policy asks, the person you help allows or declines the session on the join page before anything is shared.

  • Approvals

    Policies can require an admin, or an approver who is not the operator who started the session.

  • Roles and workspaces

    Owner, admin, operator and auditor. Anything in a workspace you are not part of answers as not found. One exception: Anslation’s platform owner account can open any workspace as an owner, and every step it takes there is written to that workspace’s audit log.

  • Peer-to-peer screen

    The screen goes from browser to browser over WebRTC, which encrypts media in transit. Anslation relays only the connection messages.

  • Audit log

    Every change writes one entry, and so does each export of the audit log or the file transfers. Chat and pointer notes stay with their session as its own history.

The optional device agent.

A screen session only shows a screen. The agent is the one part that acts on a computer, so here is exactly what it runs, when, and what is kept.

  • Terminal commands, with the user’s rightsIt enrolls with a token an admin creates. On a managed device it reports the device’s status and runs the commands an operator sends in a terminal session, with the rights of the user account it runs as. It has no screen-sharing, file-transfer or clipboard feature of its own; a command can do anything that account can.
  • When it may runA terminal session with someone at the device waits for an admin to approve it; their consent alone never starts one, and its commands run only while that person is on the join page. With nobody there, the device must be set for unattended access and covered by an access rule, and the rule decides whether the session starts at once, waits for an admin, or waits for an admin who did not open it.
  • Refused, and keptCommands that match a destructive pattern, such as a recursive delete, a disk format or a shutdown, are refused. Every command an operator sends, refused or not, and every output the agent sends back stay in the session history, each with an entry in the audit log.
  • No two-step sign-in yetAn access rule’s two-step sign-in (MFA) setting is stored but not asked for: an operator opens an unattended terminal session without one.

What it does not do, yet.

Each gap below is labelled in the product as well, so nobody relies on something that is not there.

In place today

  • Screen sessions are view-only: no keyboard or mouse input reaches the other computer
  • Consent and approvals checked on the server
  • Join tokens for the person you help kept only as keyed hashes
  • Connection messages deleted when a session ends
  • Audit export to CSV for your own reviews

Not done

  • No keyboard or mouse control
  • No video of the session is kept
  • No file transfer: file requests are approval entries only
  • No shared clipboard
  • The two-step sign-in (MFA) setting of a policy or an access rule is stored, not enforced yet
  • No TURN relay unless the deployment adds one

Network notes.

What leaves the two browsers during a session, and where it goes.

  • STUN, and who runs itTo find a direct path, each browser asks public STUN servers run by Google for its public address. No screen data goes to them.
  • TURN, for strict networksSome office networks block direct connections. A TURN relay can carry the encrypted media instead; it is set up per deployment and is not on by default.
  • Signalling through AnslationOffers, answers and network candidates pass through Anslation so the two browsers can find each other. They are deleted when the session ends; before that, any older than about an hour are deleted within a minute or so, except the screen share’s own offer, which an open session keeps so the console can pick the share up again.

Check a network before a session

The screen share check asks the same STUN servers and says whether a direct path is likely.

Safety questions, answered.

Is screen sharing safe?

It is as safe as the person you share with. Share only with a support team you contacted yourself, pick one window instead of the whole screen when you can, and stop sharing when you are done. With Anslation Remote the screen share is view-only, and the session lands in the team’s audit log.

Screen share karna safe hai?

Yes, if you share only with a support team you contacted yourself. Never type a password, OTP or UPI PIN while your screen is shared, and stop sharing as soon as you are done.

Can the support agent see my passwords?

They see whatever shows on the screen or window you share, including anything you type that appears on it. Close other windows first, and never type a password, OTP or PIN while sharing.

Is the session encrypted?

The screen travels over WebRTC, which encrypts media in transit, and the chat and connection messages go over HTTPS.

Does Anslation keep a copy of my screen?

No. The screen goes from your browser to the agent’s browser and is not stored. The chat, the approvals and the session timeline are kept for the support team.

Where do I report a vulnerability?

Use the responsible disclosure page, or the contact listed in the security.txt file under /.well-known on this site.

Questions before a security review?

Tell us what your team needs to check before using Anslation Remote. We read every request and reply by email.

Office hours: Monday to Saturday, 10:00–18:00 IST+91 74158 85838