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

[Yichao Yu]

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.

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

> 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

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

> 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