#6 Selectively Accepting Remote Clips.

[Ranieri Argentini]

From a bug report by "stefan1":

[...] I don't like Network Clipboard to transfer a clip
without first notifying the recipient that there is a
clip arriving and then awaiting the recipients
confirmation for the clip to be transferred. In case
the recipient had something important in the clipboard,
it would be over-written without the recipient being
able to stop it.
Prior notification of the recipient would also include
the feature of addressing the clip towards a certain
host instead of broadcasting it to any client listening
on that port.

Reply in same thread:

I agree that blindly accepting clipboard contents from the
network is a bad idea, at least from a security standpoint.
However, the focus of this tool is, at least as far as I am
concerned, to be used by a single person using multiple
computers at the same time. Think of a desktop/laptop
setup,
or multiple machines on a KVM switch. It is nto primarily
intended as a "collaboration" tool where the roles of the
sender and the recipient are embodied by different physical
persons.

In the next version of the protocol (somewhere due before I
release version 1.0) I'll be tackling the issues of data
integrity and confidentiality, which will amongst other
things mean a move towards connection oriented data
exchange, relegating the broadcast mechanism to peer
discovery only. Selectively accepting clips from authorized
peer however is not high up on my list of priorities
because, simply put, it does not scratch my itch.

On the other hand, I'm sure there are more people that
would
like such a feature. I'm going to open a "feature request"
tracker item for it, lest i forget after i close this bug
report.