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

[Yichao Yu]

On Mon, Apr 15, 2013 at 5:00 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 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.
>

Clipboard manager (or all other programs that need clipboard
monitoring) may be special, but I don't see why it is necessary to
break every single toolkits' api by don't allowing them to get
clipboard content without a focus. There is no way to do it (get
clipboard at any time) without breaking the current interface and
without sending out every selection changes.

>
> Thanks,
> pq