cut and paste

[Kragen Sitaker]

In an environment that supports flexible confinement, such as
KeyKOS/Pacific or EROS (or, soon, E), it is possible for cut-and-paste
communication not to involve two-way communication between
applications, yet support multiple fornmats and flexible negotiation.

As one example, suppose I want to cut and paste from my web browser to
somewhere.  If I paste into a plain-text text window, I would like a
pure-ASCII rendering of the section of the web page I cut; if I paste
into a spreadsheet, I would like separate table cells in the web page
to turn into separate table cells in my spreadsheet; and if I paste
into a rich-text editor (say, a web-page editor) I would like all the
tables, formatting, inline images, and other metadata from the
original web page to be inserted.

The standard approach is for the applications at different ends of the
communication to negotiate about what formats are possible for the
selection --- the sending application talks about what it can provide,
while the receiving application talks about what it can accept.  This
is undesirable from a security point of view, because it provides a
high-bandwidth communication channel between the applications.

The solution
------------

The sending application produces a provably confined and stateless
(i.e. DeepFrozen) compartment containing the cut or dragged data,
along with any code necessary to understand it, convert it to
different formats, and conduct format negotiations, and hands it to
the user interface.

When the receiving application is to receive the data, the user
interface asks the stateless compartment to produce a provably
confined, stateful compartment for this transaction.  

This stateful compartment then negotiates with the receiving
application to figure out what format to deliver the data in; this
negotiation can involve changing the state of the stateful
compartment.  When the transaction is completed, the stateful
compartment is destroyed.

Because the stateless compartment is stateless, it cannot be used as a
covert channel between different receiving applications.  Because it
is confined, it cannot be used to communicate back to its originating
app, so the cut-and-paste transfer involves strictly one-way
information flow.

About UI
--------

I think there are unsolved UI problems here, but they all relate to
keyboard accelerators.

It seems to me that some applications --- for example, an X window
server in a window, providing access to a remote system, or a terminal
emulator --- would benefit from being able to receive any keystroke
that is physically possible on the keyboard.  But allowing arbitrary
keystroke rebinding is bad for usability and security; if the user has
private information on the clipboard, it would be unfortunate if
pressing, for example, the 'p' key were to provide an untrusted app
with that information.

For most applications, allowing standard keystrokes to invoke
operations the application does not itself possess the authority to
invoke, such as "cut" or "paste", should not be a problem, if the user
recognizes the keys as such.  But there are potential problems;
suppose control-V is "paste", and a game requiring quick responses
while keeping one's eyes on the screen uses control-G, control-N, and
control-space for controls; or perhaps rapid switching between
control-T, control-Y, and control-U, and control-B, control-N, and
control-M.

Even allowing some applications, like terminal emulators, to directly
receive keystrokes that normally invoke paste operations would lead to
security breaches.  A malicious terminal emulator, for example, could
pretend to prevent control-V from pasting, instead sending a control-V
to the other end of its connection, while actually accepting the paste
contents and sneaking them to the other end of the connection over a
covert channel.  This might be detectable behavior, but it is likely
that it could be implemented in such a way as to escape detection.

Jonathan's proposal of a trusted menu system seems technically quite
assurable, but flawed from a UI perspective.  If an untrusted
application has the freedom to label and place the "paste" menu item
itself, it can steal sensitive clipboard contents.  Similarly, I think
his proposal of granting clipboard access to any app that gets the
focus will result in sensitive clipboard contents being stolen due to
user errors.

I don't think drag and drop is an adequate replacement for clipboard
access; it is much less usable in important ways --- it is more
error-prone and takes much more time on small screens.

In any case, copy and paste menu items can only be justified by an
absence of copy and paste toolbar buttons.

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
What we *need* is for some advanced off-world sentience to carpet nuke planet
Earth from high orbit.  Call it Equal Opportunity Ethnic Cleansing.  I mean,
racism is so petty.  Why play favorites?  -- RageBoy