[PATCH] selection: send selection events to all connected clients

[Pekka Paalanen]

On Sun, 14 Apr 2013 21:45:37 -0400
Yichao Yu <yyc1992 at gmail.com> wrote:

> On Sun, Apr 14, 2013 at 9:33 PM, Matthias Clasen
> <matthias.clasen at gmail.com> wrote:
> > On Fri, Apr 12, 2013 at 1:33 PM, Yichao Yu <yyc1992 at gmail.com>
> > wrote:
> >> A lot of useful features require clipboard access and monitoring
> >> without having a keyboard focus, e.g. clipboard action (klipper[1]
> >> and some download agents), command line access (IPython's %paste
> >> magic). This patch sends out selection events to all clients when
> >> the selection owner changes no matter whether the client has a
> >> focus or not in order to support these features.
> >
> > Clipboard managers are pretty specialized clients, and you usually
> > only run at most one of them in your session - why confuse all other
> > clients with the extra events ?
> 
> Actually all client may want to know the clipboard content even when
> it doesn't have focus. And clipboard monitoring doesn't means
> clipboard manager. It is also used by many download agents as what I
> have said.

All clients may also want to do screenshots, or listen for hotkeys, but
that is absolutely no reason to allow them to do that in an
undiscriminated way. Clipboard content is no different. As far as I
know, Wayland has taken the design decision to eliminate this kind of
security breaches compared to X.

If you really want to have a clipboard content change broadcast, create
a new interface, where interested clients can subscribe for them. I see
that as the minimum requirement for this kind of a change to be even
considered seriously.

As for the download agents, what is wrong in clicking a download agent's
button in a system tray or something? That would be an explicit signal
from the user, that he wants the agent to react. If an agent reacts by
some heuristic to all URLs a user ever happens to copy, isn't that
extremely annoying? How do existing download agents avoid annoying the
hell out of the user?

Allowing command line utilities the access to clipboard contents (or
to take screenshots, equivalently), is a problem. Enabling them enables
all spy programs, too. I'm not sure we can both enable them and stay
secure, it seems to be an either-or for a user to choose. But we *can*
design a protocol extension to allow enabling them at runtime, and
leave the choice of actually using it for the server (controlled by the
user). How the control works in the GUI is not interesting. The protocol
extension is interesting.

An optional protocol extension must be the starting point for any
proposals like this one. Let's keep the system secure by default, but
allow workarounds if needed. That is why you should not modify the core
protocol but introduce a new extension, that is optional, and
preferrably also handles dynamic security policy changes runtime (i.e.
doing a currently forbidden action would not be fatal to the client).

It is also useful to not specify any particular ways or reasons to
enable or disable these optional extension in the specification, as long
as they can be switched dynamically. This allows other people to come up
with and implement nice ways to toggle them, perhaps even as per-client
basis.

In other words, if it is still unclear, I am proposing that you should
create a protocol extension, an interface, that will allow a client to
ask for the current clipboard contents. The server may accept or
refuse. You can also add content change events, and the server may or
may not send them, depending whether it currently allows getting the
clipboard content. This extension would cater for all random clients
wanting to get the clipboard content at arbitrary times, like command
line utilities. Clipboard managers may require a different interface,
depending on their needs. Do not put random clients and a clipboard
manager into the same bucket, like we already separate random clients
and a screenshooter client.

Or if you can already do the above with the existing protocol, you are
welcome to propose that, but keep in mind that it has to be secure by
default, and you may not break the protocol or ABI.


Thanks,
pq