[Spice-devel] RFC [spice-gtk] session: Allow to delay sending clipboard to the guest

[Daniel P. Berrange]

On Thu, Jan 11, 2018 at 08:10:39AM -0500, Frediano Ziglio wrote:
> > 
> > Hi
> > 
> > ----- Original Message -----
> > > On Tue, Jan 09, 2018 at 12:16:33PM -0500, Marc-André Lureau wrote:
> > > > I think it's problematic for traditional applications as well.
> > > > clipboard access is probably going to be limited by default and only
> > > > accessed through so-called "portals", just like file access etc. This
> > > > topic should be brought on desktop / flatpak mailing list.
> > > 
> > > Maybe in some distant future, all applications everyone is running will
> > > be flatpak, and will be using portals to improve security. The same
> > > thing can be said regarding wayland, which does not have this issue.
> > > Some time in the future, this will become a non-issue. However, solving
> > > this now on x11 is definitely not something which should be related to
> > > portals/flatpak in my opinion.
> > 
> > I propose a --spice-disable-clipboard, and client UI to switch on/off
> > clipboard sharing functionality.
> > 
> > Something different will likely break some clipboard users or lower
> > experience.
> 
> If we consider this a security threat than default should be disabled
> and there should be a --spice-enable-clipboard. Note that the default
> option apply to different tools (like virt-manager and boxes).
> 
> If we decide to go to the on/off options I would see some options
> 
> - default on (like now). The user should be prompted that there's
>   a security issue and confirm to have understood. Without that
>   prompt and knowing the issue spice could be potentially considered
>   not that secure to use. That means the confirmation should be saved
>   in order to avoid prompting it every time;

Prompting the user to confirm that they understand a security issue
is a total disaster. Users will just blindly click through any
warning message about security if it gets in the way of what they
are trying to achieve.  At best we'll annoy users.

> - default off. We could say nothing but I think the user would be
>   quite frustrated as without any message and with just an update
>   copy&paste won't work. We could give the user a prompt also in
>   this case. This seems more secure, if user does not read the
>   message and click "ok" the data can be leaked.
> 
> From user experience and customer feeling somebody could complain
> that the vmware default (c&p only with focus like Christophe patch
> is supposed to do) is quite good and does not require manually
> enable/disable that making really easy to use.

This is really much more viable IMHO. It avoids need to prompt user with
security warnings and avoids extra config options and shouldn't break
normal usage patterns.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|