[Change]: Ability to forbid copy and paste

[edwardchalstrey1]

Summary

The percentage splits of responses to the SATRE survey questions copy/paste when logged into a TRE.

Source

SATRE specification survey responses

Detail

Survey results:

6.1.a. From inside to outside

No opinion	Not important	Nice to have	Important	Essential
7.62%	6.67%	3.81%	15.24%	66.67%

6.2.a. From outside to inside

No opinion	Not important	Nice to have	Important	Essential
5.71%	23.81%	14.29%	21.90%	34.29%

Where

TRE required features and TRE optional features

Proposal

• Include forbidding copy/paste from inside to outside in the 'required' features of the TRE specification
• Despite less consensus on importance, include forbidding copy/paste from outside to inside in the 'required' features of the TRE specification too

Who can help

Anyone

Specification section

https://satre-specification.readthedocs.io/en/latest/pillars/computing_technology.html#user-interface (see #110)

[drchriscole]

We've had a fair few discussions about this in hIC and it boils down to the fact that it's technically almost impossible to block paste into a TRE.

[zwelshman]

Interesting finding @drchriscole a couple of TREs do facilitate pasting into, or have a data in facility.

[JimMadge]

@drchriscole Do you mean, for example, emulating keyboard input through software, hardware, macros?

You could get a microcontroller to present as a keyboard and type anything you wanted.

Maybe that kind of thing could be prevented with managed devices or secure rooms?
Would it be worth including this kind of discussion in the specification?

[drchriscole]

@JimMadge yes that's basically it.

[manics]

I think the requirement could be "allow pasting in to be disabled" rather than "must be disabled"?

[JimMadge]

I think that kind of wording, "it must be possible to X" rather than "must do X" may be useful to design a specification that is flexible to different requirements while not imposing restrictive controls when it isn't necessary.

[crickpetebarnsley]

Why would a trusted research environment allow data to be taken out? Would that not break the "trust" of setting? Are people referring to the results data to be "copied and pasted"?

Do we need to be much more specific about what is affected by this "copy and paste"?

Getting some data into a table within a research projects TRE is one of the first steps for research to start. being able to copy a data grid and paste into a table within the research projects TRE is surely an advantageous thing. So 6.2 should offer a specification for that and it should not be forbidden.

Conversely, getting a set of sensitive data selected from within the TRE and copying it and pasting it into a data grid OUTSIDE the TRE (excel say) should be forbidden. Arguing that non sensitive data copying and pasting should be allowed is not fixing the problem. The TRE should make it easy to process the data inside so there is no need to take stuff out elsewhere.

But creating "outputs" that are safe and then copying these outside the TRE is a natural result of research and so must be allowed.

Governing this seems the issue. Perhaps we need to follow the maxim "build to help the business manage itself not to mange the business". So perhaps we need a set of logging routines and processing this to create reporting that highlights where people have done a inside to outside copy and paste such that the project and local governance of research process can take their (appropriate) responsibility and ownership.

So what is the context of the "copy and paste"?

[edwardchalstrey1]

This has been added here as:

Copying out data via the system clipboard must be disabled.
A TRE user must not be able to copy sensitive data out of a workspace using the system clipboard. A TRE may allow user to paste text into a workspace.

Based on @drchriscole suggestion that it's almost impossible to block paste into a TRE, I think it's fine we haven't mentioned that, even as an optional recommendation