On Sun, 14 Apr 2013 21:45:37 -0400 Yichao Yu <[email protected]> wrote:
> On Sun, Apr 14, 2013 at 9:33 PM, Matthias Clasen > <[email protected]> wrote: > > On Fri, Apr 12, 2013 at 1:33 PM, Yichao Yu <[email protected]> > > 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 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
