On Mon, Apr 15, 2013 at 3:45 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Sun, 14 Apr 2013 21:45:37 -0400 > Yichao Yu <yyc1...@gmail.com> wrote: > >> On Sun, Apr 14, 2013 at 9:33 PM, Matthias Clasen >> <matthias.cla...@gmail.com> wrote: >> > On Fri, Apr 12, 2013 at 1:33 PM, Yichao Yu <yyc1...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
