[OLPC Security] Bitfrost vs. Rainbow

[Mark Seaborn]

"Karl O. Pinc" <kop at meme.com> wrote:

> On 04/10/2008 02:39:22 PM, Mark Seaborn wrote:
> > Michael Stone <michael at laptop.org> wrote:
> > 
> > > On Tue, Apr 01, 2008 at 07:50:52PM +0100, Mark Seaborn wrote:
> 
> > > Could you say more about your goals for the clipboard?
> > 
> > Just as sandboxed applications get read or write access to the user's
> > files via a trusted-path file chooser (the file powerbox), they should
> > only get read or write access to the clipboard via a trusted-path user
> > interface.  Applications should only be able to read from (paste) or
> > write (cut/copy) to the clipboard after an explicit action from the
> > user, such as a key press or a mouse click, and the user needs to be
> > able to tell what consequence their action will have.
> 
> > Note that I am talking about X's CLIPBOARD.  The conventional
> > interface for X's SELECTION is not securable: pasting with the middle
> > button might be securable, but copying just by selecting text is not.
> 
> I don't understand the last sentence.
> Why is selecting text (or using the middle mouse button to paste)
> any less of an "explicit action" than Ctrl-C (or Ctrl-V)?

There are lots of ways text can become selected: by dragging; by
double clicking; by pressing Shift-Left or Shift-Right; or in Emacs,
by pressing Ctrl-Space and then the arrow keys.  How would the window
system tell when these actions claim the selection and when they
don't?  It could assume that every drag or double click claims the
selection, but that will cause false positives, which have the
consequence that the selection gets overwritten, and how should the
window system distinguish between clicks and drags?  If the window
system did not know about Shift-Right causing a selection, that would
cause false negatives, which have the consequence that there is a
selection displayed on screen which is not pastable.

The same problem exists with assuming that Ctrl-C always means Copy,
just to a lesser extent.  In the scheme I described before, pressing
Ctrl-C in a terminal window would overwrite the clipboard, even though
it means "send SIGINT" rather than Copy.  The scheme could be modified
so that the clipboard is only overwritten after Ctrl-C is pressed
*and* the application claims the clipboard, but that change would make
it less predictable because the owner of the selection would depend on
application behaviour.

Regards,
Mark