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

[Pekka Paalanen]

On Mon, 15 Apr 2013 04:03:43 -0400
Yichao Yu <yyc1992 at gmail.com> wrote:

> On Mon, Apr 15, 2013 at 3:45 AM, Pekka Paalanen <ppaalanen at gmail.com>
> wrote:
> > 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
> 
> What's wrong with manually typing instead of copy and paste? Than you
> will know every single byte you have copied.

Typing the URL is tedious, clicking once is easy. And I don't even
mean any "right-click to open menu, select operation" but literally one
click after copying the URL. That is enough to wake the agent, give it
focus enough, and allow it to get the clipboard content, so that it can
pop up its dialog or notification.

> > 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
> 
> If a program decide to randomly popup windows, isn't that more annoy.

Hm? That's exactly my point.

> > 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
> 
> Why does a spy program have to steal sth from your clipboard while it
> can easily send out your whole $HOME

Because what I see on my screen, or have in my clipboard, is quite
often *not* in any file in my $HOME.

Just because someone can break into your house through the window does
not mean you happily leave the door unlocked.

> > 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
> 
> If you trust a program and run it, why should you implement a security
> layer where there is nothing much to protect.

Nothing much to protect? Seriously?

> > 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.

What's wrong with this proposal?

I do not believe your patch will get through, so you will have to
revise it anyway. I was just trying to be helpful, and suggest
something that might be acceptable, since you clearly do not see the
security implications, or the technical implications of waking up every
single client every time the selection changes.


Thanks,
pq