Clipboard policy: the quiet data leak in remote apps

When you move a legacy application behind a browser, the easy win is obvious: the data no longer lives on the laptop. The program runs somewhere you control, and the person only sees a picture of it. It feels like the leak has been closed.

It has been narrowed, not closed. A picture is not the only thing that travels between a person and a remote application. Alongside the stream there are usually two more channels, and they are the ones people forget.

The channels beside the picture

The clipboard is the first. Select a table of customers, press copy, and the text lands on the user's own machine, where it can be pasted into a personal email, a chat or a document nobody is watching. It takes two seconds and leaves no file behind.

File transfer is the second. If people can upload to or download from the remote session, then every file in it can end up on a device you do not manage. That is often the point, for a legitimate export, which is exactly why it needs a rule and not a default.

Where the rule is enforced matters more than the rule

There is an easy way to build a clipboard setting and a hard way. The easy way hides the paste button in the web page. The person who wants to move data out opens the developer tools, or uses a different client, and the setting does nothing.

The hard way is to enforce the rule on the server side of the stream, in the component that actually carries the data. If copy is blocked there, the message never reaches the user's machine, whatever the browser does. When you evaluate any product that streams apps, ask where the policy is applied. The answer tells you whether it is a control or a courtesy.

Deciding the policy

A single organization-wide switch is the simplest thing to explain and usually the wrong thing to ship. The finance application and the internal wiki do not carry the same risk. A sensible approach has three steps:

• Sort your applications by what they hold: public, internal, regulated or customer data.
• For the sensitive ones, block both copy and file transfer by default, and grant exceptions to named roles for named reasons.
• For the rest, leave them open, and spend your attention where the risk is.

Expect friction, and plan for it. People copy between a remote application and their own tools for ordinary reasons. If you block the clipboard with no alternative, they will find a workaround, and it will be worse than the thing you blocked. Give them a sanctioned route, such as an export to a shared location, before you turn it off.

What a policy cannot do

Blocking channels does not stop someone pointing a phone at the screen. You cannot prevent that, but you can make it costly. A watermark with the viewer's identity and the time, drawn into the picture itself, travels with every photo and screenshot. It will not stop a determined person, though it changes the calculation for a casual one and gives you something to act on afterwards.

Also remember that policy is set at a moment. A rule that is read when a session starts applies to that session. Tighten it, and people already connected carry on under the old one until they relaunch. Build that into how you roll a change out.

Whatever you use, write the decision down per application. A one-page table of what each app allows, and why, is the document an auditor will ask for and the one you will want during an incident.