On Mon, Apr 15, 2013 at 5:00 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Mon, 15 Apr 2013 04:03:43 -0400 > Yichao Yu <yyc1...@gmail.com> wrote: > >> 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. > > 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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
